What Customers Actually Said, and What You Assumed

The founding charter

Ledgerlane has a hero section built from traceable numbers, but nothing yet tells you whether the words in it sound like a contractor's own week. Asking Ida for a customer persona produces a fluent, plausible "Dave, forty-one, runs a two-van electrical firm" — and none of it was said by anyone. It was predicted, not gathered, and researchers call the error reification: treating an inferred sketch as data. The fix is a rule that governs everything else here — a line only counts as evidence if you can name the exact source.

That means going to where UK trade contractors actually write about money in their own words: review sites like Trustpilot and Google Business Profiles (bimodal, capturing fury and gratitude but nothing ordinary), trade forums such as electriciansforums.net threads on tax and bookkeeping and the ContractorUK accounting and legal board, search phrasing, inbound call notes, competitor FAQ pages, and short customer interviews. Each source is named and its bias made explicit — forums skew toward people trying to avoid paying anyone, reviews toward extremes, inbound notes toward people who already bought.

Interviews go wrong through politeness and bad self-prediction, so the chapter turns to the approach from Rob Fitzpatrick's Mom Test method for customer interviews: ask about a specific past occasion, not a hypothetical future, and check whether the person already spent effort on the problem.

The evidence gets logged verbatim — typos and jargon intact — using in vivo coding, Saldaña's coding method for qualitative researchers, keeping the customer's own labels rather than paraphrasing them. Every line then gets marked observation or inference, and inferences get a line-count threshold before they're trusted: three independent sources make a pattern, two an emerging finding, one a hypothesis that stays labelled no matter how appealing it is.

Explain AI-marketing changes and practical shortcuts

Ida gets asked to group the evidence lines by situation, name each cluster from the words inside it, and cite line numbers — removing her room to invent. The result is checked the same way the hero section was: search for the quoted words, and count the cited lines against the actual file, watching for a smuggled-in extra quote that sounds right but isn't there.

A reusable brand brief then gets written once into the project's instructions layer — voice rules, a banned-words list, one accepted and one rejected example — while facts stay in the project's files, since Claude Code's CLAUDE.md hierarchy treats instructions and reference material as separate layers that can silently conflict without a stated precedence rule.

Ledgerlane has one good asset now: a hero section for its landing page where every number can be traced back to a line in the source packet. That is worth something. But it only answers half the question. The words are honest. Nobody has checked yet whether they are the words a contractor would recognise as describing his own week.

So let me show you the mistake that hides in that gap, because it is easy to make and it looks like progress while you are making it.

Open the Claude Project you built, the one called Ledgerlane Marketing, and ask Ida for a customer persona. A persona, if the word is new to you, is a short written sketch of a typical customer: their situation, their pressures, what they care about. Marketers use them to keep a message aimed at a person rather than at everybody. Ask for one and you will get one. Ida writes fluently, and the answer comes back looking like this:

"Dave, forty-one, runs a two-van electrical firm in the Midlands. He works long days on site and does his paperwork late at night. He values peace of mind and hates admin. He wants to feel confident that his tax affairs are handled so he can focus on the work he actually enjoys."

Read it again. It is plausible. It might even be right. Now ask the question that decides whether you can use it: who said that?

Nobody said it. There is no Dave. Nobody told anyone he values peace of mind. That sentence was not gathered, it was predicted. Ida has read an enormous amount of writing about tradespeople and small business, and when you ask for a persona she produces the most likely-sounding paragraph of that kind. That is what the model does, and it does it well. It is not lying to you. It is doing exactly the job you gave it, which was to generate text, not to find out anything.

Here is why it matters more than it looks. Notice that the persona contains nothing you could disagree with. "Values peace of mind and hates admin" will justify almost any copy you were already inclined to write. Want to lead on calm? Peace of mind. Want to lead on speed? Hates admin. The paragraph has no edges, so it cannot stop you from being wrong. Real customer language has edges. Real customer language will tell you that a contractor did not go looking for calm at all, he went looking for someone to deal with a letter, in a particular week, for a particular reason. That is a fact you can build a headline on and defend afterwards.

Researchers have a name for the error. When you take an inferred sketch and start treating it as data, you have reified it: turned an idea into a thing. The dangerous part comes next. Once the persona exists, you start reading real customer comments through it, keeping the ones that fit Dave and skimming past the ones that don't. Your evidence has stopped being evidence and become confirmation. That circularity is hard to see from the inside, which is why the fix has to be structural rather than a matter of being careful.

