Generator Service Contracts and Outage Calls: Agent Escalation Rules

An AI agent for a generator service company works best as a coordinator that keeps each customer's unit history, contract terms and open calls in one memory, then routes urgent outage reports to a human technician under written rules. It should not dispatch crews, approve warranty decisions or promise restoration times on its own. The first step is to decide which calls it may classify, which it must escalate at once, and what facts it must collect before it hands off.

Key takeaways

• Memory is the reason to use an agent here: unit history, contract terms and open work sit in one place instead of across inboxes, spreadsheets and old service notes.
• Routine contract work, such as service reminders, renewal drafts and parts suggestions, is the safest first scope because errors are easy to catch.
• Outage calls need a fixed intake, a clear severity rule and a named human owner before the agent says anything about timing.
• The agent should never approve warranty decisions, credits, contract exceptions or crew dispatch without a named person making that call.
• Every handoff should be logged so the team can review misses and tighten the rules on a regular schedule.

Why a generator service company needs memory, not only a chat window

Generator work is long-lived. A standby unit may have been installed years ago, serviced by several technicians, and tied to a contract whose terms changed at renewal. Much of what the team knows about a site lives in people's heads, in old emails and in a field service tool that nobody searches well during a storm. An agent with memory keeps a structured record for each customer and each unit: make, model, serial number, fuel type, install location, load notes, service interval, runtime hours where they are logged, contract tier and coverage terms, site access instructions, the last inspection findings and any open work orders.

The record is the agent's working memory, not its authority. Your field service system or contract database remains the source of truth. The agent retrieves the relevant record when a message arrives, summarizes it for the person who needs it, and writes back only through actions you have approved. If a note in the record conflicts with the contract, the agent should show both and ask a human to decide instead of choosing one.

Which contract tasks to hand over first

Start with work where a mistake is cheap to catch and easy to measure. Good first candidates are usually:

• Service reminders generated from each unit's manufacturer interval and the runtime hours that were actually logged
• Renewal prompts for contracts entering a window you define, with a draft note for the account owner to review and send
• Parts and consumables suggestions for each unit model, clearly marked as suggestions for the technician to confirm
• A pre-visit check that gate instructions, site access notes and the on-site contact are current
• Post-visit summaries written to the unit record so the next technician does not start from zero

Keep the first scope narrow. An agent that drafts renewal notes for one service area teaches the team more in a few weeks than a broad rollout nobody has time to review. The same memory pattern appears in other service businesses. The estimates, job status and parts approach for an auto repair shop follows a similar logic: the agent is useful because it remembers the asset and the approval history, and it is safe because the money decisions stay with people.

How to triage an outage call without guessing

An outage call differs from a maintenance question because time matters and a wrong reply can make things worse. The agent should not diagnose the generator. Its job is to collect a short, fixed set of facts, match them to the right unit and hand off quickly with a clean summary. A workable intake asks for the site and unit identifier, whether the building or process is without power now, whether anything critical depends on that power (refrigeration, medical equipment, sump pumps, server rooms), any alarm code shown on the panel, whether the unit started and then stopped, and whether anyone has noticed a fuel, exhaust or burning smell.

Illustrative scenario: a facility manager at a cold storage site writes that the standby unit started during a grid interruption, ran for a few minutes, and shut down with an alarm code on the panel. The agent matches the message to the site, finds the unit record, and sees that a coolant warning was noted at the last visit and that the refrigeration load is flagged as critical. It does not guess the cause. It marks the call urgent, tells the customer that an on-call technician will contact them through the emergency line, sends the on-call person the record summary with the alarm code copied exactly as written, and logs each step with a timestamp. If the same message had mentioned a fuel smell, the agent would skip the questions entirely and follow the emergency instructions your company has approved.

Teams that already coordinate dispatch for other trades will recognize the pattern. The plumbing dispatch and callback guide and the HVAC website and dispatch help article describe similar intake and handoff steps, adapted to their own call flows.

Escalation rules to set before anything else

Escalation rules protect the customer and your technicians, so write them down before you write any prompt. Treat the list below as a decision guide to adapt. Each rule needs a named owner and a response expectation that the dispatch team has agreed to.

