Lesson 01
Stop asking questions. Give it a job.
The single biggest jump in output quality comes from changing the shape of your request. A question gets you an answer. A brief gets you work. Tell it who it is writing for, what the constraint is, and what the finished thing should look like.
Try this
You are helping me prepare for a board meeting on Thursday.
Here are my notes from the last quarter. Draft a one-page
update for non-technical directors: what changed, what it
cost, what I need a decision on. Plain English, no jargon,
under 400 words. Flag anything in my notes that looks like
a claim I should check before I put it in front of them.
What good looks like: a usable draft, plus a short list at the end of things it was not sure about. That second part is the tell that you briefed it properly.
The gotcha: people write one line, get a generic answer, and conclude the tool is weak. The output quality tracks the input almost exactly. If you would not hand that instruction to a new staff member and expect good work, do not hand it to Claude either.
Lesson 02
Give it the long document, not your summary of it
This is where Claude is genuinely strong, and it is the reason we reach for it on hard reading. It holds a lot of material at once without losing the thread, so it stays coherent across a long contract or a sprawling report rather than forgetting the start by the time it reaches the end.
Try this
Attached is our supplier agreement. I am not a lawyer and
I am not asking for legal advice. Give me: the obligations
that fall on us, every date or notice period we have to
meet, anything that auto-renews, and the three clauses a
reasonable person would push back on. Quote the clause
number for each point.
What good looks like: answers anchored to clause numbers you can go and check. If it will not tell you where something came from, treat the claim as unverified.
The gotcha: do not paste your own summary and ask it to analyse that. You have already thrown away the detail that made the exercise worth doing. Give it the source document.
Lesson 03
Use Projects so you stop re-explaining your business
A Project is a persistent workspace that holds context across every session: your brand guidelines, your templates, how your business actually works. Set one up once and every conversation inside it starts already knowing who you are.
The practical version for a small team: one Project per recurring job. A "Client proposals" project holding your tone of voice and two past proposals you were happy with. A "Board reporting" project holding last quarter's pack. A "Policies" project holding the documents people keep asking about.
Try this
Using the two proposals in this project as the model for
tone, structure and pricing layout, draft a proposal for a
40-seat manufacturing client who needs managed IT and has
asked specifically about cyber insurance requirements.
What good looks like: output that sounds like your firm rather than like a chatbot, because it has your previous work to pattern-match against.
The gotcha: people put nothing in the Project and wonder why it behaves like a blank chat. The Project is only as useful as the material you load into it.
Lesson 04
Make it show its working before it does the work
For anything that matters, ask for the plan first. You catch a wrong assumption in ten seconds instead of reading two pages of confident, wrong output and having to work out where it went off.
Try this
Before you write anything: tell me how you intend to
approach this, what you are assuming, and what you would
need from me to do it properly. Do not start until I say go.
What good looks like: a short plan with its assumptions made explicit, including at least one thing it genuinely cannot know and had to guess.
The gotcha: it can be wrong while sounding completely certain. That is true of every tool in this category. The plan-first habit is the cheapest defence there is, and it is the habit that separates people who trust the output appropriately from people who trust it too much.
Lesson 05
The Monday brief
The Small Business plugin ships with prebuilt workflows you invoke by name. /monday-brief gives you a start-of-week snapshot: cash, sales, pipeline, and your top three things to do. It is the one we would switch on first, because it takes a job that quietly eats an hour every Monday and returns it as a two-minute read.
Try this
/monday-brief
Then refine it once, so it matches how you actually run the week: "Keep it to one page. Put cash first. I do not need the marketing numbers on a Monday."
The gotcha: the workflow is only as good as the systems connected to it. Run it before you have connected anything and you will get a polite, empty template. Connect the finance system first. See lesson 7.
Lesson 06
Month-end close and the numbers that come with a story
/close-month reconciles and writes the narrative to go with the profit and loss. The narrative is the point. Most small businesses produce accurate monthly numbers that nobody reads, because the numbers arrive with no explanation of what changed or why.
Try this
/close-month
Then: explain the three biggest movements against last
month in language my operations manager will understand.
For each one, say whether it looks like a timing difference
or a real change in the business.
What good looks like: a narrative you could paste into a board pack, with the movements attributed rather than just listed.
The gotcha: it is writing a narrative, not auditing your books. If the underlying reconciliation is wrong, you now have a confident story about a wrong number. The close still needs a human who knows the business to sign it off.
Lesson 07
Connect the systems the work actually lives in
Connectors are what turn Claude from a writing tool into something that can do your admin. The Small Business set covers QuickBooks for payroll planning, the monthly close and cash flow, PayPal for settlements, invoicing, disputes and refunds, HubSpot for lead triage and campaign attribution, Canva for content, and Docusign for getting contracts signed and filed back.
Connect the one that owns your most repetitive job. For most businesses that is finance, because chasing invoices and forecasting cash are the tasks that recur weekly and get deferred.
Try this
Look at our overdue invoices. Group them by how late they
are and how much is owed. For anything over 30 days, draft
a chase email in a firm but friendly tone, one per client,
and show me all of them before sending anything.
The gotcha: "and show me all of them before sending anything" is not optional. Connect a system that can act on the outside world and you have changed the stakes of a bad instruction. Keep a human between the draft and the send until you have watched it behave for a few weeks.
Lesson 08
Cowork: hand over the whole job, not the next step
Cowork is the agentic side. You give it an outcome rather than a task, it breaks the project into chunks, works through them, and comes back when it needs a decision from you. You either approve the plan first, or let it run end to end once you trust it.
Anthropic's own analysis of Cowork usage found the largest category was business process work, reports, checklists and spreadsheets, and that the overwhelming majority of use was not software development. This is an admin tool that happens to also write code, not a developer tool.
Try this
Outcome: I need our new-client onboarding pack ready to
send. That means a welcome letter, a checklist of what we
need from them, and a one-page summary of who to contact
for what. Use the tone from the proposals in this project.
Show me your plan before you start.
The gotcha: start with "show me your plan" every time until you have a feel for how it scopes work. Approving a plan takes fifteen seconds. Unpicking a confidently completed job that solved the wrong problem takes an afternoon.
Lesson 09
The safety lesson, which is mostly about what you paste
On Team and Enterprise plans, Anthropic does not train on your data by default. That answers the question most business owners ask first, and it is the reason we steer teams onto a business plan rather than letting everyone use personal accounts.
The risk that remains is not the vendor, it is the habit. Personal free accounts scattered across your team, client data pasted into whichever tool is open, and no agreed line on what is fair game. That is the pattern we see when we take over an environment, and it is a governance problem rather than a technology one.
Three rules that cover most of it: one business plan rather than personal logins, an agreed list of what must never be pasted anywhere, and a named person who owns the answer when someone asks whether a particular use is allowed.
The gotcha: banning it does not work. People use it on their phones instead, and you lose the visibility you had. Making the safe way the easy way is the only approach we have seen hold.
