Do Not Put a Job on the Calendar Before It Is Approved

The estimate is the commitment point. Not the phone call, not the intake, not the moment somebody on the phone sounds keen.

So nothing here becomes a job, an appointment or a held slot until a customer has approved a price. The order is lead, then estimate, then the customer approves, then a job, then a schedule. In that order, every time, with no shortcuts for jobs that feel certain.

A held slot costs you twice

The obvious cost first. A slot penciled in before approval is a slot you cannot sell to anybody else, held against work that may never happen. On a busy week that is straightforwardly lost revenue, and it is lost quietly, because an empty slot that was reserved looks identical in hindsight to an empty slot nobody wanted.

The second cost is worse and slower. Booking early puts a promise in front of the customer that nobody has priced yet. When the real number arrives and it is higher than the promise felt, you are no longer quoting. You are renegotiating, against an expectation you set yourself.

There is a third cost if you run mobile. A tentative slot on a route is a routing decision, and routing decisions compound. One soft booking in the wrong town reshapes the whole day around work that has not been sold.

What it looks like in the software

A drafted price lives as an estimate. It shares a table with jobs and carries an estimate status, and it is not a job, and we do not call it one out loud.

That last part sounds like fussiness about words and it is not. Language leaks into behavior. Call the drafted thing a job in conversation and within a week somebody treats it like one, because that is what the word means to everyone else in the building.

An estimate carries no scheduled date and no scheduled time. Those fields stay empty until an approval lands. Nothing automated books a slot, pencils anything in, or asks the customer what day works best before that point.

The automated reply is where this rule goes to die

If you are going to break this rule anywhere, it will be in an automatic response, and it will happen for good reasons.

Asking what day works best feels helpful. It feels like momentum. It is the single most natural thing to put in a reply to somebody who just said yes. It is also the exact thing the rule forbids, because it commits the calendar to work with no price attached.

We found a path in our own system that did all three forbidden things off one inbound message. It created a tentative booking, it texted the customer a price nobody had approved, and it asked what day worked best. It had never actually run, because something upstream failed every time and the error was swallowed silently, so it sat there for months looking like a feature.

Dead by accident is not the same as safe. It would have broken the rule the day somebody fixed the thing above it.

Helpful, done honestly

The useful version of helpful is not an earlier calendar entry. It is a faster approval.

So the effort goes into the path that actually is correct. A missed call gets answered. Intake gathers the facts. A quote gets drafted. A human reads it and sends it. The customer approves. Then, and only then, a job exists and a day gets picked.

That sequence takes the same number of messages as the shortcut and it produces a booking you can rely on rather than a placeholder somebody has to chase.

The rule has to reach your demo data

This one surprised us and it is cheap to get right.

Training records and demo data teach process whether you intended them to or not. A sample job showing a scheduled slot with no approved estimate teaches a new hire that the order is a suggestion. They will not read your policy document. They will read the screen in front of them and copy what it shows.

So the fixtures model the real order too. It costs an afternoon and it removes a whole category of bad habit before anyone forms it.

What to check in your own setup

Look for every path that can create a booking without a person clicking something. Automated replies, chat widgets, online booking forms, anything that reads an inbound message and writes to a calendar.

Then check whether any of them can send a price. A booking with no price and a price with no human are the two halves of the same problem, and they usually live in the same file.

If you find one, the fix is rarely to delete it. It is to make it gather facts and stop, and hand the decision to somebody who can be accountable for it.