Example Automation Scenarios

Three worked scenarios. Each one shows what happens today, what we would change, where a person has to approve, and what the pilot measures.

The examples below are illustrative scenarios, not client engagements or promised results. Actual scope and baselines are established during the paid audit.

Illustrative Scenario

Lead intake to CRM

Illustrative scenario · not a client engagement

Current situation

A B2B services company receives enquiries through a website form and a shared inbox. Two people check both surfaces during the day, and nobody owns the handover between them.

How it works today

Someone reads the message, copies the details into the CRM by hand, guesses whether the company already exists as a record, then messages a colleague to decide who follows up.

The flow we propose

A single, clearly defined flow captures both sources, validates and normalises the fields, checks the CRM for an existing record, applies written routing rules, and drafts an acknowledgement for a person to send.

Human control points

A person sends the acknowledgement; the system only drafts it.
Sensitive or high-value enquiries are escalated to a named owner before any reply leaves.
Any suspected duplicate is flagged for review rather than merged automatically.

What the pilot measures

Time to first action against the agreed baseline
Share of leads with a named owner
Duplicate record rate on the test set
Required-field completeness

Technical detail and assumptions

Failure and delay points

Enquiries arriving outside working hours wait until someone opens the inbox.
The same company is entered twice under slightly different names.
Required fields are left empty because the enquiry did not contain them.
Ownership is decided informally, so some leads have no owner at all.

Systems and data

The website form, one shared mailbox, and CRM systems through supported APIs and webhooks. Only the fields needed for routing and acknowledgement are read, and enrichment is limited to sources the client is permitted to use.

Baseline assumptions

Assumed volume: about 60 enquiries a month across both channels. This is an assumption for scoping, not a measured figure.
Assumed manual handling: roughly 6 minutes per enquiry today, based on a walkthrough rather than a time study.
Assumed duplicate rate: around 1 in 10 records, taken as a planning assumption only.

Pilot scope

One lead source, one routing ruleset, one CRM object, and drafted acknowledgements only. No outbound campaign, no scoring model, no changes to existing CRM records outside the pilot ruleset.

Risks, exclusions and fallback

If the CRM API is unavailable, the flow queues the record and alerts a person instead of dropping it.
Ambiguous or malformed enquiries go to an exception queue for manual entry.
This scenario is about handling and data quality. It makes no claim about sales results.

What moving to production would require

A named process owner, agreed routing rules in writing, CRM credentials with least-privilege scope, a retention decision for the queued payloads, and a rollback that disables the flow without losing enquiries.

Illustrative Scenario

Support triage with human handoff

Illustrative scenario · not a client engagement

Current situation

A small support team handles one email queue. A large share of the questions repeat, and the answers already exist in internal documents that are hard to search quickly.

How it works today

Each message is read, someone searches shared documents for the relevant policy, writes an answer from memory when the search fails, and forwards anything account-specific to a colleague.

The flow we propose

One queue is classified, an approved knowledge set is searched, and an answer is drafted with citations to the documents it came from. Anything below the confidence threshold, account-specific or policy-sensitive is escalated instead of answered.

Human control points

Every drafted answer is reviewed by an agent before it is sent during the pilot.
The system does not answer and passes the case to a person when it cannot cite an approved source.
Account-changing requests are never actioned by the system, only routed.

What the pilot measures

First-response time against the agreed baseline
Citation correctness on an agreed test set
Rate of answers with no supporting source
Escalation accuracy on cases that should have been escalated

Technical detail and assumptions

Failure and delay points

Answers vary between team members because the source is not consistently checked.
Repeat questions consume the same effort every time.
Account-specific requests sit in the queue until the right person is free.

Systems and data

One email queue and an approved set of documents the client agrees in advance. Nothing outside that set is retrieved, and the drafted answer carries the citation list with it.

Baseline assumptions

Assumed volume: about 300 messages a month in one queue. Assumption for scoping only.
Assumed repeat share: roughly half the questions are variations of known topics. This is an assumption to be tested during the pilot, not a measured baseline.
Assumed knowledge set size: around 40 documents, kept deliberately small so citation quality can be judged.

Pilot scope

One queue, one approved knowledge set, drafts only, and a fixed confidence and policy rule for escalation. No autonomous sending, no account changes, no additional channels.

Risks, exclusions and fallback

If retrieval quality drops below the agreed threshold, drafting is disabled and the queue returns to manual handling.
Out-of-scope topics are escalated rather than answered from general knowledge.
Availability of the underlying model provider is a dependency outside this workflow.

What moving to production would require

An owner for the knowledge set with a review cadence, an agreed escalation policy, logging and retention boundaries for message content, an evaluation set that is rerun after changes, and a safe-disable switch.

Illustrative Scenario

E-commerce order exception flow

Illustrative scenario · not a client engagement

Current situation

An online seller takes orders on more than one channel. Most orders pass through untouched, but a minority stall on a missing address, a stock shortfall, a payment problem or a shipment that never scans.

How it works today

Someone scans the order lists once or twice a day, spots the stuck ones, opens each channel to check the detail, writes to the customer, and remembers to follow up later.

The flow we propose

Order events are received as they happen, exception types are detected against written rules, an internal task is created with the full context, and a customer message is drafted. A retry can never apply the same action twice.

Human control points

A refund is never issued by the system. It requires explicit human approval.
An order cancellation requires human approval before anything is sent to the channel.
Any price change is approved by a person, never applied automatically.
Customer messages are drafted for review during the pilot rather than sent directly.

What the pilot measures

Time from the event to the first human action
Manual steps per handled exception
Duplicate action rate on the test set
Share of exceptions where the customer was informed before contacting support

Technical detail and assumptions

Failure and delay points

Exceptions are found late because nothing raises them proactively.
The same message is sent twice when two people pick up the same order.
Stock counts drift between channels while an exception is open.
Customers contact support because they were not told anything.

Systems and data

Order and stock events from the sales channels through supported APIs and webhooks, an internal task list, and a notification channel for the team. Only the order fields needed to classify and explain the exception are read.

Baseline assumptions

Assumed volume: about 1,200 orders a month across channels. Scoping assumption, not a measured figure.
Assumed exception rate: roughly 4 percent of orders, used only to size the queue.
Assumed detection delay today: several hours, based on how often the lists are checked rather than on logged data.

Pilot scope

One exception path from event to drafted notification, on one channel, with human approval on every irreversible action. No pricing automation, no channel-wide stock rewriting, no automatic refunds.

Risks, exclusions and fallback

Channel API limits and provider outages are dependencies. When events cannot be read, the flow alerts the team instead of assuming there is nothing to do.
The workflow is designed to reduce overselling risk across channels, not to remove it.
If idempotency cannot be established for an action, that action stays manual.

What moving to production would require

Written exception rules agreed with the operations owner, an approval path with named approvers, durable idempotency keys, a retention decision for order data, and a rollback that stops the flow without leaving exceptions unattended.