The fix is one rule, and it governs everything else in this chapter. A line earns a place in your evidence only when you can name the source. Not the type of source. The source: this review, by this username, on this date. If you cannot name it, the line can still exist, but it goes in a different column with a different label. We are going to build that file for Ledgerlane, and we are going to keep those two columns apart inside it.

Where to look, and what each place will lie to you about

Ledgerlane sells monthly bookkeeping to one- and two-van trade contractors in the UK. So we need places where UK trade contractors write about money and paperwork in their own words, without a marketer in the room. There are more of these than most people expect, and each one is bent in a particular direction, which you need to know before you read it.

Start with review sites, because they are the easiest and the most misleading. On Trustpilot's UK site you can look up firms in the neighbouring space: trade-focused accountancy chains like TaxAssist Accountants, and the bookkeeping software contractors actually use, such as FreeAgent, QuickBooks UK and Xero UK. Google Business Profiles are just as useful and more local. Search for bookkeepers and sole-trader accountants in trade-heavy areas and read the client reviews. Checkatrade and TrustATrader are worth a pass too, not for reviews of accountants but for the way tradespeople and their customers describe the working day: twelve-hour shifts, invoicing at eleven at night, no chance of dealing with paperwork during office hours.

When you read reviews, the useful material is not the star rating. In the one- and two-star reviews you find friction, stated plainly and often angrily. In the five-star reviews, look past the praise for the trigger: the sentence that says what was happening in the customer's life when he finally picked up the phone. That trigger sentence is gold, because it tells you when your offer becomes relevant.

Now the bias. Review sites are bimodal, which means the sentiment piles up at both ends and leaves the middle empty. People write reviews when they are furious about a penalty or a surprise fee, or when they have been asked nicely by a firm that just did a good job. Almost nobody writes a review about an ordinary, adequate purchase. So reviews cannot tell you what a routine decision looks like, what price feels normal, or anything at all about the people who considered a service and walked away. They are a map of extremes.

Second source: trade forums and community threads. This is where contractors talk to each other, which is a different register from talking to a supplier. In the UK there is ElectriciansForums.co.uk, with sub-forums on business, advice, regulations and law. There is PlumbersForums.net. The Screwfix and Toolstation community forums have trade and business sections. The ContractorUK bulletin board has accounting and legal boards. UKBusinessForums has an accounts and finance category. On Reddit, subreddits like UKPersonalFinance carry self-employment threads, and there are Facebook groups for UK tradesmen and for self-employed sole traders.

You don't read these front to back. You search inside them for the words attached to your problem: bookkeeper, accountant, receipts, CIS, sole trader tax return, penalty. CIS is the Construction Industry Scheme, under which contractors deduct tax from subcontractors' payments before paying them; it means a lot of trade money arrives already docked, and reconciling that is a common source of confusion and threads. Search terms like that put you straight into the middle of real conversations about the exact thing you sell.

The bias here is different and it will burn you if you miss it. Forums over-represent the tradesperson who is comfortable online, likes solving things himself, and is actively looking for a way to avoid paying professional fees. That is a self-selected crowd. You will read ten posts explaining how to do your own return and conclude that nobody wants to pay for bookkeeping. Meanwhile the contractor who would happily hand over a hundred and eighty pounds a month tomorrow, purely to never think about it again, is not on the forum. He is not on any forum. He is the customer. So forums give you excellent language about the problem and unreliable signals about willingness to pay.

Third: the phrasings people type into search. This is a source of wording rather than of stories, and there are free ways in.

The simplest is Google's own autocomplete. Set yourself to the UK site, start typing a stem like "sole trader bookkeeping" or "do I need an accountant if", and read what Google offers to finish it with. Those completions are built from real queries. Then run a full search, something like bookkeeping for self-employed builder, and open the People Also Ask box, the expanding accordion of related questions. Those are real question strings in real phrasing. Scroll to the bottom of the results page for the related searches, which often surface regional wording you would not have guessed.

Beyond that: Google Trends, set to the United Kingdom, shows you seasonality, and for this offer seasonality is a real feature. Interest in self-assessment terms spikes as the January deadline approaches. Google Keyword Planner, inside a Google Ads account, gives you UK search volumes and question-shaped terms from seed keywords, and you can use it without running ads. AnswerThePublic and AlsoAsked both take a seed term and produce a branching map of the questions people actually ask around it, organised by the question word: why, how, can, what. Set both to the UK.

