Published · Updated
Your first AI workflow should reduce the team's workload without leaving customers with more errors or repeat contacts. Choosing it also determines which systems you must connect and what work will still need a person.
Start with a specific request you receive often, can answer from reliable records, and can handle within clear permissions. Billing can fit that description, but "automate billing" is too broad: explaining a payment reminder and deciding a disputed debt are different jobs.
A useful first case is large enough to matter and narrow enough to test. Here is how to choose one without treating a whole ticket category as low risk.
Start with the question, not the department
One of our customers, an energy utility, was exploring an AI-agent expansion in September 2026. Its service lead estimated that about 30% of requests concerned customers who had paid, but paid late. He wanted to start with the payment-reminder case shown in the demonstration.
That was a reported share of this team's requests and a proposed starting point. It was not an automation result, and it does not establish that a third of another company's tickets will be suitable.
The useful detail is the customer's question: "I have paid. Why did I receive a reminder?" To answer it, the system needs the right account, payment and reminder records. A general explanation of the billing policy is not enough.
Trace the whole task before choosing it
Take a sample of this request type and follow what the support team does today:
- How do they verify the customer and locate the account?
- Which record establishes whether the payment arrived, and how current is it?
- Can they explain the reminder from that record, or must someone investigate?
- Does the case require an action, such as correcting a record, that needs separate authority?
- What happens if the records disagree or the customer disputes the answer?
This separates a repeatable lookup from a decision that requires judgment. Keep those branches distinct in the proposed workflow. Our guide to AI-agent permissions explains how to grant access and actions separately.
Give the exceptions a real destination
An initial scope might cover explaining a confirmed payment and the timing of a reminder. Disputed charges, requests for payment arrangements and missing payments could stay with people until the relevant rules, data and approvals are established. These are examples of a boundary to agree with your team, not a policy every business should adopt.
For each excluded branch, name the receiving team and the information it needs. The customer should not have to repeat the account details and explanation they already gave. Test a normal request and an exception together: an answer can be correct at first and still fail when the customer adds new information.
Do not classify a case as automated if a person had to check the record, approve the reply or finish an action. Record that work as assistance.
Rank candidates by useful work completed
Compare a few narrowly defined requests on volume, handling effort, data readiness and the consequences of an error. A high-volume category with missing payment data may be a worse first choice than a smaller category the system can complete reliably.
Also ask whether the question should exist. A confusing payment notice might need clearer wording or a self-service link before it needs AI. The guide to reducing avoidable contacts covers that decision.
Choose one candidate and write its boundary in a sentence: which request, which records, which permitted actions and which exceptions go to people. Then take it through a supervised pilot. The goal is to learn whether this workflow works, not to prove that every ticket about money should be automated.
