6. An Offer Page That Answers the Penalty Letter

The reply to the penalty letter is saved. So is the short offer-page section that went with it. Both passed their audits. Now the offer page has to stand on its own, for a contractor who never wrote in and is reading alone on a phone at nine at night.

An offer page is the single web page that explains one offer and asks for one action. For Ledgerlane, that offer is monthly bookkeeping for one- and two-van trade contractors. The action is booking a short diagnostic call. A useful way to think about the page is as a promise put in order. Every section answers the question the reader has at that moment. Every sentence still traces back to a row in the facts register or a line in the evidence file. This chapter does both. It sets the order, finds the objections, asks Ida for a draft, fixes what she gets wrong, and checks the result at phone width.

Putting the promise in order

Start with the reader. The visitor this page is built for is what copywriters call problem-aware. They know they have a problem. A penalty letter arrived, or a tax bill was bigger than they expected. But they don't yet know which kind of help fits, or who offers it. Research on conversion copy and usability work from the Nielsen Norman Group point to a common pattern for this reader. Show them their own problem first. Then explain how the help works. Then say what it includes, prove it, price it, deal with doubts, and ask for one low-risk step.

That pattern is a guide, not a law. Ledgerlane's page follows it with one change, and the change comes from Ledgerlane's evidence. Here is the order, and why each part sits where it does.

The first section is the trigger, written in the customer's own words. This is the part of the page a reader sees before scrolling. People call that "above the fold", a phrase from newspapers. The top half of a folded paper was what you saw on the stand. On a phone, the fold is the bottom of the screen when the page first loads. The research is plain about this spot. Mirror the visitor's symptoms and vocabulary right away. Opening with credentials or a vague slogan makes more people leave. For Ledgerlane, the strongest trigger in the evidence file is the penalty-or-bill moment from lines one, two and five. So the top of the page names that moment the way contractors described it. It doesn't open with "expert bookkeeping".

The second section says what Ledgerlane does and when. The research calls this the delivery model. It means explaining how the help works before listing features. Ledgerlane's brief already settled the angle. The real competitor is the accountant who looks at the books once a year, plus doing nothing. So Ledgerlane doesn't claim to be better than that accountant. It claims a different timing. The books get done every month, not once in January. That is the when-not-how-good difference, and it needs no proof beyond the inclusion rows that describe the monthly work.

The third section is the price, with what it includes. This is where Ledgerlane moves away from the research order. In the research order, proof comes before pricing. Ledgerlane puts price earlier for two reasons. First, the research also says that a missing price is a main frustration for business buyers. When the price is missing, people tend to assume the service costs too much. Second, Ledgerlane's price is its clearest, best-sourced fact. The one-van fee is a hundred and eighty pounds a month and the two-van fee is two hundred and sixty. Both come from the price list, are owned by the founder, were checked on the twenty-second of September and are current. The four inclusion rows sit right beside the price, so the reader sees what the money buys.

The fourth section is the exclusions, used as a filter. Ledgerlane has three exclusion rows, and penalty appeals are outside its scope. Putting these next to the price does a job the research describes. Answer a doubt next to the content that raises it, and keep the FAQ for broader questions. A contractor who needs an appeal handled learns that here, before booking a call that won't help. That saves their time and the founder's.

The fifth section is proof. For Ledgerlane, this section is short, and it should stay short. The research names proof as case results, client quotes and before-and-after evidence. Ledgerlane is an illustrative business with none of those yet. The brief limited proof to product facts and checkable HMRC timings, and that limit holds. So proof here means facts a reader could check. One is the setup, about two weeks from signing, which comes from the onboarding checklist. Another is the HMRC Self Assessment dates and penalty stages from the register. A testimonial added because the page "needs one" would be invented, and the page goes without.

The sixth section is objections. An objection is a reason a reader gives themselves for not acting. It might be "I already have someone for this," or "it's too late," or "it costs too much." The research's advice is to treat the FAQ as an engine, not a junk drawer. Each question should match a real hesitation, and it should be phrased the way a visitor would say it, not in company language.

The last section is the call to action. That is the single step the page asks for, usually a button. The research says the button label should name the actual action. "Submit" and "Get started" tell the reader nothing. "Book a diagnostic call" says what happens. The research also suggests a short line under the button that sets expectations, such as how long the call takes or how fast you'll hear back. That advice comes with a trap for Ledgerlane. The register has no row for call length or reply time. A line like "we reply within one working day" would be a new fact with no source. So that line stays blank until the founder supplies a row. The blank goes on the list of questions for the owner.

Finding the objections in what customers already said

It's easy to write objections from imagination, and those don't count. A believable list of doubts is just a persona in disguise, and the course has already shown that a made-up persona tells you nothing about real customers. So the rule for this list matches the rule for the brief. A candidate objection must come from a category in the evidence file and its lost-deal notes. If it doesn't, it gets labelled a hypothesis. Each answer has to cite a row or say clearly what isn't known.

Three candidates come up. Each one gets a different answer.

