Illustrative Cases, by Industry

Case 1 — Professional services: enquiry intake and proposal follow-up

At stake: Enquiries that arrive today but get a named owner tomorrow are proposals that may never be sent — and pipeline the firm cannot see.

Example business: a mid-sized B2B consultancy receiving enquiries through its website and email. No real firm is described.

Result to prove in a pilot: every enquiry reaches a named owner with a follow-up date, and proposals stop stalling for lack of ownership. That result is defined by the measurements below, against your current baseline — it is not a promised improvement.

What it costs today

Enquiries arrive in several inboxes, follow-up depends on who happens to see them first, and proposals stall because no one owns the next step.

Design

1. Enquiry captured from web form and email into one intake list. 2. Enquiry classified by service area and urgency using agreed criteria. 3. A draft acknowledgement and a draft next-step message are prepared. 4. A named team member reviews, edits, and approves the message. 5. The approved message is sent and the activity is logged, with an owner and a follow-up date.

Systems to connect

Website form, email, CRM, shared calendar, document storage for proposals.

Human review points

Classification is checked before routing; every outbound message requires approval; proposal terms are never generated or sent without a named reviewer.

Risk this design prevents: an enquiry with no owner and no follow-up date, so a proposal is never sent.

What the pilot measures

Each measure states its meaning, its source, and its window — and deliberately states no value, because no value exists yet. The window for every measure is the agreed baseline period, then each pilot week.

• First-response time. Meaning: time from an enquiry's arrival to the first approved response. Source: intake-list timestamps and the sent-message record.
• Share of enquiries with a named owner and a follow-up date. Meaning: proportion of enquiries that have both an owner and a date. Source: intake list.
• Time from enquiry to proposal sent. Meaning: elapsed time from an enquiry's arrival to the proposal being sent. Source: intake list and proposal records.
• Enquiry-to-first-call conversion. Meaning: proportion of enquiries that result in a booked first call. Source: intake list and booking records.

If this resembles your bottleneck, mention 'professional services enquiry intake' on the call — we will start from your current workflow, your systems, and the baseline you would measure against.

Synthetic data only. No real customer data is used in this example.

Case 3 — Sales-driven business: lead qualification and CRM hygiene

At stake: A pipeline the CRM cannot be trusted to describe is a forecast the leadership team cannot rely on.

Example business: a sales-led company whose leads come from forms, events, and referrals, and whose CRM records are often incomplete or duplicated.

Result to prove in a pilot: a pipeline the CRM can be trusted to describe, because every lead is qualified against agreed criteria and every record is complete and deduplicated. That result is defined by the measurements below, against your current baseline — it is not a promised improvement.

What it costs today

Good leads are buried among unqualified enquiries, follow-up is inconsistent, and the CRM cannot be trusted for pipeline reporting.

Design

1. Leads from all sources are captured in one intake list. 2. Each lead is checked against agreed qualification criteria and against existing CRM records for duplicates. 3. A draft follow-up and a suggested next step are prepared. 4. A sales owner reviews, edits, and approves the follow-up. 5. The approved activity, qualification notes, and next action are logged in the CRM.

Systems to connect

Website forms, event lead lists, email, CRM, calendar.

Human review points

Qualification criteria are agreed in advance; duplicates are confirmed by a person before merging; no lead is contacted automatically without an approved draft and a named owner.

Risk this design prevents: a lead contacted twice, or never, because the CRM holds duplicates.

What the pilot measures

Each measure states its meaning, its source, and its window — and deliberately states no value, because no value exists yet. The window for every measure is the agreed baseline period, then each pilot week, except where stated.

• Lead response time. Meaning: time from a lead's arrival in the intake list to the first approved contact. Source: intake-list timestamps and the sent-message record.
• Share of leads qualified within an agreed window. Meaning: proportion of leads that pass the agreed qualification criteria within the window the business sets. Source: intake list and qualification records.
• Share of CRM records complete and deduplicated. Meaning: proportion of CRM records with all required fields filled and no unresolved duplicates. Source: CRM record audit. Window: measured at the start of the baseline period and at each pilot review.
• Qualified-lead rate. Meaning: proportion of all leads received that meet the agreed qualification criteria. Source: intake list and qualification records.
• Discovery-call booking rate. Meaning: proportion of qualified leads that result in a booked call. Source: booking records and the CRM.

If this resembles your bottleneck, mention 'sales lead qualification' on the call — we will start from your current workflow, your systems, and the baseline you would measure against.

Synthetic data only. No real customer data is used in this example.

Case 3 in full depth — a worked example

Fictional company: Northbridge Supplies (fictional example company — not a real client, and not based on any real business). The company sells office supplies to other businesses. Leads arrive from website forms, event lists, and referrals, and its CRM records are often incomplete or duplicated. Nothing below is a result: every number-shaped field is a blank to be filled from a real pilot, and every KPI is defined without a value.

The exact trigger

A new lead arrives through any of three routes: a website form submission, an event lead list upload, or a referral passed on by email. Arrival creates one entry in a single intake list. No lead is contacted at this point, and no record is written to the CRM yet.

