equationx
FieldbookBook a call
AI Operations Fieldbook · Example 01

Should this workflow become an AI agent?

A worked example for teams automating customer enquiries. It covers the workflow, approval boundaries, failure handling, and measures that matter after launch.

The situation

Respond to a new enquiry without losing context

A website form arrives. Someone checks whether the person already exists in the CRM, searches old messages, finds the right service information, decides who should own the lead, writes a response, and sets a reminder. The reply is not the workflow. The workflow is everything required to make that reply correct and actionable.

40
enquiries each week
15 min
manual handling each
10 hrs
median reply delay
3 systems
inbox, CRM, knowledge

Example assumptions for evaluating the pattern.

The design

Automate the preparation. Keep consequential decisions visible.

01

Capture the enquiry

Receive the form or email, preserve the original message, normalise the contact details, and check for an existing CRM record.

Do not create a duplicate customer when the match is uncertain.

02

Gather the right context

Pull the lead source, previous conversations, approved pricing, service area, availability, and the relevant policy or product information.

Only retrieve information the assigned team member is allowed to see.

03

Classify and prepare

Identify intent, urgency, fit, missing information, and the next best action. Draft a reply using the business's approved facts and tone.

Low-confidence classification and unusual requests go to a person.

04

Ask for approval where it matters

Routine acknowledgements can follow a pre-approved rule. Pricing, commitments, exceptions, and sensitive replies wait for review.

The agent never invents a price, deadline, entitlement, or policy exception.

05

Record and follow through

Save the enquiry, source, draft, decision, owner, and follow-up date. Alert the owner when the lead is untouched or the customer replies.

Every action must be traceable and safe to retry without sending twice.

Control

Decide authority before choosing a model

Most production failures are not writing problems. They are unclear authority, unsafe retries, missing context, or no owner for exceptions.

Agent can do

  • Capture and deduplicate an enquiry
  • Retrieve approved business information
  • Classify intent and urgency
  • Draft a reply and create a task

Person reviews

  • Prices, quotes, and commercial promises
  • Complaints or unusual exceptions
  • Low-confidence customer matches
  • The first version of a new workflow

Agent must never

  • Invent a policy, price, or deadline
  • Bypass role-based permissions
  • Hide the source of an action
  • Repeat an irreversible action blindly
Steal this

Production-readiness checklist

  1. 01Write down the trigger, successful outcome, and owner.
  2. 02List every system and the minimum permission required.
  3. 03Define what the agent may do, must ask about, and must never do.
  4. 04Create examples of normal, ambiguous, and adversarial inputs.
  5. 05Make retries safe: the same event must not create duplicates or send twice.
  6. 06Log the input, retrieved sources, decision, action, and approver.
  7. 07Set an alert for failures, stale work, and unusual volumes.
  8. 08Review real outcomes after launch—not only model accuracy.
Decision drills

Test the operating judgement, not the vocabulary

Decide before opening each answer. These are the questions that change whether an automation is useful, risky, or merely expensive.

01The draft is correct 97% of the time. Should the agent send every reply automatically?+
Not from accuracy alone. Separate low-risk acknowledgements from messages that quote prices, make commitments, handle complaints, or disclose account information. Automate by consequence, not by one average accuracy number.
02A task takes four hours but only happens twice a month. Is it worth automating?+
Possibly. Eight hours saved is only part of the calculation. Include delay, error cost, interruption, specialist dependency, and whether the same pattern appears elsewhere. Start with a reusable step—not a custom system for one rare task.
03The CRM API failed after the email was sent. What should happen next?+
Do not send again. Record a durable operation ID before acting, make each step idempotent, and retry only the failed CRM write. The recovery path is part of the workflow design, not an implementation detail.
04A team wants a chatbot because customers ask many questions. Is that enough reason?+
No. First identify the questions, source quality, escalation path, and actions the assistant may take. If the knowledge is outdated or ownership is unclear, the chatbot will expose the problem rather than solve it.
Measure

Measure the workflow, not the demo

Median time to first useful response
Percentage requiring human correction
Duplicate or missed enquiry count
Qualified leads progressing to the next stage
Failures recovered without customer impact
Hours returned to the team each month
Next patterns
Pattern 02

Turn a meeting into CRM updates without trusting a summary blindly

Which facts can be recorded automatically, and which need confirmation?

Pattern 03

Extract documents without letting one wrong field corrupt the system

How should confidence, validation, and exception queues work together?

Pattern 04

Triage a shared inbox without creating another inbox to monitor

What should be routed, drafted, escalated, or ignored?

Your workflow

Send us one repetitive process. We’ll tell you what we would automate—and what we would leave alone.

No prepared brief required. A rough description of the trigger, systems, and bottleneck is enough.

Share a workflow