Built-In AI or a Connected Front Office: How to Choose for Your Field-Service Stack

Field-service platforms increasingly ship AI features, and dedicated AI front offices increasingly connect to those same platforms. If you already run one of these platforms, you aren't choosing between AI and no AI. You're choosing where the AI lives and what it's allowed to touch. Those are different questions, and the second one matters more.

Quick answer: Decide by asking what happens when the AI is wrong, not by comparing feature lists. Built-in AI means one vendor and one bill, and the ceiling is whatever that vendor prioritises. A connected front office means the platform you already run stays the system of record while something specialised handles the phone, and the risk moves to the quality of the integration. Judge either one on four things: how granular the controls are, whether it writes into your existing records or beside them, whether it reports what it did in a way you can audit, and what it does when it's unsure.

Start with the decision you're actually making

If you have no field-service platform, this article is premature. Get your jobs and customers into one system first; layering AI on top of a shoebox produces a faster shoebox.

If you already run one, your existing platform isn't in question. Your jobs, customers, schedule, and history live there and should keep living there. What you're choosing is what answers the phone, captures the request, and decides what happens next, and whether that thing is part of the platform or connected to it.

That framing kills a lot of bad comparisons. A demo of an AI feature isn't comparable to a demo of an AI product; what's comparable is what each does with a difficult call at 9pm.

The four questions that actually separate options

1. How granular are the controls?

The single most important question, and the one least often asked in a demo.

Ask whether autonomy is one setting or many. Sending a customer a confirmation, writing up a request, putting a job on the calendar, and assigning a technician carry very different costs when they go wrong. If they're governed by one switch, the riskiest one sets your ceiling, and you'll end up approving harmless messages by hand forever because you aren't ready to auto-dispatch.

Then ask whether conditions can only restrict. You'll want exceptions, such as holding after-hours work for a person or requiring approval above a job value. Those rules should be able to lower what the system may do and have no way to raise it, so that no combination of rules you accumulate over a year can produce more autonomy than your base setting allowed. We go through that in deciding what your AI front office may do without asking.

Finally, ask for the stop. There should be one control that halts everything regardless of individual settings.

2. Does it write into your records or beside them?

The failure mode to avoid is a second source of truth. If the AI keeps its own customer list, its own job records, or its own notion of your schedule, you now reconcile two systems by hand, and the reconciliation is exactly the work you were trying to remove.

Concrete questions: does a booking create a job in the platform you already use, or in the vendor's system with a sync afterwards? Does it recognise an existing customer and attach to that record, or create a new one? Does it import your history at connect time so returning callers are known on the first call?

A built-in feature usually wins this by construction, and that's a real advantage. A connected product can match it, but you should verify it rather than assume it, and the test is simple: book a job as an existing customer and see whether a duplicate appears.

3. Can you audit what it did?

Anything that acts on your behalf should be able to tell you what it did in language you can check, and any number it reports about your savings should come with a method you can read.

Be specific here. Ask how a reported figure is calculated, whether it counts measured time or estimates, whether work a person did by hand is excluded, and whether the number rounds in the vendor's favour. Patchment (that's us) publishes the method behind its estimate of hours handled, counts only measured time on completed calls with a per-call ceiling, gives no credit for messages a person typed themselves, rounds the displayed number down, and suppresses the figure entirely below a threshold rather than printing something near zero. Whether or not you choose us, that's the shape of disclosure worth demanding, and a vendor who can't show you the method is reporting marketing rather than receipts.

Note that Patchment doesn't publish list pricing, because what it costs depends on call volume and configuration. Whichever way you go, get the number in writing against your actual volume rather than a headline rate.

4. What does it do when it's unsure?

The behaviour that separates good from bad isn't the confident path. It's the uncertain one.

Ask what happens on a pricing question. The correct answer is that it declines and routes to a person; a system that invents a number creates an expectation your technician has to walk back on site. Ask what happens with an ambiguous address, with an emergency, with a caller who already has a job open, and with a caller who isn't a customer at all. Ask each of these as a scripted test rather than accepting a general assurance.

Where each option tends to be stronger

Built-in AI has fewer moving parts. One vendor, one bill, one support conversation, and no integration to break. Data lives where it already lived. If your needs are close to the middle of what the platform's customers want, this is often the pragmatic answer, and the honest advice is to try it first because it's the cheapest thing to try.

A connected front office is a specialisation bet. Answering phones well is a different problem from managing schedules well, and a product doing only the former can go deeper into it: call handling, escalation rules, per-action autonomy, technician workflow. The tradeoff is that quality now depends on the integration, which is why the questions in section two exist.

The bet is worth making when the phone is your bottleneck rather than your scheduling. If you're losing jobs because calls go unanswered after hours and on busy afternoons, that's a front-office problem. If your jobs are booked fine but your dispatching is chaotic, more AI on the phone won't fix it.

A short evaluation script

• Book a routine job end to end and confirm it lands correctly in the platform you already run.
• Repeat as an existing customer and check for a duplicate record.
• Ask for a price and confirm it declines rather than quotes.
• Call outside business hours and confirm the behaviour matches what you configured.
• Ask to see the per-action controls, then try to construct a rule that increases autonomy. You shouldn't be able to.
• Ask how any reported savings figure is calculated, and ask for it in writing.

Run the same script against both options. Most of the differences that matter show up in under an hour, and none of them show up on a feature grid. For a plumbing or HVAC shop, that hour is the cheapest diligence available.