Back to Blog
May 14, 2026Kris Newlin

The First 7 Days With an AI Coworker: A Day-by-Day Activation Plan

Most AI rollouts fail in week one. This is the day-by-day plan that gets a real workflow shipping by Day 7. Connect tools on Day 1, ship the first cron on Day 3, expand on Day 5. No abstract framework, just the actual schedule.

Key Takeaways

  • Most AI rollouts die in week one because the goal is too vague. "Try out AI for our team" is not a plan. The plan that works is a specific, named workflow shipping by Day 7. One workflow. One owner. One review meeting at the end of the week.
  • The 7-day plan is structured around proof, not exploration. Day 1 is connections. Day 2 is the first manual ask. Day 3 is the first cron. Day 4 is internal feedback. Day 5 is the second cron. Day 6 is documentation. Day 7 is the team review and expansion plan for week two.
  • The first cron is always internal-only. Slack-posts, Notion-drafts, internal-only data pulls. Not customer-facing. Not anything that touches money. The point of week one is to build trust in the tool, and trust is built on low-risk wins, not on hero moves.
  • The biggest mistake is starting with the most ambitious workflow. "Make our entire customer onboarding agentic" is week 12, not week 1. The right week-1 workflow is something a junior PM could describe in two sentences.
  • By Day 7, you should have: two crons running, three teammates trained, a documented playbook, and a list of five week-2 candidates. If you don't, the plan didn't work and the team needs to debrief why before week 2 starts.
  • This is not how-to-manage-an-AI-coworker (that's [a separate post](https://viktor.com/blog/how-to-manage-an-ai-coworker)). This post is the activation calendar. The management discipline comes after the activation lands.

The short version

The First 7 Days are not about exploring possibilities. They are about producing one shipped workflow, with three witnesses, that the team can point to as evidence the tool works. That is the only goal of week one. Everything else is week two onward.

The plan below is what we recommend after watching dozens of teams do this well and many do it badly. The teams that succeeded had a specific workflow named on Day 1 and a finished version of it on Day 7. The teams that failed wandered through Day 4 still asking "what should we try?"

If you adopt nothing else from this post, adopt this: pick the workflow on Day 1. Don't change it mid-week. Ship it by Day 7. Expand from there.


Day -1: The pre-flight (one day before kickoff)

Before Day 1, do two things:

1. Pick the team. Three people. One champion (probably you, if you're reading this). One skeptic (someone who will challenge what works and what doesn't). One implementer (someone who will set up the actual workflow). Bigger groups slow week one down. Smaller groups fail because the workflow has too few witnesses.

2. Pick the workflow. Single workflow. Internal-only. Recurring. Examples that have worked:

  • Monday morning revenue digest (Stripe + HubSpot, posted in #revenue)
  • Friday weekly summary across team Slack channels (read 5 channels, post a digest)
  • Daily competitor intel scan (read RSS, post links to #competitive)
  • Customer feedback weekly synthesis (Pylon + Granola, post a Notion brief)
  • Weekly hiring pipeline state (Ashby data, posted in #hiring)

Avoid for week one: anything that emails customers, anything that updates the CRM, anything that touches code. Save those for week two and beyond.

Write the workflow definition in one paragraph. "Every Monday at 8 AM, in #revenue, post: new MRR last week, biggest deal closed, top 3 deals in pipeline by stage change, top 3 churn risks based on Stripe events. Source data from Stripe and HubSpot." That paragraph is your scope. Don't change it.

Day 1: Connect everything

Day 1 has one goal: connect the AI coworker to the tools the workflow needs.

For the example workflow above (Monday revenue digest), that's:

  • Slack (the surface the digest posts to)
  • Stripe (where the MRR data lives)
  • HubSpot (where the deal data lives)

For your specific workflow, list the integrations and connect them. Each integration takes 2-5 minutes. Plan a 60-minute block.

A common Day-1 mistake: connecting too many tools "while we're at it." Resist this. Connect only what the chosen workflow needs. More integrations = more attack surface = more questions from security. Add tools as workflows demand them; don't pre-connect.

End-of-Day 1 checkpoint:

  • All required integrations connected
  • A test message in Slack: "@Viktor confirm you can read Stripe" returns a sane response
  • The team is in the channel where the workflow will run

Day 2: The first manual ask

Day 2 is not about automation. It's about asking the AI coworker to do the workflow manually, once, with a human watching.

@Viktor pull the following from Stripe and HubSpot for last week
(Monday-Sunday inclusive):

1. New MRR added (sum of new active subscriptions started in the window)
2. MRR lost (sum of subscriptions canceled or downgraded in the window)
3. Net MRR change
4. Largest single new subscription (customer name, MRR)
5. Top 3 deals that moved stages in HubSpot (deal name, from-stage, to-stage)

Post the result as a Slack message in this thread with the data inline.
Also flag any deal-stage moves that look weird (e.g., backward stage moves
or deals stuck for more than 30 days).

This is a manual ask. The AI coworker does the work, returns the result, the three witnesses (champion, skeptic, implementer) read the output and discuss:

  • Are the numbers right?
  • Is the format readable?
  • What would you change?

The point of Day 2 is not to ship the cron. It's to verify the AI coworker can actually do the job before you put it on a schedule. Saturate the prompt; iterate the output. By end of day, you should have a refined version of the prompt that produces output the team would actually read on a Monday morning.

End-of-Day-2 checkpoint:

  • A working prompt that produces the right output when run manually
  • The three witnesses agree on the format
  • A documented prompt (in Notion or your wiki, the exact words you'll use in the cron)

Day 3: Ship the first cron

Day 3 is when you take the manual ask from Day 2 and put it on a schedule.

@Viktor every Monday at 08:00 Europe/Amsterdam in #revenue:

[the exact prompt from Day 2]

If any data source is unavailable, do not skip the post; instead post a
message saying "Data source X was unavailable; here's what we have" with
the partial data.

That's the cron. The AI coworker confirms it's scheduled. Done.

But Day 3 has a second job: trigger the cron manually for the first run, so the team sees what the actual posted output will look like in the channel. Don't wait until Monday to find out the output is broken on Monday.

@Viktor run the Monday revenue digest cron now as a test (post the result
to #revenue-test instead of #revenue, so we can review without spamming
the real channel).

Review the test output with the three witnesses. Adjust if needed. Re-run. Once it looks right, the cron is shipped.

End-of-Day-3 checkpoint:

  • Cron scheduled
  • Test run executed and reviewed
  • Team agrees this is the version that should run Monday
  • One paragraph in the team wiki: "the Monday revenue digest, what it does, where it posts, who owns it"

Day 4: Internal feedback day

Day 4 is the rest day from new building. It's when you get the team's feedback on what shipped.

In #general or wherever the team gathers, post:

Heads up team. The Monday revenue digest will start posting this coming Monday at 8 AM in #revenue. We'd love your input today on whether the format is right. The output looks like this [paste the test output from Day 3]. Anything you'd change?

Watch the responses. The skeptic on your team-of-three will probably ask the hard questions ("what about churn from downgrades?", "can we see the source-of-truth?"). The rest of the team will weigh in on format ("can the deals be sorted by value?", "show the trend vs last week").

Day 4's product is a list of week-2 changes to make. Don't make them on Day 4. Capture them in the wiki as "v2 backlog." This is how you avoid scope creep mid-week-one.

End-of-Day-4 checkpoint:

  • Feedback collected from at least 5 teammates outside the team-of-three
  • A v2 backlog with 3-7 items captured
  • Zero changes to the live cron between Day 3 and Day 5

Day 5: Ship a second cron

Day 5 is when you stretch into a second workflow. The point is not to maximize output. The point is to prove the activation pattern (pick, prompt, schedule, verify) is repeatable.

The second workflow should be:

  • Internal-only (still no customer-facing actions)
  • Different from the first (don't ship two revenue digests; pick a different category)
  • Owned by a different team member than the first

If the first cron was a revenue digest owned by you, the second cron might be a "weekly product feedback synthesis" owned by your PM, or a "Friday hiring pipeline summary" owned by your recruiter. The point is to spread the muscle.

Run the same Day 2-3 pattern compressed into Day 5: one manual ask, one prompt iteration, one scheduled cron, one test run.

End-of-Day-5 checkpoint:

  • A second cron is live
  • A second teammate has run the pattern
  • The wiki has two workflows documented

Day 6: Documentation and handoff

Day 6 is the maintenance day. The two workflows are running. Now make sure they don't depend on you alone.

Spend Day 6 on three things:

  • 1. Document the playbook. Each cron in the wiki gets:
  • What it does (one paragraph)
  • Where it posts
  • Who owns it
  • The exact prompt
  • How to debug it (what to check if the output is wrong)
  • How to pause it (one command)

2. Train one backup person per cron. The owner is the primary; a backup teammate knows how to read and edit the prompt if the owner is out. The backup walks through the cron once with the owner watching.

3. Set the review cadence. Decide now: how often will the team review whether each cron is still useful? Monthly is good. Add a calendar reminder for the first review (4 weeks out).

End-of-Day-6 checkpoint:

  • Both crons documented end-to-end in the wiki
  • Two backup owners trained
  • First monthly review scheduled

Day 7: Team review and week-2 plan

Day 7 is a 30-minute team meeting. Three witnesses plus anyone else interested. Three agenda items:

1. What worked. The crons are running. Demo the most recent post from each. Note what the team noticed.

2. What's noisy. Anything that didn't work as expected? Format issues, threshold problems, data source quirks. Capture as "fix in week 2."

  • 3. The week-2 candidate list. Pick 3-5 candidate workflows for the next week. The criteria:
  • Still internal-only (week 2 is too soon for customer-facing actions)
  • Spans a different team or function (don't ship 5 revenue crons; spread)
  • Has a clear owner

By end of Day 7, you have:

  • 2 crons live
  • A v2 backlog from Day 4 of items to upgrade in the existing crons
  • A week-2 list of 3-5 new crons to ship
  • A documented playbook
  • An organic story to tell the rest of the company: "here's what we did in 7 days, here's what's coming next"

That story is the most important week-1 deliverable. The crons are evidence; the story is the artifact that gets the rest of the org to lean in.

Common week-1 failure modes

Three failures we see repeatedly. If you're heading toward any of these by Day 4, course-correct.

Failure 1: Wandering scope. "We connected Slack, Gmail, HubSpot, Stripe, Linear, Notion, and PostHog, and we're still figuring out what to do." This is the most common failure. Fix: stop adding integrations. Pick one workflow. Ship it.

Failure 2: Customer-facing too early. "We set up an auto-response to all support emails this week." This is week 8, not week 1. Trust isn't built yet. The first auto-send to a customer that's wrong burns months of credibility. Fix: revert to internal-only for week 1.

Failure 3: Solo champion. "I set up two crons; nobody else on the team knows how they work." This is the slow-burn failure. By month 3, you're the only one who can debug anything, and the AI coworker becomes a personal tool, not a team capability. Fix: make sure two people can edit each cron by Day 6.

What week 2 looks like (in one paragraph)

Week 2 is when you pick three of the candidate workflows from Day 7 and ship them, while upgrading the v2 backlog items on the existing crons. Still internal-only. Still review-first. By end of week 2 you have 5 crons running, 5 documented workflows, and a team that has now done the activation pattern five times. By week 4 you can begin considering the first customer-facing workflow, with explicit human-approval gates. By week 8 you're managing an AI coworker the way you'd manage a junior teammate, which we cover separately in How to Manage an AI Coworker Like a Team Member.

Safety and approval (week 1 specific)

The week-1 default is conservative on purpose. The hard rules:

  1. No customer-facing emails sent. Period. Drafts only, and even drafts are not the focus of week 1; that's week 4+.
  2. No CRM writes. All HubSpot or Salesforce updates in week 1 are read-only. Changes wait for week 3+.
  3. No code commits or deploys. Engineering integrations are read-only in week 1.
  4. Internal Slack posts and Notion drafts only. Auto-create those; everything else waits for human approval.
  5. One person on call for each cron. If something looks wrong, that person can pause the cron with a single command.

The same review-first principle behind the Air Canada bereavement-refund lesson applies in week 1: the cost of an AI taking a wrong customer-facing action in week 1 is far larger than the cost of waiting two weeks to enable that workflow. Be patient. Build trust first.

Frequently Asked Questions

Can we accelerate this to 3 days instead of 7?

Sometimes. If you have a single high-confidence workflow and an experienced team, the connect-prompt-schedule-test loop can compress to 2-3 days. But you lose the muscle-building benefit of running the pattern twice. We recommend the full 7 days for the first activation; compress on subsequent rollouts.

What if the first workflow doesn't ship by Day 7?

Stop and debrief. The cause is usually one of the three failures above (wandering scope, too ambitious, solo champion). Don't extend Day 7 into week 2; reset and pick a smaller workflow. Ship something on Day 7, even if it's smaller than the original plan.

Should we tell the broader team about this in week 1?

Yes, briefly, on Day 4. Don't make a launch announcement. Let the crons run and the team see them naturally. The story emerges from the artifacts, not from a memo.

What if the Stripe or HubSpot data is messy and the digest looks bad?

That's a real win. Week 1 surfaces data hygiene problems you didn't know you had. Capture them and address them in week 2-3. The AI coworker doesn't make the data worse; it makes the data visible.

Do we need to write the prompts in plain English or in some special syntax?

Plain English. The whole point of an AI coworker is that the prompt sounds like an instruction to a teammate. The prompts in this post are the actual format. No special syntax.

What about training data and security in week 1?

Standard SOC 2 compliance applies; no training on your data without explicit permission. Run the standard security review your team would for any new SaaS tool. Most teams complete this on Day 0; if not, build a half-day on Day 0 for it.

How does this scale to multiple teams kicking off at once?

Each team runs its own 7-day plan. Don't try to coordinate a company-wide week-1. Decentralized adoption with shared playbook beats centralized rollout.

Viktor is an AI coworker that lives in Slack, connects to 3,200+ integrations, and ships its first useful workflow inside the first 7 days.

Get Started For Free →

$100 in free credits. No credit card required.