The bias in search data is that it is dominated by people trying to solve the problem themselves for free. Someone typing how do I claim van expenses is usually looking for HMRC guidance, not a bookkeeper. Search phrasings tell you the words in people's heads with real accuracy. They tell you almost nothing about whether the person has any intention of hiring anybody, or any money to do it with.

Fourth: your own inbound questions. For Ledgerlane, illustratively, this means the free-text answers on the contact form, the notes from first calls, and the notes on deals that were lost. These are your best material, because they come from people who reached you about this specific offer. The first-call question worth asking is what made you pick up the phone this week, and the answer is often one sentence long and better than anything you'd write. Lost-deal notes are equally valuable: they hold the objection in the customer's own words, things like the wife does the books, or I can't justify that monthly.

Their bias is survivorship. Everyone in that file crossed a threshold: they noticed the problem and did something about it. That means your inbound notes cannot tell you why the other visitors read the page and left, or what keeps a contractor content with the arrangement he already has.

Fifth: competitor pages. Look at the service pages and frequently-asked-questions sections of bookkeepers who serve trades. Notice which headings are phrased as customer questions. Those headings are a competitor's summary of the objections they get often enough to pre-answer, which is useful intelligence gathered at somebody else's expense. Their bias is promotional. Every testimonial on that page was selected. You will never learn from a competitor's site what their prospects found confusing, or what made someone choose not to buy.

Sixth: short interviews with a handful of existing customers. Four or five is enough to change your mind about something. But interviews go wrong in a specific way, and the way they go wrong is that people are polite and people are bad at predicting themselves. Ask a contractor "would you pay sixty pounds a month for automated receipt capture?" and he will say probably, yeah, because that is a friendly thing to say to a stranger who clearly wants to hear it. The answer is worthless.

The dependable approach, set out in Rob Fitzpatrick's book The Mom Test, is to stop asking about the future and ask about the past. Three rules do most of the work. Ask about things that already happened rather than pitching the idea. Anchor on a specific recent occasion: talk me through the last time you did your invoicing, or what happened with your return this January. And check whether the person has already spent time, money or effort on the problem. If a contractor tells you paperwork is a nightmare but has never once tried a spreadsheet, an app, or his sister-in-law, that reported frustration is weak evidence that he will ever pay to fix it. Effort already spent is the signal. Complaints are cheap.

That is the map. Six sources, each of which can be named, each of which distorts in a known direction. Notice what that gives you together: forums and reviews for wording, interviews and inbound notes for buying behaviour, search for the phrasing of the question. No single one of them would have been enough.

Now build the file. It is a spreadsheet and it stays boring on purpose. Six columns. The verbatim quote, in quotation marks. The source, as a direct link to the actual comment or review. The author's username or handle. The date it was published. A short problem category. And a rough note on how strong the feeling is.

The rule while capturing is that you do not clean anything up. Copy the words exactly, including typos, slang and trade jargon. Keep subbie. Keep shoebox of receipts. Keep whatever mangled phrasing the person used, because the wording is the whole asset. The moment you tidy a quote into professional English you have destroyed the thing you went to get. Also record the situation around the quote where you can see it: the January deadline, the letter that arrived, the new van.

Here is what a first pass might look like for Ledgerlane. Every one of these lines is invented for the example, because Ledgerlane is an invented business, so treat them as illustrations of shape rather than findings about real contractors. In a real file, each would carry its link and its date.

Line one, from a forum thread: "found the letter under the seat of the van three weeks late." Line two, from a review of a bookkeeping firm: "I rang them the day after the fine landed." Line three, forum: "I've got a carrier bag of fuel receipts on the passenger seat and no idea what CIS has been deducted." Line four, first call note: "The wife used to do it but she's back at work now." Line five, review: "It was the year-end bill that did it, four grand out of nowhere." Line six, forum: "I'm not paying an accountant three hundred quid to type numbers off my bank statement." Line seven, autocomplete stem, so a search phrasing rather than a person: "do I need an accountant if I'm a sole trader." Line eight, lost-deal note: "Can't justify the monthly at the minute, ask me after Christmas." Line nine, forum: "Every January I swear I'll keep on top of it and every January I don't." Line ten, first call note: "I just want someone to tell me what I owe before I spend it." Line eleven, review: "They wanted everything in their own software, I gave up." Line twelve, interview: "I hand my paperwork over to my sister-in-law once a quarter."

