The call I get now is not "should we use AI". That argument is over. The call is "we've paid for Claude, three people have logged in twice, and nothing has changed. What are we doing wrong?"
Usually nothing dramatic. They bought a subscription and called it a rollout. Those are different things, and the gap between them is where most of the money goes.
I build with Claude Code every working day and I've set it up properly for a handful of small businesses now. Here's the order I do it in.
Do not roll it out in week one
The instinct is to buy seats for everyone and announce it at a team meeting. Resist that. What happens is twelve people each spend forty minutes asking it to write a limerick, decide it's a toy, and never open it again. You have then burned the one moment of genuine curiosity you were going to get.
Start with one person and one job. Ideally the person is whoever in the business is already slightly too interested in this stuff, because they'll push through the awkward first fortnight without needing to be managed. Everyone else comes later, once there is something concrete to show them.
Pick the job before you pick the tool
"We want to use AI to be more efficient" is not a job. "Rachel spends six hours a week turning site survey notes into quotes" is a job.
Good first candidates share three traits: they happen weekly or more often, they involve turning one kind of text into another kind of text, and getting them slightly wrong is cheap. Quotes from notes. Meeting notes into actions. Long supplier documents into a summary someone will actually read. Draft replies to the same eight customer questions.
Bad first candidates: anything where being wrong is expensive, anything regulated, anything that needs a fact the model has no way of knowing. I've written elsewhere about what can and cannot sensibly be automated, and the shape of that list has not changed much.
Projects are the part most people miss
If your staff are using it as a chat box, starting fresh every time and re-explaining the business in every message, they are doing the equivalent of introducing themselves to a colleague every morning.
Projects fix that. A project holds a set of files and a set of standing instructions, and every conversation inside it starts already knowing them. Set up one per recurring job rather than one per person. Into the quoting project goes your price list, two examples of a quote you were happy with, and your terms. Into the customer replies project goes your tone of voice and the twenty questions you actually get.
This is the step that turns generic output into output that sounds like your company. It takes an afternoon. It is worth more than the subscription.
Write the instructions like an induction, not a prompt
The custom instructions on a project are the highest-value writing you will do in this whole exercise, and almost nobody spends long enough on them.
Do not write prompt-engineering incantations. Write what you would tell a competent new starter on day one. What the company does. Who the customer is. How formal to be. What we never say. What to do when it doesn't know something, which should always be "ask, don't guess".
That last instruction is the one that saves you. A model with no instruction about uncertainty will produce a confident, plausible, entirely invented figure. A model told to flag gaps will leave you a hole to fill in.
Connectors: ask the boring question first
You can wire it into the systems you already run, so it can read a document in your drive or pull a thread out of your chat tool without anyone copying and pasting. That is the point at which it stops being a novelty.
Before you switch one on, ask the boring question: what exactly can it see now, and who in this company is allowed to see that? A connector inherits the permissions of whoever set it up. If that's a director with access to everything, you have just given every conversation a view of the payroll folder. That is not a flaw in the software, it's a filing problem you already had, and the connector is what makes you notice.
Turn on one, use it for a fortnight, then turn on the next. The businesses that connected everything on day one are the ones who later could not tell me why an answer contained a number from a document nobody meant to share.
Decide what goes in, in writing
You need one page saying what staff may and may not paste in. Client data, personal data, anything under an NDA, anything with card details in it. Read the terms of the specific plan you are on, because the treatment of your data differs between the consumer tiers and the business ones, and it is the sort of thing that gets updated.
One page is enough. If it runs to nine pages nobody reads it and you have achieved nothing except a document. I've gone into this properly in the note on what AI governance actually means at this size.
How to tell whether it worked
Measure the one job you picked, and measure it in hours, not vibes. Rachel's six hours a week either became two or it didn't. If it did, you now have the internal case study you need to bring in the next person, and it cost you a fortnight instead of a rollout.
If it didn't, the usual cause is that nobody set up the project properly and everyone is back to typing into an empty box. Second most common: the job was a bad candidate and needed a fact the model was never going to have.
What I'd actually do on Monday
Pick one job. Pick one person. Build a project with real examples in it, spend two hours on the instructions, and leave the connectors switched off for the first fortnight. Review it at the end of the month with a number in your hand.
That's it. The businesses getting real value out of this are not the ones with the cleverest prompts. They are the ones who treated it as a small internal project with an owner and a deadline, instead of a subscription and a hope.
If you are still at the stage of deciding which one to buy, the comparison with ChatGPT and the note on whether Claude suits a small business at all are the better starting points. And if you'd rather not do the setup yourself, that's a thing I do.
If you are trying to work out where AI actually fits in your business, get in touch and I will give you a straight answer before you spend anything.
Setting up Claude, answered
Common questions about turning a Claude subscription into something that actually gets used.
You bought a subscription and called it a rollout. They are different things. Nearly always the fix is to stop treating it as something everyone discovers alone, and instead set it up around one person and one real job first. The curiosity you get at the start is a one-time thing, so do not waste it on a team-wide free-for-all.
Start with one person and one job, not seats for everyone. Pick whoever is already slightly too interested in this stuff, because they will push through the awkward first fortnight without being managed. Get one concrete result, then use it to bring the next person in. A big launch announcement usually ends with people deciding it is a toy.
Something that happens weekly or more, turns one kind of text into another, and is cheap to get slightly wrong. Quotes from site notes. Meeting notes into actions. Long supplier documents into a short summary. Draft replies to the same handful of customer questions. Avoid anything where being wrong is expensive as your first try.
No. That is the most common and most expensive mistake. A dozen people each spend forty minutes asking it for a limerick, decide it is a toy, and never open it again. You have then burned the one bit of genuine curiosity you were going to get. Earn the wider rollout with a result people can see first.
Faster than people expect once it is pointed at the right job, and never if it is left to everyone to figure out alone. The work is not technical, it is choosing the task, setting one person up properly, and building from a win. If you would rather not run that yourself, it is exactly the kind of setup I help with.