A 30-day rollout: who gets seats first, what goes in the shared knowledge base vs personal projects, role-based access for finance vs legal vs ops, spend-limit configuration, and the prompt-library structure that scales past 50 users. Don't let marketing pilot first. Start with finance close.
The default Cowork rollout goes like this. Marketing asks first, because marketing always asks first. They get the seats and produce a great deal of copy, and at the end of the quarter nobody can say whether the company is better off. Finance is still closing the month in a spreadsheet.
Cowork is Anthropic's product: Claude working inside the folders, documents and tools on a person's machine, carrying out multi-step tasks rather than answering one question at a time. At 50 people that is a different proposition from a chat window. There is no IT department to absorb it, one person runs finance, and every mistake has a name attached.
So the rollout is not a licensing exercise. It is a sequence of decisions about who goes first, what the company knows collectively rather than individually, and where the boundary sits between the people who see payroll and the people who see contracts. We run it in 30 days, in this order.
Why start with finance close and not marketing?
Because the close has a ground truth and marketing does not. When the controller drafts the accruals schedule or the variance commentary with Cowork, every output is checked against the ledger by its reviewer, on a deadline that arrives whether the tool worked or not. A wrong number is caught inside the month. A weak headline is published, and the argument about whether it worked outlasts the pilot.
On our finance automation payback map we rank the close late, because as a build it depends on everything above it. That is exactly why it is the right place for a person with an assistant: the team already verifies everything, so the assistant is judged on evidence. Nothing Cowork drafts is posted until the controller approves it, so the human stays in the loop by construction. And 30 days covers exactly one close, which makes the second close the measurement.
A pilot without a ground truth produces enthusiasm, not evidence. The close has a ground truth and a deadline.
Who should get Cowork seats first?
Fewer people than want them, chosen for the workflow rather than the enthusiasm. Each week below ends with a written decision, not a demo.
- Week one: finance close. Seats for whoever owns the close and whoever reviews it. The COO or IT lead builds the finance knowledge base from the close checklist, chart of accounts and prior close packs, personal data removed. The owner writes down what a good close looks like before this one starts.
- Week two: ops. Seats for the recurring, documented processes: supplier onboarding, the weekly operating report, the procedures. Same rule as finance: a named person checks every output against its source. This is the week the personal versus shared line gets drawn.
- Week three: legal and people. Contract review against your own playbook; policy answers from the handbook. These roles have the hardest boundaries, so they follow an access model already tested on finance and ops. The first spend caps per team are set now, on a fortnight of evidence.
- Week four: the second close and the seat review. Measure the close against the definition from week one. Then, and only then, open seats to the teams that asked first, marketing included, with the prompt library and the usage policy already in place.
What goes in the shared knowledge base and what stays personal?
The distinction that matters is not confidentiality. It is whether the company wants the answer to be the same whoever asks. If everyone in a role should get an identical answer, the source belongs in the shared knowledge base: the close checklist, the chart of accounts, the contract playbook, the employee handbook. If the answer may vary with the individual, it stays in a personal project: the draft nobody has seen, a meeting's notes, Friday's working file.
Two rules keep it honest. A shared knowledge base has an owner accountable for keeping it current, and anything in it is company policy the moment a model can read it. And nothing personal about an employee or a customer goes into any project unless the data classification in your usage policy says it can. That is the clause companies breach first, and Cowork's ability to read whole folders makes it easy to breach by accident: one shared folder with an HR spreadsheet at the bottom of it.
How do you structure a prompt library that scales past 50 users?
By role and by output, not by cleverness. A prompt library at 50 people is a small set of named, owned instructions, each producing one artefact: the variance commentary, the supplier due diligence summary, the first-round contract review, the job description from a role profile. Each lives in the knowledge base of the role that owns it, states which source it reads and who reviews the result, and carries a version. Past 50 users it scales because a new starter in finance inherits finance's prompts with finance's sources.
How do you set access and spend limits by role?
Access follows the data, not the org chart. Finance sees the ledger and the close pack. Legal sees the contracts and the playbook. Ops sees suppliers and procedures. People sees the handbook and the HRIS record. Nobody sees all four by default, founders included. The boundary is the knowledge bases themselves: one per function, membership managed by whoever manages the identity provider, and the approved-tools page of the policy pointing at that list rather than at a PDF.
Spend limits are set per team, not per person, and after the first fortnight rather than before it. Set a monthly cap per team on what the early usage justifies, alert the team lead before it is reached, and revisit it at the seat review. A cap set on the first day is a guess that either strangles the finance pilot or means nothing; a cap set on evidence is a budget.
What are the three mistakes?
- Letting marketing pilot first. High output volume, no ground truth, and a verdict that is a matter of taste. Enthusiasm spreads faster than evidence, and at the budget review there is nothing to show but drafts.
- Giving everyone a seat on the first day. Fifty seats before there is a shared knowledge base means fifty personal knowledge bases, none of them owned, and a prompt library nobody can find. Seats follow the shared knowledge bases, never the other way round.
- Treating the rollout as an IT ticket. Which folders a model may read is a governance decision, and whoever provisions seats rarely knows what is in the shared drive. The rollout needs an owner in the business, a policy that says what a model may see, and a reviewer who signs off on outputs.
What to do next
If you have not started, pick the close. Name the owner, the reviewer and the definition of a good close, in writing, before the first seat is issued. If you have already started with marketing, do not withdraw the seats; add finance this month, run one close, and let the comparison settle the argument. Either way, have the usage policy written before week three, because legal and people cannot be given seats without it.
We build this on spec. A 20 or 45-minute call is enough to tell whether your close is ready to go first and whether your shared drive can become shared knowledge bases without a clean-up. Where the scope needs defining, a four-day Spec from €5,000 produces the rollout sequence, the access model and the policy as a written brief you own outright, whether you run the rollout with us or on your own. The tool is Anthropic's. The sequence is yours to get right.