\nThe request usually arrives as a complaint about staff. Too much time on the phone, too many interruptions, could we get a chatbot.<\/p>\n
Then you look at what the calls are, and they are all the same call. Where is my thing. Is it ready. Has it started yet.<\/p>\n
That is not a support problem. It is a visibility problem wearing a support problem’s clothes, and the fix is usually a customer status page rather than a system.<\/p>\n
Because the information exists and they cannot reach it. Inside your business, the job’s stage is written down somewhere. From outside, the only interface to that fact is a human who has to be asked. Every call is a customer doing a database lookup by voice.<\/p>\n
Nobody set out to build it that way. It happens because the people running the work already know the status, so the absence never shows up from the inside.<\/p>\n
The tell is that the calls cluster on the longest jobs. Nobody phones about something they collect the same afternoon. They phone when the thing has been out of sight for four days and silence starts to feel like a problem.<\/p>\n
Less than people expect. A customer status page is not a portal and does not need a login, which is the decision that kills most of these projects before they ship.<\/p>\n
What it needs is a permanent link, the current stage in plain language, and a sense of what happens next.<\/p>\n
That is close to the whole specification.<\/p>\n
The plain language part is where these go wrong. Internal stage names leak onto the page, and the customer gets A date helps, even a rough one, as long as it is honest. “Ready Thursday” is useful. “Ready Thursday” that becomes Monday twice is worse than no date at all, because now the page has taught them not to trust it.<\/p>\n I built one of these into Uwrapz<\/a>, a car wrapping workflow platform, as a solo project that reached production in about two months. Vehicles sat in the workshop for days, so the owner fielded the same call constantly. Every job got a status link and a notification when it moved a stage. The owner’s summary afterwards was that the repeated status calls largely dried up.<\/p>\n Wherever the customer already is. This is the part that decides whether the page gets used or ignored.<\/p>\n For most service businesses that means messaging, because a link sitting in an email from three weeks ago is functionally lost. WhatsApp is the usual destination, and there is a cost quirk worth knowing before you design the flow. As Meta’s pricing rules stand at the time of writing, utility template messages are free when delivered inside an open customer service window, while marketing templates are charged whatever the timing. Check the current WhatsApp Business Platform pricing<\/a> before you build, because these rules move. A status page changes that maths in your favour, because customers who can check things themselves tend to open the conversation themselves. The full breakdown of what the WhatsApp Business API actually costs to run<\/a> covers the rest of it.<\/p>\n The page and the notification are not alternatives.<\/p>\n The notification is what makes the page get looked at, and the page is what stops the notification from having to explain everything.<\/p>\n Less than a portal, more than a plugin.<\/p>\n The real variable is not the page. It is whether your business already knows, in software, when a job changes stage.<\/p>\n That third row is the one that surprises people, and it is the reason quotes for this vary so wildly. If nobody records that a job moved from cutting to fitting, no page can display it. You are not buying a status page at that point. You are buying the discipline of recording stages, and the page is what makes that discipline visible enough to survive.<\/p>\n Worth saying plainly: that is still usually worth doing, because the same record that feeds the page also tells you which stage is quietly eating your week.<\/p>\n If jobs finish the same day, skip it. Nobody needs to track a haircut.<\/p>\n If your stages genuinely cannot be predicted, a status page becomes a public log of uncertainty, which is worse than a phone call where a human can add context. Some work is like that. Custom fabrication that depends on a supplier who does not answer emails is not improved by broadcasting the wait.<\/p>\n And if the calls you are getting are not actually status calls, this fixes nothing. Listen to a week of them properly before building anything. If half are people asking for changes or chasing quotes, you have a different problem and a status page just moves it.<\/p>\n The test is simple. If the same question arrives more than a few times a week, and the answer is already written down inside your business, that is a screen you have not built yet.<\/p>\nQC2 PENDING<\/code> when what they needed was “we are checking the finish, then it is ready to collect”. You are not showing them your pipeline. You are answering the question they would have phoned to ask.<\/p>\nWhere the link should live<\/h2>\n
What it costs to build<\/h2>\n
\n\n
\n \nWhat you already have<\/th>\n What the build involves<\/th>\n<\/tr>\n<\/thead>\n \n Jobs tracked in a system with clear stages<\/td>\n Mostly a public read-only view plus a link. The short version.<\/td>\n<\/tr>\n \n Jobs tracked in a spreadsheet<\/td>\n Move the stages somewhere queryable first, then the page.<\/td>\n<\/tr>\n \n Stages that live in people’s heads<\/td>\n This is the actual project. The page is the easy half.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n When this is the wrong thing to build<\/h2>\n