Every recurring customer question is a candidate for automation. Many of them are better candidates for prevention. If a thousand people a month ask the same thing because a product page is missing one technical detail, the cheapest resolution is the detail, not an agent that explains it a thousand times.
This article is a method for sorting recurring contacts into three groups: prevent, keep and answer well, and automate. It sits upstream of the question of which existing tickets to automate first; that article prioritises demand you have decided to serve, while this one asks which demand should exist at all. Contact reduction is not automatically good, so the method is built to protect the contacts that create value.
Where this comes from. The method draws on three conversations Typewise held in 2026: a research interview I ran with the technology lead of an eyewear retailer, a demo a colleague ran for a sports-apparel retailer, and a quarterly review my colleague held with a parcel-logistics customer. The observations below are anonymised and marked as reported; the sorting method is our recommendation and the triage table is invented.
Three kinds of recurring contact
Failure demand. The customer contacts you because something upstream did not work: the delivery notification was confusing, the product page did not say the lens is made to order, the order form accepted the wrong identifier. The customer would rather not have contacted you. The fix belongs upstream.
Value demand. The customer wants advice: which product suits a beginner, whether two items are compatible, how to get started. These contacts build the relationship and, handled well, reduce returns. Prevention here means removing the need for a repeat question, not removing the conversation.
Residual demand. Legitimate requests that cannot be designed away: a change of plans, a damaged item, an exception. These are the automation and handoff candidates.
The groups are not fixed. A question moves from failure to residual once the upstream cause is fixed and only the genuine cases remain.
Step 1: find the recurring questions per product and per stage
Aggregated ticket categories hide the pattern. "Order status" is not a cause; "order status for made-to-order items in the second week" is. Three sources show the causes:
- Conversation analysis per product. Group inbound questions by the product or product line they concern and by the journey stage (choosing, ordering, waiting, using, returning). A recurring pre-purchase question about one product line is usually a content gap on that line's pages.
- Agent knowledge. The people answering know which questions they answer from memory because the page does not. Ask them for the ten they are most tired of.
- Channels that close without a ticket. Where a first-level team or phone line answers simple parcel-status questions without creating a ticket, the ticket system undercounts the demand. The logistics customer's service manager described this layout to my colleague: most calls go to an external first level that answers parcel-status questions from the tracking data without creating a ticket, and only cases that need investigation or a written exchange become one. Count those too, or the biggest prevention candidates stay invisible.
If you already use an AI assistant, reports of recurring questions per product are one of its more useful outputs, provided a person turns them into page changes.
Step 2: decide the group with four questions
For each recurring question, answer these in order.
- Would the customer rather not have asked? If yes, it is failure demand. Go to step 3.
- Does the answer depend on the customer's situation in a way a page cannot cover? If no, it is a content gap: publish the answer where the customer was looking. If yes, continue.
- Does a good answer change what the customer buys, keeps or does next? If yes, it is value demand: keep it, staff it, and make it easy to reach. Consider automating the routine part and keeping a person for the judgement.
- Is the contact driven by an event the customer could not foresee? If yes, it is residual demand: a candidate for automation with a clear handoff.
Write the group next to each question. In the illustrative triage below, the largest single category turns out to be failure demand with one or two upstream causes; whether that holds for you is exactly what the exercise shows.
Step 3: fix upstream before you automate
Prevention is mostly ordinary product and communication work.
- Product information. Add the missing specification, the compatibility note, the sizing guidance, the "this item is manufactured to order and takes about two weeks" line at checkout. A repeated technical question is a product-page bug.
- Notifications written from the customer's side. A delivery notice that says what the customer can do about it (change the day, give a drop-off permission) replaces the contact it would otherwise provoke. The logistics customer's service manager reported fewer tickets after their notifications were rebuilt from the customer's perspective, with plainer wording and direct options to adjust delivery or give a drop-off permission; the first version, he said, had been built from the developer's point of view and was logical only to developers. He offered no before-and-after count, and other service improvements were running at the same time, so treat a redesign like this as a hypothesis to test rather than a guaranteed effect, because service changes rarely happen one at a time.
- Stage-by-stage status. Where fulfilment has several steps the customer cannot see, show them. "Where is my order" demand falls when the customer can answer it alone. An eyewear retailer's technology lead told me in an interview that the bulk of their contacts were order-status questions, often from customers who had not understood at checkout that a specialist lens is manufactured externally and takes longer; their plan was stage-by-stage updates plus an explanation at the moment of ordering. A plan, not a measured reduction, and the clearest example I have of a contact that should not exist.
- Form design. If customers keep entering the pass number where the order number belongs, the form, not the customer, is the cause. Validate the identifier at entry, or accept both and map them.
- Expectations before purchase. Guidance at the moment of choosing reduces orders placed only to try and return. This is both a service outcome and a cost outcome, and it is the clearest case where prevention and value demand overlap.
Step 4: protect the contacts worth having
A contact-reduction target applied bluntly removes the advice conversations that justify the premium or prevent the return. Two guardrails help.
First, measure outcomes, not silence. A customer who stops replying may be satisfied or may have given up on the channel. The sports-apparel retailer's e-commerce lead raised this unprompted in the demo: a shopper who goes quiet may have had the question answered or may have given up on the chat, and he wanted the downstream signal, whether an item went into the basket. He also wanted reports of recurring pre-sales questions so he could find gaps in product pages, and said his team had no capacity for pre-sales escalations and would need an outsourcer. All three are requests, and the guardrails here are our answer to them. For pre-sales questions, a better success signal is whether the customer then added the item, completed the order or came back for the next step. Define the signal per contact type before you count anything as "resolved by content".
Second, keep a human path for judgement. Whether that path is staffed by people, AI or both is a staffing decision, but the path should exist, and if the volume of pre-sales advice exceeds what the team can staff, say so in the plan rather than assuming a human fallback that nobody can cover.
A worked, hypothetical triage
The table is illustrative. The counts are invented to show the shape of the output.
| Recurring question | Monthly volume | Group | Action | Signal to watch |
|---|---|---|---|---|
| "Will this lens take longer? Why no update?" | 900 | Failure | Explain made-to-order timing at checkout; add stage updates | Volume of this question after the change; not overall ticket count |
| "Is the mount compatible with model X?" | 400 | Content gap | Add compatibility table to the product page; keep an answer path | Question volume and return rate for the pair |
| "Which set should a beginner buy?" | 350 | Value | Keep and staff; automate the first filtering questions | Items per order, returns within 30 days |
| "Can I change the delivery day?" | 600 | Failure to residual | Put the option in the notification; automate the remaining requests | Share handled in self-service; contacts that still arrive |
| "My item arrived damaged" | 120 | Residual | Automate intake with evidence validation; human decision | Reopens and time to decision |
Notice that only two rows are automation candidates, and the largest row is solved by a sentence at checkout.
What this does not prove
A proposed prevention is not a measured reduction. Before you count a saving, hold the change for long enough to see the specific question's volume move, and expect concurrent changes to muddy the picture. Prevention can also shift contacts rather than remove them, for instance from support to a sales channel; follow the customer, not the ticket category. Finally, a contact that disappears because the customer gave up is not a success, so pair any reduction with the outcome signal you chose in step 4.
Related reading
- Which customer service tickets should you automate first?: prioritising the demand you keep.
- Knowledge debt: prioritising support documentation by business impact: the content side of the same problem.
- First contact resolution: the essential customer success KPI: measuring the contacts that remain.
FAQ
Is reducing contacts always a good goal?
No. Advice conversations that change what a customer buys or keeps are worth having, and a customer who gives up on a channel also stops contacting you. Sort contacts into failure, value and residual demand first, and reduce only the failure demand.
How do we know a content fix worked?
Track the volume of that specific question, not the total ticket count, and give the change time. Where other changes happened at the same time, treat the drop as indicative rather than proven.
Where should we start?
With the recurring questions per product and journey stage, including the ones that close without a ticket. Where one upstream gap turns out to drive a large share of contacts, fixing it is likely to cost less than automating the answer.
