Customer experience
Make your website promise operational.
Use a simple promise register to keep website claims aligned with service conditions, operational dependencies and business change.
A hypothetical parts supplier says on its website that replacement items are available for next-day UK delivery. The sales team still believes that statement is accurate. Operations knows it depends on stock, an order cut-off and the carrier’s postcode coverage. None of those conditions is visible to the person maintaining the website. A public promise can become misleading when the operation changes quietly behind it.
Build a short register of consequential promises
Review the website for statements a customer could reasonably use when deciding to buy. Delivery timing, service availability, geographic coverage, cancellation rights, stock claims and phrases such as guaranteed, always or included deserve attention. Check FAQs and confirmation pages as well as headline service copy.
Put the important claims in a simple promise register. Record the exact wording, page, intended audience, any condition shown to the customer, the operational owner and the evidence that currently supports it. Keep the list selective: it should highlight claims with a real commercial or service consequence, not become an inventory of every sentence.
Expose the dependencies behind each claim
Ask the operational owner what must remain true for each promise to hold. Next-day delivery might depend on live stock data, a weekday cut-off, payment approval, warehouse capacity and a carrier service that excludes some postcodes. A cancellation statement might depend on contract type and how far work has progressed.
Write the dependencies beside the claim rather than leaving them as informal knowledge. This makes it easier to distinguish a genuine service commitment from an aspiration or an old marketing assumption. It also reveals conditions that should be explained clearly to customers instead of hidden in the process.
- What does the customer reasonably expect from this wording?
- Which system, supplier, team or policy makes it possible?
- Which boundary or exception materially changes the promise?
- Who can confirm whether it remains supportable?
- What should happen if a dependency changes?
Connect the register to change triggers
For every registered promise, name the changes that require a review. Useful triggers include revised supplier terms, new opening hours, a system migration, a different delivery partner, a new service region, altered cancellation rules or a change in who performs the work.
Add the website check to the relevant change checklist. The person approving an operational change does not need to rewrite the page, but they should flag affected promises to the content owner. Give that owner a clear route to confirm the new position and a date by which public wording must be updated.
Repair the operation, the wording or both
A mismatch does not automatically mean weakening the claim. The promise may be commercially valuable and expose an operational problem worth fixing. In other cases, precise wording is the honest answer: ‘next working day for stocked items ordered before 2pm’ is more useful than a broad statement the business cannot consistently support.
Agree the remedy, owner and completion date in the register. When the change is made, verify the public wording and the relevant operational evidence, then record the review date. Sample the register periodically, but let real business changes drive most reviews rather than relying on an annual content exercise.
A Rethink website conversion review can help connect consequential claims with the service conditions and ownership needed to support them.