Twelve lines, each with a source. That is more useful than any persona, and it took an afternoon.

Then comes the move that makes the file trustworthy. Go through and mark each line as one of two things. Observation, or inference.

An observation is a verbatim quote of someone describing something that happened or something they did. Line one is an observation. The letter, the seat of the van, three weeks late. Someone typed that. Qualitative researchers call this kind of coding in vivo, a term Johnny Saldaña uses for taking the participant's own words as the label rather than paraphrasing them. The point of keeping labels verbatim in the first pass is that it stops your interpretation from quietly replacing the customer's voice before you have even finished reading.

An inference is what you conclude from observations. "Contractors need mobile-first receipt capture" is an inference. It is a reasonable one — look at lines one and three, both describing paper loose in a vehicle — but nobody said it. If you write that sentence into your file without a label, then in two weeks it will read exactly like a quote, and you will build a headline on it believing a customer handed it to you.

So mark it, and cite it. The inference goes in its own column, and beside it you write which line numbers it came from. Contractors capture receipts away from a desk, in a vehicle: lines one and three. Now anyone, including you in a month, can look at that inference and immediately see how much weight is under it.

Which brings up the question of how much is enough. A single statement from one person is an anecdote, not a pattern. The convention is straightforward. If three or more independent sources say something compatible and nothing contradicts it, you have a pattern you can act on. Two independent sources make it an emerging finding, promising and provisional. One source is a hypothesis, and it stays labelled as a hypothesis no matter how much you like it.

Work that through on our file and watch it bite. The trigger inference — a contractor acts when a penalty or a bill arrives — draws on line two, the fine, line five, the four-grand year-end bill, and line one, the late letter. Three independent sources, nothing against it. That is strong enough to put in a headline, which is convenient, because Ledgerlane's audience paragraph already assumed it. Now it is not an assumption.

Compare that with line twelve, the sister-in-law. The inference you'd draw is that Ledgerlane's real competition is not other bookkeepers but informal family arrangements. That is an interesting idea. It might change the whole message. And it rests on exactly one line, from one person. Line four, the wife who used to do the books, is adjacent but not the same claim; it describes an arrangement that ended rather than one that competes. So the family-competition inference gets recorded like this: the inference in the column, the source noted as one line only, and a status marking it as thin, to be tested in the next interview before it goes near positioning.

You do not delete it. Deleting it loses the idea, and it might be the most valuable idea in the file. You label it. The labelled version is safe to keep around, because the label is what stops it being promoted to fact when you are tired and drafting at speed. The general rule is worth stating plainly: nothing marked thin goes into core messaging until something independent corroborates it.

And notice that inference is not the enemy here. You cannot write copy from raw quotes alone. Copy requires you to generalise, to decide that these five people represent a category of buyer, and to name a benefit nobody articulated in those words. That is the job. It is only dangerous when it is unlabelled, because next chapter's positioning decisions will rest on some of these inferences, and someone has to be able to ask which ones and get an answer.

Now put Ida on it, properly this time. The difference between the persona request and this one is that this one gives her material and takes away her licence to invent.

Upload the evidence file to the Ledgerlane Marketing project and make the request specific. Group these lines by the situation they describe. Name each group using words that appear in the lines themselves. For each group, list the line numbers it came from. Do not add any line that is not in the file, and do not smooth any wording.

That set of instructions is doing four separate jobs, and it is worth seeing them. Grouping by situation, rather than by feeling, keeps the clusters tied to circumstances you could design copy for. Naming from the customers' own words is in vivo coding done by machine, and it prevents Ida from renaming a cluster of angry, specific quotes as something bloodless like Administrative Burden. Requiring line numbers gives you an audit trail, so every group can be checked against its evidence in ten seconds. And the instruction against adding lines addresses the failure mode you already know she has, since her standing project instructions already tell her to flag missing facts rather than invent them; here you are naming the specific thing not to invent.

A good result comes back looking like clusters with ugly names. Something like "found the letter late," covering lines one and two. "Receipts in the van," lines one and three. "Somebody else used to do it," lines four and twelve. "Not paying that to type numbers," lines six and eight. Those names are ugly because they are quotations, and that is the sign they are right.

Then inspect it exactly as you inspected the hero section. Two checks. First, take each group name and search the file for those words. If Ida has named a group "peace of mind" and that phrase appears nowhere in twelve lines, she has drifted back into predicting. Rename it from a line that is actually there. Second, count. Add up the line numbers cited across all the groups and see whether any number appears that your file does not contain, and whether any quoted fragment in her summary differs from your wording.

