How To Tell If Your Ops Team Is Ready For Cowork

If you've been hearing about Cowork and trying to figure out whether your team is ready, this is the post. Six signals you're ready. Four signals to fix something else first. What to bring to a scoping call.

No theory, no feature tour. The point is for you to self-qualify before you book the call, so the time we spend together goes into shaping a deploy instead of figuring out whether one fits.

Six Signals You're Ready For A Cowork Rollout

If you nod at four or more of these, you're in the right zone. All six and the rollout will pay back inside the first month.

1. Your operational knowledge lives in one or two people's heads

You have a head of ops, an office manager, or a senior coordinator who knows how everything actually works. Onboarding, vendor management, the workflow for a refund, the sequence for a new location opening. None of it is written down in a way someone else could run from. When that person takes a day off, the team slows. When that person leaves, the business shakes.

This signal lands well for Cowork because skill design starts with extracting what's in heads and encoding it as triggerable workflows. The rollout would target this pattern first. The audit captures the workflows your senior operator runs, the architecture turns them into skills the rest of the team can fire on demand, and by week three your operational memory lives somewhere other than one person's brain.

2. Your ops team is two to five people doing repetitive workflows

Small enough that every team member is doing real ops work. Large enough that the same patterns repeat across people. A two-person ops team running multi-location operations. A four-person back office at a franchise group. Three coordinators behind a small agency. The repetition is what makes the skills worth writing. The team size is what makes shared workflows worth standardising.

The rollout would target the workflows that show up in three or more team members' weeks. Those are the highest-leverage skills to write first because the savings compound across seats. The first build queue lands here.

3. You've got a stack that doesn't talk to itself

CRM, calendar, inbox, project tool, accounting, customer support, marketing. Each one does its job. None of them sync cleanly. Someone on your team is the manual bridge between them, copying data, updating fields, pulling reports, reconciling lists. The integration layer is a human, and that human is expensive.

Cowork lands well here because MCP connectors turn the stack into one queryable surface. The audit identifies which integrations are official, which need custom MCP work, and which can stay manual. The architecture wires the rest. By the end of the rollout, the workflows that used to require a human bridge run as scheduled tasks or on-demand skills against a unified source.

4. You have at least one workflow your team would describe as "the annoying one"

Every ops team has it. The Friday afternoon report. The new-location onboarding checklist. The vendor reconciliation. The end-of-month close. The intake sequence that requires checking four systems and emailing three people. Your team can name it without thinking, and they dread it on the calendar.

That workflow is the pilot. The rollout would target it first because the team is already motivated to see it solved, and the success metric is easy to define. If the annoying one shrinks from four hours to forty minutes, the team adopts the rest of the stack without resistance. The first pilot creates the political will for everything that follows.

5. You can name three to five SOPs that exist but nobody follows consistently

The new-client onboarding doc. The refund policy. The vendor escalation flow. The QA checklist. The reactivation sequence. They're written down somewhere. Maybe Google Docs, maybe Notion, maybe a Confluence page someone updated in 2024. The team mostly remembers the gist. Different team members do them differently. The gap between what's written and what gets done is wide.

That gap is exactly what skills close. An SOP encoded as a skill fires at the trigger point, runs the same way every time, and surfaces what was missed. The rollout would target the SOPs that fail most often or cost the most when they fail. Your existing docs are the raw material. The architecture turns them into skills the team actually uses.

6. You have a 90-day horizon with at least one launch you'd want this in place for

A new location opening in Q3. A product launch in 60 days. An expansion that doubles your client base. A hiring wave that brings three new ops people online. Something on the calendar that would benefit from the stack being live and the team trained before the load hits.

This signal matters because rollouts shape around real timelines, not generic templates. The architecture sequence ties each stage to a launch deadline. If you have a launch the rollout would serve, the engagement has a clear definition of done. If you don't, the rollout still ships, but the team adoption is slower because there's no forcing function pulling the work into daily use.

Four Signals You Should Fix Something Else First

These aren't disqualifications forever. They're disqualifications for now. Fix the root cause, then come back.

1. Your CRM is fundamentally broken

Duplicate records, fields nobody trusts, three systems that should be one, a pipeline view that doesn't match the actual deals. The CRM is the source of truth for half the skills a Cowork rollout would write. If the source is broken, the skills inherit the brokenness, and every workflow that reads from the CRM produces unreliable output.

Fix this first. A CRM migration or consolidation is its own engagement. Audit the current state, design the target schema, migrate the data, validate it, retrain the team. Six weeks to six months depending on size, complexity, and team. Once the CRM is the source of truth your team actually trusts, the Cowork rollout reads from a clean foundation and the skills compound. Doing them in the wrong order means rebuilding the skills after the CRM gets fixed.

When to revisit. After the migration is complete, the team is trained, and a month of production use confirms the CRM holds up. At that point, signal six (the launch horizon) usually re-applies and the rollout sequence kicks off.

2. You don't have ops headcount yet