The first is "My accountant does this once a year." This has the strongest support. The brief's competitor was built from evidence: the year-end accountant plus inertia. So the objection belongs to an evidenced category. The answer doesn't argue that the accountant is bad. It repeats the timing difference. Ledgerlane does the books every month, the inclusion rows say what that means, and the accountant can still do the year-end work. Wait, though. Can they? The register says nothing about whether Ledgerlane works alongside a contractor's accountant or hands records over. A sentence promising that would be easy to write and would have no source. So the answer says what the inclusions cover. A new question goes to the owner: does Ledgerlane hand records to an existing accountant, and how?

The second is "Software is cheaper." This is labelled a hypothesis. It sounds likely, but likely is not observed. Unless a line in the evidence file shows a contractor saying it, it doesn't count as proven. It can still go on the page as a question, because answering a doubt that turns out to be rare costs little. But the answer is limited. Ledgerlane's own price can be stated from its row. No price for any software can be given, because the register holds none. Comparing to a figure nobody checked would break the rule that numbers keep their conditions. The honest answer is narrower. Software records what you enter. Ledgerlane's fee covers the four listed inclusions, done for you. Whether that's worth the difference is the reader's decision, and the page doesn't make it for them.

The third is "Is it too late this year?" This is also a hypothesis as an objection. It follows from the penalty trigger, but no line quotes it. It's the most dangerous one to answer, because the tempting answer is a guarantee. "It's never too late, we'll get you sorted" is the reassurance the brand guide bans. It also runs into the advertising-code limits recorded in the brief. Under the CAP Code, the UK advertising code, the page can't promise or imply an outcome that depends on HMRC. What the page can say comes straight from the register. An online return is due by the thirty-first of January. A return up to three months late gets a fixed hundred-pound penalty. Later stages add ten pounds a day for up to ninety days, then three hundred pounds or five percent at six months and again at twelve. Setup takes about two weeks from signing. Those are facts with their conditions attached. What the page can't say is whether it's too late for this particular reader. That depends on their tax year and whether they've filed, and the page doesn't know either. So the answer ends by naming those two unknowns. The diagnostic call is where they get answered.

Notice what that third answer does. A diagnostic call is the right next step because the page admits what it doesn't know. The call to action grows out of the unknowns. It isn't a sales trick.

The request to Ida

With the order and the objections settled, Ida can draft. The request goes in a new chat inside the Claude Project called Ledgerlane Marketing. The brief, the register, the brand guide and the evidence file are already there as project files. Her standing instructions apply automatically. Still, the request names everything it relies on. A named source is easier for her to use and easier for you to check.

In plain words, the request says this. Draft a full offer page for Ledgerlane from the saved audience-and-offer brief, the product-facts register and the brand guide. Use seven sections in this order: the trigger in customers' words, what Ledgerlane does and when, the price with its inclusions, the exclusions, proof limited to product facts and HMRC timings from the register, objections, and a call to action to book a diagnostic call. For objections, use only the three listed. Label the second and third as hypotheses in your notes, not on the page. After every sentence, add a tag in brackets naming the register row or evidence line it rests on. A sentence with no source gets the tag "no source", so it can't hide. Don't write the line under the button, because no row supports a call length or reply time. At the end, list every row used with its checked date. Then list unknowns in two groups, questions for the customer and questions for the owner.

The tag-per-sentence rule matters most. It turns the audit into a search. You don't have to reread the page and hope you spot a problem. You look at each tag and open the row.

Inspecting the first draft

The draft below is illustrative. Its faults follow the pattern the course keeps recording. Fluent copy slips in claims the sources don't hold.

Most of it is sound. The trigger section uses the penalty-letter wording. The price section gives a hundred and eighty and two hundred and sixty pounds, tagged to the price rows. The exclusions are listed and tagged. Three sentences fail.

The first failure is a reassurance line. At the end of the trigger section, Ida wrote, "Relax. We'll take the stress off your shoulders." It's tagged to evidence line two, which is a contractor describing stress. The tag points at a true line, but the line doesn't support the sentence. Line two shows the stress exists. It doesn't show Ledgerlane removes it. This is the same misused citation the penalty-letter reply had. The brand guide's rule about reassurance in place of information settles it. The fix is to cut the line. The sentence after it, which names monthly books and the two-week setup, does the real work.

The second failure is an uncited claim about saving time. In the "what we do" section, Ida wrote, "Save hours every week on paperwork." It's tagged "no source", so the tag rule worked. She flagged her own gap, which is the point. No row measures hours saved, and no evidence line quotes a contractor on time spent. The fix is to replace it with what the inclusion rows actually say Ledgerlane does each month. The reader can judge the time saved for themselves.

The third failure is a penalty figure that lost its condition. In the proof section, Ida wrote, "HMRC charges £100 for a late return." It's tagged to the penalty row, and the row is correct. But the sentence dropped the row's condition. The hundred pounds applies to a return up to three months late. After that, the amount grows. Stated bare, it's false for many readers and could make the risk look smaller than it is. The fix copies the full condition from the row.