The data fields used

Only these fields are used: lead name, work email, company name, lead source (form, event, or referral), enquiry text, and — for matching only — the name, company, and email domain of existing CRM records. No other personal data is used, and no field is collected that the business has not already provided through its own forms and lists.

The draft produced

For each lead that passes the agreed qualification criteria, a draft follow-up is prepared from a template, for example: “Hello [Name], thanks for your enquiry about [service area]. Based on what you shared, a short call to discuss [topic] looks like the right next step. Would [day and time options] suit you?” The bracketed parts are filled from the lead's own enquiry text. The draft is never sent as written: it waits for a named sales owner to review, edit, and approve it.

The approval rule

One rule governs every lead: no lead is contacted without an approved draft and a named owner. Duplicates are confirmed by a person before any records are merged — the system suggests a possible duplicate, a person decides. Qualification criteria are agreed in advance and written down before the pilot starts, not adjusted to fit the leads that arrive.

When confidence is low

If a lead cannot be matched confidently against the qualification criteria — for example, the enquiry text does not say what the business needs, or the company details are missing — no draft is prepared and no contact is made. The lead is routed to the named sales owner for manual qualification, with the reason recorded (“insufficient information” or “unclear need”). Low confidence never produces a guess dressed as a qualified lead.

When the CRM is down

If the CRM is unavailable, leads stay in the intake list and nothing is sent. When the CRM is available again, the queued leads are processed in arrival order under the same approval rule. No lead is contacted during an outage, and no record is written until the system that holds it is reachable.

How the baseline would be measured in week 1

Before any automation is switched on, the baseline is measured over an initial period agreed with the business (for example, the two weeks before the pilot). The same definitions are used before and during the pilot, so the comparison is like for like. Each KPI below states its meaning, its source, and its measurement window — and deliberately states no value, because no value exists yet.

• Lead response time. Meaning: time from a lead's arrival in the intake list to the first approved contact. Source: intake-list timestamps and the sent-message record. Window: the agreed baseline period, then each pilot week.
• Share of leads qualified within an agreed window. Meaning: proportion of leads that pass the agreed qualification criteria within the window the business sets. Source: intake list and qualification records. Window: the agreed baseline period, then each pilot week.
• Share of CRM records complete and deduplicated. Meaning: proportion of CRM records with all required fields filled and no unresolved duplicates. Source: CRM record audit. Window: measured at the start of the baseline period and at each pilot review.
• Qualified-lead rate. Meaning: proportion of all leads received that meet the agreed qualification criteria. Source: intake list and qualification records. Window: the agreed baseline period, then each pilot week.
• Discovery-call booking rate. Meaning: proportion of qualified leads that result in a booked call. Source: booking records and the CRM. Window: the agreed baseline period, then each pilot week.

A buyer reading this can follow the logic end to end and spot holes in it — that testability is the point. If any step above does not fit your business, that is exactly what the AI Opportunity Discovery Call is for.

Synthetic data only. No real customer data is used in this example.

Case 5 — Operations: internal requests, approvals, and reporting

At stake: Approvals that wait on one inbox, and reports assembled by copying between systems, are decisions made late and on stale figures.

Example business: a growing company where internal requests, approvals, and weekly reports move by email and spreadsheets.

Result to prove in a pilot: approvals that no longer wait on one inbox, and reports assembled from connected systems instead of copied by hand. That result is defined by the measurements below, against your current baseline — it is not a promised improvement.

What it costs today

Requests get lost in inboxes, approvals wait on one person, and weekly reporting takes hours of copying data between systems.

Design

1. Internal requests are submitted through one form. 2. Requests are routed to the right approver based on type and value, with reminders for overdue items. 3. A draft summary and a draft weekly report are assembled from the connected systems. 4. A named manager reviews and approves requests and the report. 5. Approved items are actioned and logged, with an audit trail of who approved what and when.

Systems to connect

Internal request form, email, task tracker, spreadsheets or reporting tool, document storage.

Human review points

Approval thresholds are set by the business; no spend or commitment is approved by the workflow alone; report figures are checked by a named reviewer before distribution.

Risk this design prevents: a report distributed with figures nobody checked.

What the pilot measures

Each measure states its meaning, its source, and its window — and deliberately states no value, because no value exists yet. The window for every measure is the agreed baseline period, then each pilot week.

• Request-to-approval time. Meaning: time from a request's submission to its approval. Source: request form timestamps and the approval log.
• Share of requests with a named approver and a logged outcome. Meaning: proportion of requests that have both an approver and a recorded outcome. Source: request and approval logs.
• Overdue request count. Meaning: number of requests past their agreed response time and still unapproved. Source: request log.
• Reporting time per cycle. Meaning: hours spent assembling one weekly report, from data collection to distribution. Source: time records for the reporting cycle.
• Error rate in distributed reports. Meaning: proportion of distributed reports that later require a correction. Source: corrections log.

If this resembles your bottleneck, mention 'operations approvals and reporting' on the call — we will start from your current workflow, your systems, and the baseline you would measure against.

Synthetic data only. No real customer data is used in this example.