Most "what is happening with this" calls are answered by the same information. What is safe to show a customer, how to word a status, and when not to expose it at all.
Key takeaways
- Every "what is happening with this" call is a status that was never exposed.
- A good status says what happened, what is next, and when - all three, or it creates a new question.
- Do not expose a status updated by hand; stale information is worse than none.
- You do not need a portal: a personal link or a proactive message covers most businesses.
- What stays hidden: internal notes, costs, employee names, and internal reasons for delay.
A considerable share of inbound calls in a small business is the same question: what is happening with the order, the project, the repair. The question is entirely reasonable - the customer does not know and has no way to find out - so every one of those calls is a cost the business pays for the absence of visible information. Self-service status solves exactly that, provided it is worded properly.
Why the customer calls at all
Not from impatience, but because they do not know whether anything is happening. Somebody who knows the order ships on Wednesday will not call on Monday; somebody who received an order confirmation and nothing since will call, because from where they sit, silence could also be a fault.
That explains why speed is not the fix. A business that answers the same questions quickly still pays for them, and only when the information is available in advance does that traffic fall. It is also why the right measure is not response time but the number of enquiries of this type.
What a status has to say
| The element | Example | Why |
|---|---|---|
| What happened | "Received and approved" | Confirms it did not fall through |
| What is next | "Awaiting picking" | Shows movement |
| When | "Expected to ship Wednesday" | Prevents the next call |
| What is needed from you | "No action required" | Removes uncertainty |
The last row looks redundant and it is what prevents most enquiries. A customer who sees a status and is not sure whether the ball is with them will call to check, and that is exactly the call we wanted to save. A three-word sentence resolves it.
What not to expose
- Internal notes - even entirely reasonable ones.
- Costs and margin - there is no reason for those to be there.
- Employee names and who handled what.
- Internal reasons for delay - "awaiting manager approval" invites a question.
- Technical intermediate statuses that tell the customer nothing.
The last point confuses many businesses. An internal status like "in QA stage 2" is accurate and not useful - the customer does not know what it means or when it ends, so they call to ask. Translating into the customer's language is part of the work, not decoration.
How to expose it without building a portal
Three levels, cheapest first:
- A proactive message on every meaningful status change - cheap, and solves most of the problem.
- A personal link to a status page with no password, sent once and staying valid.
- A customer area with a login - only when contact is frequent.
The second is the best balance for most small businesses: no password to forget, no system to stand up, and the customer can check whenever they want. A full comparison of a portal against proactive updates is in a customer portal or email threads.
Wording status in the customer's language
Internal statuses were built to manage work, so they describe what is happening at your end. The customer is asking a different question: when is it mine. Translating between the two is a short job done once.
The simple method is mapping every internal status to one of four external states: received, in progress, ready, delivered. Four states cover almost any business, and everything in between stays internal. A fifth internal status with no external equivalent is usually a stage the customer does not need to know about at all.
What is worth adding to each state is an expected date. "In progress" with no date produces a call within two days; "in progress, expected Thursday" holds until Thursday, and that is exactly the difference being measured.
The prerequisite: the status has to be real
A status updated by hand will be out of date. That is not a discipline problem but a reality one - under pressure nobody stops to update a status, and that is precisely when customers check.
So the rule is to expose only statuses derived from an action that happens anyway: an order created, a payment received, a parcel handed to a courier. All of those produce a record on their own. A status requiring somebody to remember to click is not ready for exposure, which is the same test described in automatic tracking updates to the customer.
Where to put the link
The most common reason self-service does not reduce enquiries is that customers do not know it exists. A link sent once in the order confirmation is buried within two days, and then the customer does exactly what they would have done before.
What works is repetition: the link in the order confirmation, in every update message, in the email signature, and in the automatic reply of the channel they contact you on. That is not flooding - in each of those places it is relevant to precisely the question the customer is about to ask.
What happens when something goes wrong?
This is where self-service proves itself or fails. A status stuck in the same state for three days produces exactly the call we set out to prevent, so there has to be a rule: after X days with no movement, a proactive message goes out even when there is nothing new.
Such a message looks odd and works extremely well: "still waiting on a part from the supplier, we will update Sunday" is an answer that prevents a call, and far better than a frozen status. What damages trust is not the delay but the silence around it.
When not to expose status at all
There are three situations where exposing it does more harm than good. First: when the status depends on a third party you do not control - every delay of theirs then looks like a delay of yours. Second: when the process is short anyway, and a customer given a link to something finishing tomorrow is left with a pointless interface.
The third is the important one: when the information is not accurate. A status updated once a day on a process that changes hourly gives the customer a stale picture, and they will act on it - arriving to collect something that is not ready, or calling to ask why it says something different from what they were told.
In all three cases, a proactive message at the meaningful transitions works better and costs less. Fewer data points that are all correct beat a continuous picture that is partly stale.
What to measure
One number: how many calls and messages of the "what is happening with" type arrived this month. Measure one month before and two months after. If the number does not fall, the reason is nearly always that customers do not know the information exists - and that is solved by adding the link to the order confirmation and to every message, not by improving the page.
Sources
Frequently asked questions
Should status be exposed even when there is a delay?
Yes, and especially then. A customer seeing a documented delay with a new date calls less than one seeing a stale status. What matters is that the status says what changed, not only that it is still not ready.
What about customers who will never use it?
Keep answering them as usual. Self-service is not meant to replace responding but to reduce volume, so even a one-third drop in enquiries is a complete success.
How detailed should the status be?
Enough to answer the question and no more. Four or five stages in the customer's language beat fifteen internal ones, which only generate questions about stages the customer never knew existed.
Is a link without a password acceptable?
Usually yes, when it is unique and long and exposes nothing sensitive. What you should avoid is a link guessable from a sequential number - that exposes other customers' orders, and it is an easy mistake to prevent up front.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
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.
