Choosing an AI Feature in Your Field Software

Why this matters

Field service software now ships AI features the way it used to ship report templates: an invoice-description writer, a job-duration predictor, a call summarizer, a "suggested next step" on every lead. Each one is demonstrated on a clean sample account where it looks excellent, and each one, once switched on, starts touching your customer records, your pricing and the words that go out under your name. The decision to turn one on is usually made in the ten minutes after a webinar. It deserves an hour, and most of that hour should be spent on your own jobs, not the demo.

The five questions, and why each one is the one that bites

These go to the vendor in writing, and you keep the answers. A salesperson's verbal "yes" is worth what you paid for it.

1. What data does it use, and where does that data go? The feature reads something: job notes, photos, call audio, customer history, prices. Ask which fields, whether that data leaves the vendor's own systems for a third-party AI provider, whether your data is used to train or improve models for other customers, and whether you can opt out of that without losing the feature. The shop's own rules about what customer data may reach any AI tool come from its policy (see related: The Shop AI Use Policy SOP), and a feature built into your software is still an AI tool for that policy's purposes. What bites if you skip it: you made a privacy commitment to customers (see related: The Customer Privacy Promise When You Use AI) that the feature quietly breaks.

2. Can you turn it off, at what level, and what happens when you do? Off for the whole account, per user, per feature? Does switching it off stop new processing only, or also delete what it already generated and stored? Is it on by default for new users you add later? A feature you cannot switch off for one user is a feature you cannot pull from the new hire who is not trained yet. When to actually turn one off is its own card (see related: When to Turn an AI Feature Off). What bites: the feature misbehaves and your only lever is a support ticket.

3. Can you see why it suggested what it suggested? A good feature shows its source: the line item came from this photo, this note, this past job. A black box produces an answer with no trail. You need the trail because the person reviewing the output has to check it against something, and "the software said so" is not something. What bites: a reviewer cannot tell a correct suggestion from an invented one without redoing the work, which erases the time saved.

4. Can you export what it produced, and your edits to it? If the feature writes invoice descriptions, those descriptions are your records. Can you get them out in a standard file along with everything else when you change software? Are your corrections to its drafts stored, and do they leave with you? What bites: years of AI-assisted records that only exist inside one vendor's system.

5. Who is responsible when it is wrong? Read the terms of service for the AI feature specifically. Vendors commonly disclaim the accuracy of AI output and place responsibility for reviewing it on the customer, and some carve AI features out of their general warranties or limit liability for them more tightly than the rest of the product. That means when a feature drafts a message that promises something you do not offer, you are the one who made the promise to your customer. How those clauses apply in your state, and whether an indemnity in your contract covers any of it, is a question for your attorney; walk in with the terms document, the feature's description and an example of the output you are worried about. What bites: you assumed a vendor stood behind the feature it sold you, and it does not.

A feature that fails question 1 or question 5 badly enough is a no regardless of how well it performs. The rest is a trade-off you make with the trial.

The trial: twenty of your own past jobs

A demo account has clean notes, complete photos and typical jobs. Yours do not, and the gap between the two is exactly where an AI feature fails. So test it on work whose correct answer you already know.

Pick twenty completed jobs from the last few months. Mix them deliberately: a dozen typical jobs of your most common types, five that went sideways (a callback, a change order, a dispute), and three with bad source material (a tech's one-word note, blurry photos, a job split across two visits). The messy ones matter most, because a feature that only works on clean input will be working on messy input every afternoon.

Run the feature on each and grade the output against what actually happened. Three grades are enough:

• Usable: a reviewer accepts it with light edits.
• Rework: right idea, but a reviewer has to rewrite substantial parts.
• Wrong: states something that did not happen, or misses something that did, in a way that would mislead a customer or a tech if it shipped.

Time it. Record how long the reviewer spends on each output, from opening it to accepting it, and compare against how long the same task takes today with no feature.

Have the person who will actually use it run the trial. If the office manager reviews invoice descriptions, the office manager runs it. An owner who does not do the task daily will judge it on how impressive it looks.

Worked example: an invoice-description writer

A twelve-person HVAC and plumbing shop is offered a feature that reads the tech's job notes and photos and drafts the line-item descriptions on the invoice. Today the office manager writes those from the tech's notes, taking about 11 minutes per invoice on average.

The written answers. Question 1: the vendor sends notes and photos to a third-party AI provider, does not use the shop's data for training by default, and offers a written data processing agreement. Acceptable. Question 2: the feature can be switched off per user, and generated drafts stay in the invoice history after it is switched off. Acceptable, noted. Question 3: each drafted line links to the note and photo it came from. Good. Question 4: drafts and edits export with the invoice records. Good. Question 5: the terms disclaim accuracy of AI-generated content and require the customer to review before sending. Expected, and it means review is mandatory, not optional.

The trial results, twenty jobs:

172 minutes over 20 invoices is 8.6 minutes each, against today's 11. That saves 2.4 minutes per invoice, about 22 percent of the current 11 minutes. The rework jobs took longer than writing from scratch (14 minutes against 11), which is normal: fixing a confident wrong draft is slower than writing a right one. The feature earns its time on the usable thirteen.

The two wrong outputs are the real finding. Both described a part replacement that did not happen. In one, the tech had written "checked cap, ok"; the feature drafted "replaced run capacitor." In the other, a photo of an old part next to a new boxed part (the tech had brought it but not needed it) produced a replacement line. Each took the reviewer 12 minutes because she had to go back to the tech to confirm. If either had shipped, the customer is billed for a part and labor that never happened.

The decision. Two wrong in twenty is 10 percent of invoices carrying a billing error if review slips. The shop turned the feature on for the office manager only, kept it off for anyone not trained on reviewing it, and added one check to the review: every replaced part in a drafted description must appear in the job's parts-used record. That check takes seconds, because the software already records parts used. After the change, the shop re-ran five messy jobs and the parts check caught the one wrong draft that appeared.

What would have changed the decision. If the feature had offered no source link (question 3), each review would have meant re-reading all the notes and photos, and the 6-minute usable review would have grown toward the 11 minutes it replaced. The shop would likely have declined. If the trial had shown wrong outputs that no simple record check could catch, such as invented diagnostic findings rather than invented parts, the shop would have declined, since review would then depend entirely on the reviewer's memory of a job they did not attend.

Measuring after you switch it on

The trial is twenty jobs; the real test is the first two months. Keep the same three grades on a sample of ten outputs a week, and keep timing them. Two things to watch: whether the wrong rate drifts up as the vendor updates the feature (vendors change the underlying model without much notice, and behavior changes with it), and whether review time quietly shrinks toward zero, which means people have stopped reviewing. The full method for measuring time saved is its own card (see related: Measuring Whether an AI Tool Actually Saved Time).

What a new AI feature should never be allowed to do on its own

Regardless of how the trial goes, a feature should not send anything to a customer without a person approving it, change a price, mark a job complete, or close a ticket. These are the actions where an error reaches a customer or the books before anyone sees it. If the feature's default is to do any of these automatically, change the default before going live, or decline the feature.

References

• The vendor's terms of service, data processing agreement and AI feature documentation, read in full before switching on
• See related: The Shop AI Use Policy SOP
• See related: Measuring Whether an AI Tool Actually Saved Time
• See related: When to Turn an AI Feature Off
• See related: The Customer Privacy Promise When You Use AI