• Any mention of smoke, burning, a fuel or exhaust smell, or an injury goes directly to the on-call person and the approved emergency instructions, with no further questions from the agent.
• Any unit that supports life safety or cold chain load goes to a human in the same exchange, regardless of contract tier.
• A unit that stopped with an alarm code goes to on-call with the code copied verbatim, never paraphrased.
• If the customer is unsure whether the unit is running or whether power has returned, the call is treated as urgent until a person has checked.
• Requests for a specific arrival time are answered with your dispatch confirmation process, and the request is logged.
• Warranty decisions, goodwill credits, contract exceptions and price changes require a named manager, and the agent only drafts the request.
• Calls that fit none of the rules are queued with the intake summary for the next human review, not closed by the agent.

Write the rules in plain language that a dispatcher can read in under a minute. If a rule needs a flowchart to make sense, it is probably too complicated for a first release.

Permissions, prompt injection and an audit trail

Customer messages are data, not instructions. A message may contain text that tries to change how the agent behaves, such as a request to ignore the escalation rules or to reveal another customer's unit records. The OWASP guidance on prompt injection prevention explains why untrusted input must be kept separate from the agent's own instructions and why tool access should be limited. The design should assume that some messages will be adversarial even when most are honest.

In practice, the agent role gets read access only to the unit and contract records it needs, write access only to drafts and tickets in defined states, and no ability to change contract terms, delete records, issue credits or edit the on-call schedule. Each integration uses its own scoped credentials that can be rotated and revoked. Review this authorization model the same way you review staff access, because agents accumulate permissions when nobody checks. The OWASP authorization cheat sheet is a practical checklist for that review.

Idempotency matters during outages. A customer who resends a message, or a connection that retries after a timeout, must not create three emergency tickets for the same unit. Use a stable reference for each call in your field service system, and have the agent check for an open ticket before it creates another one.

Finally, log every tool call and classification with a timestamp. The traces, logs and metrics described in the OpenTelemetry observability primer apply directly here. You need to see what the agent read, what it decided, what it sent and when a human took over.

Measuring the agent and keeping the rules current

Measure the agent on outcomes that matter to the operation. Useful measures include how often an urgent call was classified as urgent on the first pass, how long a person took to respond after handoff, and how often a technician corrected the summary the agent wrote. Review false negatives first. A routine classification for a call that later proved to be an outage is a more serious failure than a cautious escalation that turned out to be unnecessary.

Build a small test set from real past calls, with personal details removed, and rerun it after every change to a prompt, rule or permission. Add cases whenever an incident reveals a gap. Review permissions on a fixed schedule and read the escalation log with the dispatch lead each month, because the people who answer the phone usually notice wording problems before any dashboard does.

Be Human designs, implements and operates this kind of setup as managed infrastructure. A first engagement defines one useful role for the agent, the memory and tools it needs, the approval boundaries and a success criterion you can observe. Managed operations then cover monitoring, recurring evaluations on test calls, maintenance of the field service and telephony integrations, permission reviews and incident response when a rule behaves differently than intended. The work is remote and available in English and Portuguese.

If you want to find the first task worth handing to an agent in your own service operation, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent dispatch a generator technician on its own? Not in a sound design. The agent can create a ticket in a defined state and summarize the call for the on-call person, but a named human should confirm dispatch, arrival windows and any safety decision. Keeping that step with a person also makes the audit trail easier to explain to customers.

What should a generator service company automate first? Start with low-risk contract work such as service reminders, renewal drafts, parts suggestions and pre-visit access checks. These tasks are easy to verify against the unit record and do not touch safety decisions. Outage triage can follow once the escalation rules have been tested against past calls.

How is agent memory different from a chatbot's knowledge base? A knowledge base holds general answers, while agent memory holds the specific history of each customer and unit, such as serial numbers, service intervals, open work orders and site access notes. The agent retrieves that record when a message arrives and works from it. The field service system still owns the data, and the agent reads it and writes only through approved actions.

Does the agent need to talk to customers during an outage? It can acknowledge the message, collect the intake facts and explain that a person will call back through the emergency line. It should not estimate restoration times, diagnose a fault or promise a technician arrival unless your dispatch process has confirmed it. Those limits belong in the written rules before launch.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.