Every Monday someone asks for a copy of last month's invoice. Every week a few customers want to change a delivery address, and a few more ask where their order is. Nobody has complained, and each request takes only five minutes. But five minutes, forty times a month, is more than three working days.
Recurring requests are the quiet cost of a small company. They are also the best place to look when someone says "we should build a customer portal". Before you build anything, you need to know which requests are actually recurring, and which of them a customer could safely handle alone.
Start with a tally, not a workshop
Memory is a poor guide. The request that annoyed you last Tuesday feels frequent, while the quiet one that arrives daily goes unnoticed.
For four weeks, ask everyone who talks to customers to add a tick to a shared sheet whenever a request comes in. Use four columns:
- what the customer asked for, in a few words;
- the channel (email, phone, form, message);
- roughly how many minutes it took to handle;
- whether it needed a person's judgement or just a lookup and a repeat of known steps.
Do not design categories in advance. Write what you hear and group similar lines at the end. Four weeks is long enough to include a month-end and a quiet spell. If your business is seasonal, note that and repeat the count at a different time of year.
Separate questions from actions
Your list will contain two different kinds of request.
Questions need an answer that is the same for most people: opening hours, delivery times, how to return something, what a document means. These are usually best served by a customer FAQ page built from real questions, not by software.
Actions need something to happen in your systems: send a copy of an invoice, change an address, reschedule a booking, reset access, confirm a stock level, cancel a subscription. These are the ones worth considering for self-service, because the customer can do part or all of the work themselves, at any time of day.
Mark each line in your tally as question or action. If most of your volume is questions, fix the answers first. A tool will not help a customer who cannot find the answer.
Score the action candidates
Take the five or six actions with the highest counts and score each from 1 to 3 on four points:
- Frequency. How many times a month? Three points for the top of your list, one for fewer than ten.
- Handling time. How many minutes does a person spend? Add the time spent finding the data, not only the reply.
- Rule clarity. Can you write the steps as fixed rules? Three points if yes, one if every case needs a judgement call.
- Risk. What goes wrong if the customer makes a mistake or someone else pretends to be them? Score three for low risk (a copy of a document the customer already owns), one for high risk (changing bank details, issuing refunds).
Add the four numbers. Anything with a score of 10 or more is a candidate; below 7, leave it with a person. Treat the score as a way to start a sensible conversation, not as a calculation that decides for you.
A short example. Sending invoice copies: 40 a month, 6 minutes each, a fixed rule, low risk. Changing a delivery address: 12 a month, 4 minutes, clear rules, medium risk. A refund request: 5 a month, 20 minutes, needs judgement, high risk. The invoice copy is an obvious first choice. The refund should stay with a person, however much time it takes.
Check the data and the identity question
A self-service tool is only as good as the data behind it. Before choosing a candidate, check three things:
- Is the information already in one system, or do you need to gather it from a spreadsheet, a mailbox and a shared drive?
- Can you reliably tell who the customer is? Letting someone download an invoice needs a way to prove they are the right person, such as a link sent to the address you already hold.
- Who sees the result when something looks wrong? A tool with no human fallback creates more email, not less.
If the answers are unclear, the first project is not the tool. It is tidying the data. This is the same discipline described in what to log in a small internal tool so support questions answer themselves: know what happened, to whom and when, before you automate anything.
Choose the smallest first step
For the top candidate, write down the smallest version that removes most of the manual work. Often it is not an account area. It may be:
- a form that fills in the details for a person, so the lookup is already done;
- an automatic email with the document, triggered by a short request form;
- a page where the customer enters an order number and email address and sees a status.
Each of these is a few days of work rather than a few months. Keep the human route open: a line saying "Not what you need? Write to us" costs nothing and catches the cases the tool cannot handle.
Resist the urge to bundle five requests into one portal. A portal needs accounts, passwords, support and maintenance. One narrow tool that works is better than a broad one that is half-used. If you later decide the idea deserves more, treat it like any feature request for an internal tool: with a score, an owner and a decision date.
Decide what success looks like
Before building, agree two numbers with whoever pays for it: how many requests of this type you expect to handle manually after launch, and how many minutes that should save per month. A realistic target is that about half to two-thirds of the requests no longer reach a person within the first few months. Some customers will always prefer to phone.
Repeat your tally for the same request type four weeks after launch. If the count of manual requests did not fall, find out why. Often the link is hard to find, or the form asks for something customers do not have to hand. Fix that before adding anything new.
What to do this week
Share a simple sheet with your team and start the four-week tally today. Mark each line as a question or an action. At the end of the month, score the top five actions, choose one with low risk and clear rules, and describe the smallest version that would work. If you want a second opinion on what is worth building, bring the tally to a short conversation with a developer; with real numbers on the table, an hour is usually enough.