The customer asks when you are coming. Nobody knows

The phone rings at ten past nine. A customer, polite but tight-voiced, asks whether somebody is still coming this morning. She took the morning off. The office says of course, let me just check, and puts her on hold.

Checking means this: a message to the group chat that nobody answers because both crews are driving. A call to the technician who was meant to be there, which goes to voicemail. A call to the other van on the off chance they swapped. A look at the calendar, which says what was planned on Friday and nothing about what has happened since. Twelve minutes later the office calls back with an answer that is half a guess, and the customer hears the guess in the voice.

Nothing went badly wrong on site. The first job of the day simply ran long, the technician decided to finish it rather than leave a half-open boiler, and told nobody, because there was nobody to tell and no obvious place to write it.

Where the status actually is

The job has a state. It is either not started, on the way, in progress, blocked on a part, done, or done with something to come back for. The firm knows that state at every moment. The trouble is that the knowledge is spread across the one person who is standing in it, the van that carries the paperwork, and a chat thread where it is buried under photos of the previous job. There is no single record of the job that holds its current state, so there is nothing the office can look at. There is only somebody to ask.

What that costs, in detail

Every customer question becomes an investigation. The question is simple and the answer exists, but getting it means interrupting the person who has it. Three calls to answer one is the normal ratio, and the office makes them while the next enquiry rings out.

The technician is interrupted at the worst moment. The person with their hands inside the job is the only person who can say how the job is going, so they are the one who gets called. Each call costs the minute it takes and the five minutes it takes to get back into the work.

The schedule is a plan that nobody updates. It was true at eight. By ten it is a picture of the morning the firm intended to have. Nobody adjusts it, because adjusting it would mean knowing what has changed, which brings us back to the phone calls.

The customer is told last. A delay is known to the technician at nine, to the office at half past, and to the customer only if she rings. The firm had the information for an hour and used it for nothing. The customer did not take the morning off for a delay. She took it off to be left waiting without a word, which is a different thing and the one she will remember.

The group chat is a record that forgets. A week later nobody can find which message said the part was ordered, or whether the follow-up was agreed, because a chat is sorted by time rather than by job.

The owner is the lookup table. When the office cannot find out, it asks the owner, who usually knows because the technician texted them directly. So the firm cannot answer a customer when the owner is on a roof.

What a system of action does instead

One record per job, with a state on it. Not a calendar block and not a chat thread. A job that knows whether it is scheduled, on the way, in progress, blocked or done, and that changes state when something real happens. The technician taps once when they set off and once when they finish; that is the whole data-entry burden, and it is less than the phone call it replaces.

The time of arrival comes from the schedule, not from a guess. If the first job ran long, the next job’s expected start moves with it, because the two are in the same plan and the plan knows the drive between them. The office does not calculate this; it reads it.

The customer hears first, as a draft that a person sends. When a job’s expected start moves past what was promised, the system drafts the message: who is coming, roughly when, and sorry. The office or the owner reads it and sends it, or decides this customer deserves a call instead. It does not go out on its own, because the message to a customer is exactly the kind of thing a person should still sign.

The office answers from the screen. The question “when are you coming” becomes a glance: the job, its state, its expected start. No calls, no hold music, no guess in the voice.

The state is kept, not scrolled past. When the job is done, the record still shows when it started, when it finished, what blocked it and what was promised for the return. Which is also what the invoice and any later complaint will need.

What this does not do is drive the van. A system can know a job is late because the previous one is still open; it cannot know the technician chose to stay and finish. That choice still belongs to the person on site, and the point is only that the choice should take them one tap to share.

The test

Tomorrow, pick an hour mid-morning and, without calling anyone, try to write down the state of every job that is supposed to be running: started or not, on time or not, anything blocking it.

Mark each line you could fill in from something you could look at, and each line you would have had to phone for. The second count is the number of times a customer could ring and get put on hold. It is also how much of the firm’s day currently exists only in a van.

BiznesIQ is being built so that the job carries its own state and the schedule carries the expected arrival, with the customer message drafted and waiting for a person to send. That is the same argument as your calendar only knows about time, taken one step further into the working day, and it is the first half of why a complaint is a job nobody priced. How BiznesIQ is meant to tie the job, the schedule and the customer message into one record, and what it deliberately does not do, is on the homepage.