She will sometimes smuggle in a plausible extra. It usually looks like a thirteenth quote that fits the pattern beautifully, phrased slightly more neatly than the rest. When that happens, do not argue with her about it in the chat and do not accept a corrected version on trust. Delete the extra, then re-run the grouping request on the unchanged file. You are not disciplining the assistant. You are protecting the property that makes the file worth having, which is that everything in it has a source.

So what is true now that was not true this morning. You have a set of named sources for contractor language and you know which way each of them leans. You have a file of verbatim lines with sources and dates. You know which of your beliefs about this customer are observations, which are inferences with three lines under them, and which are single-source hypotheses wearing a confident face. You know that the penalty-or-bill trigger is supported rather than assumed, and you know that the family-arrangement idea is not yet supported at all.

What is missing is also clearer than it was. The file has almost nothing from contractors who considered a bookkeeper and decided against one, because none of these sources reach them well. There is nothing about what price feels normal, since reviews won't tell you and forums will tell you wrong. And the thin lines need testing, which gives you your questions for the next interview: what did you do with your paperwork before you called anyone, and who does it now if not you, and what did you spend on it. Past behaviour, specific occasion, effort already committed.

The message itself has not been written. Ledgerlane still has one hero section, unchanged. What it has now is the evidence a message could be argued against, which is a different thing and comes first.

A brief you write once

There is a shortcut worth setting up while the tone work is fresh, because you have now inspected voice twice and you have a real brand example in the packet. Rather than describing Ledgerlane's voice in every request, write it down once in a place the assistant reads automatically.

Assistant project workspaces keep rules in two layers, and knowing which layer to use saves you grief. Project instructions are the behavioural layer: role, tone, things never to say, how to handle conflicts. They go into the context on every turn of every conversation in that project. Project files are the factual layer: the product sheet, the brand example, and now the evidence file. In Claude Projects the instructions field takes plain text or markdown at whatever length you like, and project knowledge holds up to two hundred thousand tokens of reference material, which is far more than this offer will ever need. In ChatGPT Projects the instructions field is smaller, roughly five to eight thousand characters, with file attachments capped at around twenty to twenty-five on standard plans. Either way, rules go in instructions and facts go in files.

The brand brief goes in the instructions field, and it has four parts. Voice rules, stated as things to do and not do. A banned list. One acceptable example. One rejected example.

For Ledgerlane it reads roughly like this. Voice: short sentences, active voice, plain words a contractor would use, no more than one idea per sentence. No conversational opening — give the copy, not "Sure, here's a draft." Never use the words seamless, effortless, revolutionary or game-changer. Never use peace of mind. Then the claims list: every price, timing or scope statement must cite the file it came from, and anything not in the files gets written as unverified rather than estimated. Add the two rules the inspection taught you, so the two-week onboarding claim always carries from signing, and any page that names what is included also names what is excluded. Then add one line the evidence file does not support and ban it explicitly: no claim that Ledgerlane chases invoices, and no claim about saving a number of hours per month, because nothing in the packet or the evidence establishes either.

The acceptable example is a sentence from the saved hero section. The rejected example is a sentence from the ungrounded draft, kept deliberately, with a note of what is wrong with it. Examples do more than adjectives here, because "direct" means many things and a sentence means one.

One structural rule matters more than it looks. Assistants have no compiler deciding which source wins when your instructions and your files disagree. In practice, instructions tend to dominate on tone and files on facts, but without a stated rule a contradiction can produce a confident blend of both. So write the precedence in: these instructions override the attached files on voice, the files govern facts, and if two files disagree, flag it rather than choosing.

Then test whether the brief actually saved you anything, because that is the only measure that counts. Open a new chat in the project and give a bare request with no style reminders at all — a three-bullet summary of what Ledgerlane includes, say. Check four things in the answer. Did it skip the conversational padding. Are all the banned words absent. Did it cite the source file for the price, or mark a missing figure as unverified instead of guessing. And can you use the text as it stands without a correction prompt. Four out of four means the brief is being inherited and you have stopped paying for tone in every request. Anything less tells you which rule to make more specific, and negative rules and if-then conditions hold up better than open-ended requests to be engaging.

The brief holds rules. It does not hold evidence, and it cannot make a claim true. That is what the file you built this chapter is for.