How to stop answering the same question 20 times a week
If you answer the same question twenty times a week, that isn't an annoyance — it's data. Repeated questions are the most automatable work in your business, and most owners handle them the most expensive way possible: personally, one at a time.
Repeated questions are a signal, not a nuisance
A question that arrives twenty times is telling you two things: customers genuinely need the answer, and the answer barely changes. That combination — high demand, low variation — is precisely what automation is for.
Most businesses invert this. Novel, tricky requests get careful attention while the repetitive ones get dashed off between jobs, with slightly different wording each time. The result is inconsistency exactly where consistency is cheapest to achieve — and a slow, invisible tax on the person doing the answering, usually the owner or the most experienced member of staff. Sound familiar?
- "What are your opening hours over the bank holiday?"
- "How do I cancel or move my appointment?"
- "Can you resend my invoice?"
- "What do I need to bring / prepare / stop doing beforehand?"
- "How much does X cost?"
Answer once, publish it, and let routing do the rest
The fix is structural, not heroic: write the answer once, publish it to a knowledge base, and let classification route incoming questions to it. In ReQuest DESK, every inbound message — email, web, chat, WhatsApp, transcribed voice — goes through one classifier that matches it to your services and published answers.
The word published matters. Answers are grounded only in what you have explicitly approved — drafts stay drafts until you publish them, so the AI can never improvise a price or a policy you haven't signed off. That governance model is what makes it safe to let the system answer without you reading every reply.
How do you know which questions you still can't answer?
The questions you answer manually are only half the picture. The other half is the ones your knowledge base can't cover yet — and guessing at those is a waste of an evening.
Coverage mapping shows exactly which request types have a grounded answer and which still fall through to a human. And because the proposals engine watches real cases, it will suggest new or changed request types when a pattern emerges — a human approves before anything changes. You improve the catalog from evidence, not intuition.
What about answers that change with the seasons?
Holiday hours are the classic trap. You update the answer in December, forget about it, and in February the system is still cheerfully announcing your Christmas closure. Stale answers are worse than no answers, because they're delivered with confidence.
Time-boxed amendments solve this: publish the seasonal answer with an expiry, and the standard answer resumes automatically when the window closes. Nothing to remember, nothing to roll back, no February embarrassment.
None of this replaces your staff — it removes the twenty-a-week questions so their time goes to the requests that genuinely need judgement, including the ones that arrive after hours. The repetitive work was never the valuable part of their day. It was just the loudest.
The service layer you never had time to build — live in days.
Describe what you do — ReQuest builds the catalog, answers the routine, and routes the exceptions to your team.