Writing for the customer and the adjudicator on the same page

The first reader wants to know whether they can return a coat they bought three weeks ago. They will give the page a short amount of attention, they are scanning for a number, and every clause that is not about their situation is noise they have to push past.

The second reader is reconstructing what you promised, on a particular date, after something went wrong. That might be an adjudicator, a card issuer reviewing a chargeback, a regulator, a solicitor, or your own colleague in two years trying to work out what the business committed to. This reader wants completeness. Every exception written down, every term defined, no gap where a reasonable person could have assumed something you did not mean.

These are not two moods of the same document. They want opposite things from the same page. The first reader is served by omission and the second is harmed by it. A single page that tries to serve both usually serves the second, because the second reader is the one somebody in the business is afraid of.

The features are recognisable. A definitions block at the top, so that ordinary words can be used precisely later. Conditions nested inside conditions, because that is how the actual rule works. Constructions that avoid naming who does the acting, because naming an actor commits you. The qualifiers: subject to, where applicable, at our discretion, save where, reasonable, without prejudice to.

Every one of those exists for a reason and most of them are load bearing. Someone chose them, often after something went badly. Telling a business to write its terms in plain friendly language is easy advice to give and it quietly asks them to drop protection they added deliberately.

But look at what the combination does to the first reader. The answer to their question exists on the page, in a subordinate clause, qualified by a term defined two screens above, with an exception in a later section they have not reached. They cannot find it, and if they think they have found it there is a real chance they have found the wrong one. The page is correct. It is also, for its most common visitor, useless.

This happens without a decision. Whoever answers the inbox gets tired of typing the same explanation, writes an FAQ entry, and publishes it. It is accurate as far as it goes, it is written from memory, and it is written from memory of the common case.

It says fourteen days. The policy says fourteen days from the date of delivery, excluding made to order items, personalised items and anything sold as a clearance line. Both are on the site. Both were true when written. For most customers the short one is a perfectly good answer.

Then the policy gets amended, because policies do. The amendment is made by whoever owns the policy, which is not the person who wrote the FAQ, and it does not occur to anyone that a second document contains the same number. From that moment the site publishes two different promises, and the business has no way of knowing which one a given customer read. That is the state most sites are in, and nobody has done anything wrong to get there.

The obvious fix is to have one document, written well enough to serve everybody. It is attempted often and it produces a characteristic result: a page that is too long for the customer and too loose for the adjudicator.

Too long, because serving the first reader means putting the plain answer where they will hit it, and serving the second means the exceptions have to be there too, so the plain answer ends up wrapped in the qualifications it was supposed to escape. Too loose, because the merge is done by softening. Somebody rewrites a defined term into ordinary language to make a sentence readable, and a word that had a specific agreed meaning becomes a word that means whatever a reader thinks it means.

That is the worst outcome available. The customer still cannot find the answer, and the protection that justified the difficult writing has been diluted by an editing pass nobody ran past the person who added it.

The arrangement that works is not clever. Put both on the same page, stacked, with the plain answers on top and the binding text below, unchanged. Between them, one sentence stating the relationship: the section above is a summary provided for convenience and the terms below are what apply.

That sentence is what makes the arrangement safe rather than reckless, and it is the sentence to have checked by whoever advises you, because the exact wording matters and it is not something to copy off another site. What it buys you is the ability to write the top section for the reader who has a question, without the top section becoming a second competing promise.

Two ways this gets built badly. The precedence sentence is put in small text at the very bottom, where it is not between the two things it is arbitrating. Or the binding text is put behind a link, so the page a customer reads contains only the summary and the relationship is asserted rather than shown. Stack them. The point of one page is that both readers can see they are looking at two layers of the same thing.

The mechanism that keeps the two layers honest is a rule about where facts live. Every number, date, threshold, exclusion and named condition in the summary has to be traceable to a sentence in the binding text below it. The summary may simplify by leaving things out. It may never simplify by restating a threshold in its own words.

This sounds pedantic until you watch it fail. A summary that says roughly a fortnight above a clause that says fourteen days has introduced a fact. A summary that says most items above a clause that names three excluded categories has introduced a judgment. Neither is a lie and both create a gap between the layers that will be argued about.

The useful corollary: if the summary needs a fact the binding text does not contain, you have found a hole in the binding text. That is a genuinely valuable finding and it comes free with the exercise. The response is to fix the clause, not to let the summary cover for it.

The obvious objection to a summary is that omission is how it misleads. Somebody in an excluded category reads the plain version, believes it applies to them, and is told otherwise later. That objection is right and it has a cheap answer.

The summary carries a scope line naming the cases it does not cover. Not describing them in detail, just naming them so that a reader in one of those cases knows to keep reading. Made to order items, clearance lines, trade accounts, installed goods, anything bought in person rather than online. A single sentence, and it is precisely the sentence the excluded customer needs, because their whole problem is that they do not know they are a special case.

This is also the part that improves your support queue fastest. A large share of the arguments that reach a person are people who read a general rule and were in an exception. They were not being careless. Nothing on the page told them there were exceptions until they had already made a decision.

Ownership is the last piece and it is where this usually falls apart. The binding text is owned by whoever can amend the terms. The summary is owned by whoever answers customer questions. Those are different people with different calendars and no reason to talk.

The fix is physical rather than procedural. Because the two layers are on the same page, in the same file, an amendment cannot be made without the person making it seeing the summary directly above. That is a weaker guarantee than a review process and a much stronger one than a reminder, because it costs nobody any discipline. A review calendar depends on somebody remembering; adjacency does not.

Where you genuinely cannot combine them, because the binding text lives in a system the content team cannot touch, the fallback is a single named person who owns the pair and a note in both documents saying the other exists and where. It is weaker. It is also better than the common arrangement, which is two documents that do not know about each other and a business that finds out they disagree from a customer.