Writing Catalog Descriptions That Set Accurate Expectations
Why this matters
The line item name sells the job. The description is what prevents the argument afterward. A customer who books "drain cleaning" and expects a full camera inspection because the vague description implied it, then gets a bill for the camera as an add-on, does not remember which word was technically accurate. They remember feeling surprised, and a surprised customer leaves a review before they leave a callback. A tight, honest description is one of the cheapest tools a shop has for cutting dispute-driven callbacks and bad reviews.
What a good description actually does
A catalog description has one job beyond naming the service: draw the line between what is included and what is not, in language a non-tradesperson can understand without a phone call. It is not marketing copy and it is not a technical spec sheet. It sits between the two.
- States what's included in plain terms. Not "standard diagnostic protocol," but "we identify the cause and give you a repair price before doing further work."
- States what's explicitly excluded, especially anything a customer might reasonably assume is included. If parts are separate, say so in the description, not just in a footnote on the invoice.
- Names the trigger for extra cost, if there is one. "Additional charges apply if access requires cutting drywall" tells the customer the condition that changes the price, before it happens on their job.
- Avoids trade jargon the customer has to look up. If a term is unavoidable, define it in three or four words right there rather than assuming the customer knows it.
The three failure modes
Almost every bad catalog description falls into one of these patterns. Naming the pattern makes it easier to spot in your own catalog.
- Too vague to mean anything. "Complete system service" tells the customer nothing about what happens on the visit. Vague descriptions feel efficient to write and are the single biggest source of "that's not what I thought I was paying for."
- Too technical to read. A description copied straight from an internal work-order template, full of trade shorthand, is written for the tech, not the customer. If a customer has to call and ask what it means, the description has failed at its one job.
- Overpromising to sell the job. A description that implies more than the price actually covers, to make the number look better, generates the worst kind of dispute: one where the customer feels actively misled rather than just under-informed.
A simple structure that works for most entries
You do not need a paragraph. A short two- or three-sentence pattern covers almost every catalog entry:
- What we do. One plain sentence describing the work.
- What's included versus what could add cost. One sentence naming the boundary.
- What happens next, if the service can uncover more work (a diagnostic that leads to a repair quote, for example). One sentence setting that expectation up front.
A description built this way reads in under ten seconds and answers the three questions a customer actually has: what am I getting, what could change the price, and what happens if you find something else.
Test the description like a customer would
The best check is not a style review, it is a comprehension check. Have someone outside the trade, someone in the office who has never done the physical work, read the description and tell you back what they think is and is not included. If their answer does not match what the tech would actually do on-site, the description needs work, not the customer's understanding.
Do this pass whenever you write a new entry, and revisit it any time a dispute or an unhappy review traces back to a misunderstanding about scope. A pattern of "the customer thought this was included" complaints on the same line item is a description problem to fix, not a training problem to keep re-explaining on every call.
References
- Federal Trade Commission guidance on clear and non-deceptive service advertising
- Trade-standard practice for scope-of-work disclosure in field service
- See related: Simplifying an Overgrown Catalog
- See related: The Catalog Price vs the Quoted Price Mismatch Decision Tree