One revision pass handles all three. The request is short. Remove the reassurance line. Replace the time claim with the monthly inclusions from their rows. Restate the penalty with its full condition from the row. Confirm that no sentence on the page promises or implies a result from HMRC. That last check is the CAP Code limit, run once more across the whole page, because a guarantee can appear anywhere, not only where you expect it. The revised draft comes back with every sentence tagged to a row or line. No "no source" tags remain. The row list gives the price, inclusion, exclusion, onboarding and HMRC rows with their checked dates. The owner questions now include call length, reply time and handover to an existing accountant.

Looking at it on a phone-sized screen

Most contractors will read this on a phone, often in a van between jobs. A page that looks tidy on a laptop can fall apart on a narrow screen. So the last check happens at phone width. Two things matter here: line length and where the button lands.

You don't need a phone to start. In the Chrome browser, open the draft page and open the developer tools. The F12 key does it, or Control, Shift and I on Windows, or Command, Option and I on a Mac. Then turn on the device toolbar with Control, Shift and M, or Command, Shift and M on a Mac. Under Dimensions, choose Responsive and set a width between three hundred and twenty and three hundred and ninety pixels. That covers common phone sizes. Know the limit of this tool. Chrome is imitating a phone on a desktop computer. It doesn't run a real phone's software or hardware. So a final look on an actual phone is still worth doing.

At that width, check line length first. Readability guidance aims for about forty-five to seventy-five characters per line. The web accessibility guidelines set eighty as an upper limit. At phone width, long lines are rarely the problem. The common fault is the reverse. A heading, or a price line with its condition, breaks into two- and three-word scraps that are hard to follow. The penalty sentence, now carrying its full condition, is the one to watch. If it reads badly in short pieces, fix the layout, not the wording. The condition stays.

Then check the button. "Book a diagnostic call" should be easy to tap, with space around it so a thumb doesn't hit the wrong thing. The accessibility guidelines set a minimum target of twenty-four by twenty-four pixels, and forty-four by forty-four at their stricter level. If the page uses a button stuck to the bottom of the screen, scroll the whole page. Make sure it never covers the exclusions or the penalty condition. A sticky button that hides the facts which filter readers out undoes the work of putting those facts next to the price.

That is as far as this check goes. The button doesn't lead anywhere yet. The page still needs its booking form, the confirmation a contractor sees afterward, and a full accessibility review of headings, focus order and form fields. Those form the next build.

The page is saved in the project with the request that produced it, the revised draft with its tags and row list, and a fault note. The note names the three faults: the reassurance line on a misused citation, the uncited time claim, and the penalty figure without its condition. Each note makes the next draft easier to check, because the faults it records are the first places to look.

Testing the adaptation instruction in a fresh chat

Before the form gets built, one small test is still owed. The saved situation adaptation instruction has only ever run in the chat where it was written. An instruction that works there might lean on earlier conversation without anyone noticing. A fresh chat removes that crutch.

First, a quick check that the ground hasn't moved. Anthropic's documentation shows no change, from the start of September to the twelfth of October, in how Claude Projects apply instructions and files in new chats. That check left out two areas: the September coordinator update already covered, and changes to Claude's memory system. Project instructions still act as standing guidance in every chat. Uploaded files are still reference documents the project pulls into each chat as needed. So a new chat in Ledgerlane Marketing should see the instruction, the register and the brief. The test checks whether it does.

The test input is a second illustrative inquiry, different from the penalty letter. A two-van electrician writes that their accountant just sent a year-end tax bill much bigger than expected. They ask whether Ledgerlane could have prevented this and what it would cost. That's the bill side of the trigger, not the penalty side, so it tests whether the instruction adapts or just copies the last reply.

Ida is asked for a reply email using the saved instruction. The result is judged on the four checks from the penalty-letter work. Here is the illustrative result.

On tags, every changed sentence carried one. The price sentence pointed to the two-van row at two hundred and sixty pounds, which correctly matched the reader's two vans. That passes.

On VAT, the reply made no VAT claim. This matters because "including VAT" slipped into two earlier drafts, and the VAT row is still open with the founder. That passes.

On using only the contractor's own facts, the reply mentioned the two vans and the bill. It didn't guess the bill's size, the tax year or the trade's income. It also didn't answer "could you have prevented this" with yes. A yes would be a promise about an outcome. Instead, it described the monthly work from the inclusion rows. That passes.

On split unknowns, the reply ended with questions for the customer: which tax year the bill covers, and whether they're VAT-registered. It listed questions for the owner, including the open VAT row and whether Ledgerlane works alongside an existing accountant. That passes.

All four checks passed on this one illustrative inquiry. That shows the instruction carries into a new chat for this kind of message. It doesn't show that it holds for every message. A third test with an unusual case, such as a contractor outside the van-trade audience, would test it further. For now it has earned its place, and the work can move on to the booking form and the confirmation behind the button.