You're a solo founder, or a founder plus a part-time VA. Ops is whatever you do between sales calls. There's no team to roll a shared layer out to, and most of the workflows that would benefit are still being invented.

Fix this first. Cowork is a team layer. The architecture, the shared skills, the source-of-truth wiring, the Live Artifacts, the training cycle. All of it assumes a team that uses the same workflows daily. For a solo founder, the right move is a different stack and a different scope. Stand up the back-office basics, hire your first ops person, document the workflows they end up running, and let three to six months of pattern emerge.

When to revisit. When you have two or three ops team members running repeatable workflows for at least 90 days. At that point you have enough pattern to encode and enough seats to make the shared layer worth the build.

3. You have less than 90 days of ops history at current scale

You just hired your ops team. You just opened the third location. You just pivoted the service model. Whatever your team does now is six weeks old, and it's still changing every week. The workflows haven't settled into a pattern yet.

Fix this first. Cowork skills are encoded patterns. If the pattern isn't stable, the skill encodes the wrong thing and has to be rewritten in week three. A rollout that ships before the operation stabilises is a rollout you pay for twice. Let the team run for three months. Watch which workflows repeat, which break, which get invented and abandoned. The patterns that survive the first quarter are the ones worth encoding.

When to revisit. When the team has been running the current model for 90 days and the leadership team can name the workflows that show up every week. Stable repetition is the prerequisite. Without it, the rollout encodes a moving target.

4. You don't have decision authority on workflow changes

You're evaluating the rollout, but the team's workflows are owned by someone else. A boss who hasn't approved the spend, a parent company that has to sign off, a board that asks questions. Or you're a department head and the rollout touches another department's tools without their buy-in.

Fix this first. Cowork rollouts touch how the team works. Skills change daily habits. Live Artifacts replace existing dashboards people are attached to. The /customize tuning step asks for opinions about voice rules and workflow ownership. Without decision authority, the engagement stalls at the first conflict, and the team that has to adopt the stack drags their feet because they weren't part of the call. The rollout fails on adoption, not architecture.

When to revisit. When you have either explicit authority over the workflows the rollout would touch, or a sponsor higher up who has signed off and will back the changes with the team. Decision authority is non-negotiable. Get it before the scoping call, not after.

What To Bring To A Scoping Call

If you cleared the readiness check and you're booking the call, here's the prep that turns a 45-minute conversation into a real scoping pass. The more you bring, the more concrete the call gets.

Your top five recurring workflows. The ones that eat the most team hours every week. Name them, estimate the hours, identify who runs them. "New client onboarding, four hours a week, runs through our office manager." That level of specificity.

Your current stack. CRM, calendar, inbox, project tool, accounting, customer support, marketing, anything else the team lives in. A list of names is enough. We'll figure out connector status on the call.

Where SOPs live. Google Docs, Notion, Confluence, a shared drive, in heads. The honest answer matters more than the polished one. If "in heads" is the truth, say so.

Names of the one or two ops team members who'd be primary users. Not org-chart-wide. The actual humans whose workflows the rollout would touch. Their roles, their seniority, their tech fluency.

Your 90-day calendar. Launches, deadlines, hiring waves, expansion milestones. Anything the rollout would need to be in place for. The timeline shapes around real events, so vague is expensive.

Honest answer on decision authority. Who has to sign off on workflow changes. Who owns the spend. Whether you're the buyer or the evaluator. Better to surface this on the call than discover it in week two.

What You'll Walk Out Of The Call Knowing

Whether Cowork is the right next move. Sometimes it isn't. If the readiness check surfaces a broken CRM, a team that's too new, or a workflow set that hasn't stabilised, the honest answer is to fix that first. The call surfaces the call, not a yes.

Which of your workflows would get the highest leverage. Not the full build queue. The two or three workflows that would land first, the ones with the cleanest trigger conditions and the highest hours saved per skill. That's enough to know whether the engagement is worth scoping fully.

The rough sequence and 30-day shape. Not a detailed scope, not a fixed quote. A structural map of what discovery, architecture, build, and handoff would look like for your operation. Enough to plan around. Enough to take to whoever else has to weigh in.

Whether you need a CRM migration first. Sometimes the call surfaces that the foundation isn't ready. If that's the case, the honest answer is to scope the migration separately and revisit the Cowork rollout after. Sequencing matters. A rollout on a broken foundation is a rebuild waiting to happen.

Why The Readiness Check Works

The reason this diagnostic works is the person running it has shipped Cowork rollouts and the engineering work underneath. Most consultants will sell you a strategy. Most engineers will sell you a build. A hybrid will tell you whether you need one yet.

Skills are easy to write. They are hard to write well. The audit, the schema design, the failure-mode planning, the integration contracts, the pilot validation. None of those compress because the tooling got faster. The work of designing the architecture stays the same. The cost dropped on the syntax side. The rigor stayed on the engineering side. A readiness check that doesn't surface those distinctions sells you a deploy you'll rebuild in month three.