A store's policy pages are an operational asset, not only legal text. What belongs there, what belongs on the product page, and who updates them when operations change.
Key takeaways
- These pages hold two kinds of information: a legal framework and changing operational detail.
- The operational detail is what goes stale, and it is also what generates enquiries.
- Anything affecting a purchase decision does not belong in the terms but on the product page.
- Every policy page needs an owner and a last-updated date.
- The most common contradiction is between what is written and what support says on the phone.
The legal wording of a terms page is a lawyer's work, and that is not what is discussed here. What is discussed: policy pages also contain operational information - delivery times, return conditions, support hours - and that information goes stale, contradicts what actually happens, and belongs to nobody.
Two kinds of information on one page
A store's terms page usually contains a framework - who the parties are, what the terms cover, how disputes are resolved - alongside operational detail such as how many days shipping takes and what condition a returned item must be in.
The difference between them is the rate of change. The framework changes rarely and is handled by a lawyer; the operational detail changes when the courier company changes, when collection in person is added, or when support hours move - and then nobody remembers to update the page.
What belongs where
| The information | The right place | Why |
|---|---|---|
| Shipping price | Product page and cart | Directly affects the decision |
| Delivery time range | Product page | The customer's first question |
| Return conditions in brief | Product page | Removes hesitation before buying |
| Return conditions in full | Policy page | Detail that does not belong on a product page |
| Support hours and contact routes | Footer and contact page | Needed after the purchase |
| Legal framework | Terms | Does not affect the decision |
The rule behind the table is simple: information a customer needs in order to decide lives where they decide. A terms page is an excellent place for what is needed to explain, and a poor place for what is needed to buy.
Why it goes stale
The reason is not laziness but ownership. A terms page is created once, usually when the store is set up, and often by an outside party. From that moment it belongs to nobody: not to marketing, who did not write it, and not to operations, who do not touch pages.
The result is contradictions discovered through customers. The store moved to a courier that delivers in two days, the page still says seven business days, and the customer calls to ask which is true. In the reverse case - the page promises faster than reality - the contact already arrives angry.
The contradiction between the page and what support says
This is the hardest problem to see from inside, because each side sounds reasonable on its own. The page says returns are accepted within 14 days in the original packaging; the support agent, wanting a satisfied customer, accepts a return with no packaging. Both behaved sensibly, and the result is that there is no single policy.
It gets complicated when a second customer asks for the same thing and gets a different answer - and then the argument is not about the return but about fairness, which is far harder to end.
The fix is not to harden support but to document what actually happens. If in practice you accept returns without packaging, that is what should be written; and if that is not what you want, a decision is needed - and it is the business's decision, not that of whoever answers the phone.
What comes back from support is the best list
There is no need to guess what is missing from the policy pages. The questions reaching support are exactly the list, and at an average store five questions cover most of it:
- When will it arrive.
- How much is shipping and when is it free.
- How do returns work and who pays.
- When does a refund actually land.
- What to do if the item arrived damaged.
Logging enquiries for two weeks and classifying them gives you the precise order in which to update, and it is also the measure: if after the update the same question keeps arriving at the same volume, the information exists and is not where people look for it.
Who owns it and what to record
| The field | Why |
|---|---|
| Owner | Who updates when operations change |
| Last updated date | Lets you know whether the page is stale |
| Source for each operational figure | Where the delivery time came from |
| Events that require an update | Changing courier, changing hours, a new product type |
The fourth row is what turns this into a process rather than an intention. When changing courier appears on a list as an event requiring a page update, it happens; when it depends on somebody remembering, it does not.
Three ten-minute checks
- Open the page and read every sentence containing a number - days, percentages, hours - and confirm it is still true.
- Ask whoever answers customers which three contradictions they hit most often.
- Check that every policy page is reachable from the footer and from the order confirmation, not only through search.
The first catches most of the staleness, because numbers are what change. The second catches what the page does not say at all. The third sounds technical and is the one that explains why customers ask about things that are written down - information that cannot be found is worth exactly as much as information that does not exist.
What if the policy itself is unclear?
Sometimes the problem is not the wording but that there is no decision: there is no uniform answer to who pays for a return, so every case is settled individually. In that state precise writing is impossible, and what is needed first is the decision.
That sounds obvious and is in practice a leading source of vague pages: general wording is not a legal error but a faithful reflection of a business that has not yet decided. Once the decision is made, writing it onto the page is fifteen minutes of work, and the legal wording goes to a lawyer.
Sources
Frequently asked questions
How much time is worth spending on these pages?
The operational update is an hour a quarter at an average store. What takes time is the decisions behind it, and those are made once.
Should information be duplicated between the product page and the terms?
Yes - briefly on the product page and in full in the terms. What you should avoid is two versions written separately, because they will contradict each other the moment something changes; better that the page points at the source than restates it in different words.
Who should approve a change to a policy page?
A change to operational information - whoever owns operations. A change to legal wording - a lawyer. The trouble starts when the two are mixed in one paragraph, which is a good reason to separate them on the page.
Should previous versions be kept?
Operationally it is useful, because a question about an order from two months ago is answered by what was written then. Whether and how that is required legally is a matter for a lawyer.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.
