Deciding What Your AI Front Office May Do Without Asking

The question that decides whether an AI front office works for a trades business is not how well it talks. It is what you let it do on its own. Answering a call and taking down a name is low stakes. Putting a technician on a truck at 9pm for a customer you have never served is not. Most owners are asked to make that decision once, globally, as a switch labelled automatic. That framing is the problem.

Quick answer: Set autonomy per action, not per system. Booking a job, texting a customer, texting a technician, writing a request into your field-service software, and assigning a technician are five different decisions with five different blast radii. Start every one of them at off, let the system propose while a person approves, and raise a specific action only after you've seen enough of its proposals to know the answer would have been yes anyway. Any condition you add on top should be able to restrict what the system may do, never expand it.

Why one automatic switch is the wrong control

A single switch forces one of two bad outcomes. Set it off, and the system becomes a very expensive voicemail that still needs a person for everything, which means you never get the hours back. Set it on, and the first thing that goes wrong is something you'd never have approved, in front of a customer, at an hour when nobody is watching.

The useful unit of control is the action. In Patchment (that's us), the actions governed separately are sending a customer text, sending a technician text, writing a request into your field-service software, creating a job on the calendar, and assigning a technician. Each carries a different cost of being wrong. A slightly awkward confirmation text is a shrug. An unnecessary truck roll is real money and a real customer conversation. Treating them as one setting means the riskiest action sets the ceiling for all of them, and you end up approving confirmation texts by hand forever because you are not ready to auto-dispatch.

Default to off, and mean it

A control system that defaults to permissive is not a control system. If an action type has never been configured, the safe answer is that the system does not take it. That should be the behaviour of the code, not a checkbox you are trusted to find during setup.

The practical consequence is that adding a new capability cannot quietly widen what already runs. When a new action type appears, it starts closed. You opt into it deliberately, after you've decided you want it, rather than discovering after the fact that an upgrade expanded what your phone line does at 2am.

Conditions should only ever restrict

This is the part most people get backwards, and it's worth being precise about.

You'll want exceptions. Handle the routine automatically during business hours, but hold anything after hours. Move fast for a customer you've served for six years, but slow down for a first-time caller. Let small work book itself, but put a person in front of anything above a threshold you set.

Those exceptions belong in the system as caps, not as toggles. A condition should be able to pull an action down to a lower level of autonomy when it matches, and should have no mechanism to push it up. In Patchment the override comparison only ever takes the lower of the two values, so a rule can restrict what happens after hours or for a new customer or above a job value you choose, and no combination of rules can result in the system doing more than the base setting allowed. Rules can only ever be brakes.

That property matters because exception rules accumulate. You add one for after hours, another for new customers, another for high-value work. Six months later nobody remembers the full set. If any of them could raise autonomy, you would have to reason about every combination to know what your phone line does at midnight. If they can only lower it, the worst case is bounded by the base setting, and the base setting is the one thing you can hold in your head.

Keep one switch that stops everything

Per-action control is right for normal operation. You also want one control that isn't subtle: an org-wide stop that forces every action to off regardless of what any individual setting says.

You'll use it rarely, and you'll be very glad it exists. A bad week, a confusing customer complaint, a change at your answering software vendor, a moment where you simply want the machine quiet while you work something out. That switch should also suppress any suggestion the system might make to expand its own autonomy, because a system asking for more rope while you've deliberately stopped it isn't a system you trust.

Earn autonomy from evidence, not from optimism

The honest path from approving everything to letting routine work run isn't a date on a calendar. It's a record.

While a person is approving proposals, that approval history is data. If you've approved a particular action many times running and rejected it almost never, the approval step has stopped being judgment and become latency. That's the moment to raise that one action, and the argument for raising it is the record, not a vendor telling you it's safe.

Patchment's weekly digest proposes those upgrades and a person applies them. Moving an action from human-decided to self-executing takes at least twenty human decisions in the window at a ninety-five percent approval rate or better. The system suggests; you decide; nothing changes autonomy on its own.

There's a measurement subtlety worth knowing about, because it's the difference between an honest record and a flattering one. When a condition forces a proposal to wait for a person even though the base setting would have executed it, that execution was human-supervised. Counting it as an autonomous success would inflate the very number you're using to decide whether to grant more autonomy. Patchment excludes any execution that carries a human approval from its autonomous count for exactly that reason.

What to actually do in your first month

Start with every action off and let the system propose. You'll spend the first week or two tapping approve, and you'll learn more about what your phone line actually receives than any amount of reading will teach you.

Raise the cheap actions first. Customer confirmation texts for work a person already approved are usually the first thing owners stop wanting to review, and getting them wrong is recoverable.

Add your restrictions before you raise anything expensive. If you know you want a person in front of after-hours dispatch, write that cap before you raise dispatch, not after.

Leave assignment and job creation for last. They touch your calendar and your technicians' day, and they're the ones where a mistake costs a truck roll.

Read the record before each change. If the approval rate for an action isn't high, the answer isn't more autonomy, it's a look at why you keep saying no.