A phrase such as “fast, affordable and excellent” leaves the customer and the operating team to invent different meanings. A more specific statement makes both value and trade-offs easier to discuss.
Write the promise in observable terms
A fictional payroll-support service might propose: “For small businesses using our supported payroll system, we review a complete payroll file and identify flagged exceptions before the agreed submission deadline.”
This statement defines a segment, an input condition, a task and a timing condition. It still needs clarity about supported systems, what counts as complete, the agreed deadline and what the review does not cover. It should not be presented as a public guarantee before the service can substantiate it.
Connect each claim to an operating requirement
| Promise element | Work or evidence required |
|---|---|
| Supported system | Compatible input and a maintained scope list |
| Complete file | Intake checklist and a way to reject missing information |
| Exception review | Reliable checks and an escalation path |
| Before the deadline | Capacity, scheduling and clear cutoff times |
| Useful result | Customer can understand and act on the flagged items |
A promise is easier to keep when the customer knows what they must supply. Making a dependency visible is not the same as shifting every problem to the customer. The service must also make those requirements reasonable and understandable.
Inspect the capacity behind “fast”
Suppose the fictional team can review 40 standard files per day and expects 55 submissions just before a common deadline. A general speed promise will be difficult to support unless scheduling, capacity or the offer changes.
The capacity guide helps estimate the effective rate. Workflow mapping shows whether missing information or approval waits make the rate estimate irrelevant to elapsed customer time.
A premium response time may require reserved capacity that has a real cost. Include that cost when considering service pricing, rather than assuming the same team can promise unlimited urgent work.
Explain what the offer excludes
Specify the scope and the path for exceptions. If unusual cases need another specialist or more time, describe how the customer learns that and who takes responsibility for the next decision.
Avoid promising certainty where the work only supports an investigation. A review can identify potential exceptions without guaranteeing that no error exists. The exact wording should match the actual evidence and responsibilities of the service.
Test understanding and delivery
Ask a prospective customer to explain the promise in their own words. What do they expect to receive, when and with what effort? A mismatch can reveal ambiguity before a sale creates disappointment.
Then test the operating journey on representative cases, including missing inputs and exceptions. Track completion within the agreed conditions, quality, customer effort and the cost of keeping the promise. These are proposed tests, not results from a real payroll business.
Put the promise on a strategy map
Use the five-box resource to connect the promised outcome to product, production, channel and customer work. Compare the customer's alternatives. If the promise adds a benefit, identify which activity funds or enables it.
Sources and limits
The activity relationships draw on HBS's value-chain explanation. The payroll-support statement and conditions are original fictional HBW examples. They are not a legal service commitment, compliance certification or recommended wording for a regulated service.