How Jobs Get Booked Automatically From Phone and Text Intake

Booking a job from a phone call sounds like one action. It's at least three, and the gap between them is where automated booking either earns its place or quietly fills your calendar with work you can't run.

Quick answer: A conversation isn't a booking. Intake gathers the answers, a request records what the customer asked for, and a job is what goes on the calendar with a time and an address. Keeping those separate is what lets you automate the safe part while a person still stands in front of the expensive part. The failures that matter are almost never the AI misunderstanding words. They're a missing service address, a returning customer created twice, and a caller with an open job being booked a second one they didn't ask for.

Three steps, not one

Intake is the conversation. It establishes who is calling, what's wrong, where the work is, and how urgent it is.

A request is the durable record of what was asked for. It exists whether or not anything is scheduled, and it survives a call that ended before a time was agreed.

A job is the commitment. It has a window, an address, and eventually a technician, and it's what your crew works from.

The reason to keep these apart is that they carry different risk. Writing down what a customer asked for is close to free and wrong only in the sense that it can be corrected. Putting a job on the calendar consumes a window your team could have sold to someone else, and assigning a technician commits a truck. In Patchment (that's us) creating a request and creating a job are separately governed actions, so you can let the system record every inbound request automatically while still holding calendar commitments for a person, and change your mind about that one action later without touching anything else.

Systems that collapse this into a single automatic step force you to choose between capturing nothing automatically and committing your calendar automatically. Neither is what a busy HVAC shop wants.

The service address is the failure that costs money

Of everything intake can get wrong, the address is the one that turns into a wasted morning.

A job with a plausible but wrong address doesn't announce itself. It looks like a normal job on the calendar right up until a technician is standing outside the wrong building, and by then you've spent the drive, the window, and the customer's patience. A missing apartment or unit number does the same thing in a denser service area.

So the address should be validated and attached as part of booking rather than treated as a free-text note carried along for the ride. Postal-code awareness during intake matters for the same reason: knowing early whether an address falls inside the area you actually serve is what stops you booking work you were never going to send anyone to.

If you evaluate one thing when testing automated booking, make it this. Call in with a slightly ambiguous address and see what happens. A system that books it anyway is telling you something about every other edge case it handles.

Recognising the caller you already know

The second expensive failure is treating a returning customer as a stranger.

The visible cost is the customer being asked for details you already hold, which reads as an office that doesn't know them. The invisible and worse cost is a duplicate customer record in your field-service software, because from that point your history for that person is split across two entries and neither tells the truth.

This is why importing existing customers before go-live matters, and why it's worth testing with a real returning customer's number rather than only with new ones. Recognition also changes what the conversation should be: a known caller can be greeted by your business name and moved through intake faster, because the things you already know don't need asking again.

The caller who already has a job open

Here's the case most intake designs miss, and it produces the strangest results.

A customer with a job already booked calls back. They might be asking about that job, or reporting a new problem at the same address, or a different problem at a different property. Treating every call from a known number as a question about the existing job means new work is never captured. Treating every call as a new request means a customer asking when the technician will arrive ends up with a second appointment nobody wanted.

The right behaviour is to establish which of those it is before doing anything durable. This matters more than it sounds, because the customers most likely to call twice are the ones already waiting on you, which is exactly the group you can't afford to handle badly.

A related case is the callback. If a call was escalated to a person and a later call completes the intake, the earlier escalation should stop being an open item. Otherwise your queue slowly fills with things that were already resolved, and a queue nobody trusts is a queue nobody works.

Retries, duplicates, and knowing when to stop

Anything that writes into your field-service software over a network will sometimes get an unclear answer: the request may have succeeded, or it may not.

The naive response is to retry until something works, which is how a customer gets three identical jobs on the calendar. The correct response is for a write to be identifiable, so a repeat can be recognised as the same booking rather than a new one, and for retries to stop rather than continue blindly when the failure isn't the kind that retrying fixes.

You'll mostly not see this working. You see it failing, in the form of duplicates, and it's worth asking about specifically because it doesn't show up in a demo.

Texts book differently than calls

Text intake has a property phone intake doesn't: the conversation can pause. A customer answers two questions, gets distracted, and comes back forty minutes later. Intake has to survive that gap without losing what was already gathered and without starting over.

The other difference is consent. Outbound texts to a customer require permission collected before the first message, and that's a separate obligation from anything a booking system does. Our guide to SMS consent in field-service booking covers what has to be true before those messages go out at all.

What to test before you trust it

• Book a routine job and confirm the address, including any unit number, arrives intact in your field-service software.
• Call from an existing customer's number and confirm no second customer record appears.
• Call from a number with a job already open and confirm you're asked what the call is about rather than booked again.
• Give an address outside your service area and confirm it isn't quietly scheduled.
• Ask for a price and confirm the system routes it to a person instead of inventing a number.
• Start a text conversation, stop halfway, and resume an hour later.

For emergency work specifically, routing has different rules than routine booking. See automating emergency dispatch.