ProTech Innovations Book a call

Illustrative case library

Illustrative Cases, by Industry

Six workflows, each framed by the result it is built to prove — measured against your baseline in a pilot, never promised in advance. Read the result first, then the design, then exactly what a pilot would measure.

Book an AI Opportunity Discovery Call See the interactive demos

Read this first: every case below is an invented example with synthetic data — not work done for a client, and not a result you are promised.

Jump to an illustrative case: Professional services · E-commerce · Sales-driven business · Customer support team · Operations · Document-heavy back office

Illustrative demonstration — not a client case study.

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.

Discuss a similar workflow →

Illustrative demonstration — not a client case study.

Case 2 — E-commerce: pre-purchase questions and order updates

At stake: A shopper waiting on a delivery or returns answer is a sale that can still be lost — and every repeatable question answered by a person is capacity not spent on a complex case.

Example business: an online retailer whose support team answers the same delivery, returns, and stock questions every day.

Result to prove in a pilot: routine questions answered from approved knowledge without a wait, while refunds, address changes, and disputed orders always reach a person. That result is defined by the measurements below, against your current baseline — it is not a promised improvement.

What it costs today

Shoppers wait for answers to routine questions, support staff repeat the same replies, and order-status questions interrupt work on more complex cases.

Design

1. A shopper asks a question in chat or email. 2. The assistant retrieves an answer only from approved help articles and the order system. 3. A draft answer is prepared, with order status where relevant. 4. A confidence and sensitivity check runs; refunds, address changes, and disputed orders are flagged. 5. Routine answers go out after review rules are met; flagged cases go to a support agent with the draft attached.

Systems to connect

Online store, order management, help centre, support ticketing, email and chat.

Human review points

Approved knowledge only; sensitive requests escalate to a person; agents review flagged drafts and can correct the approved knowledge base.

Risk this design prevents: a refund or address change handled without a person.

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 a shopper's question to the first approved answer. Source: chat and email timestamps and the sent-answer record.
  • Resolution time. Meaning: time from a question's arrival to the case being resolved. Source: support ticket records.
  • Share of cases resolved without escalation. Meaning: proportion of cases closed without being passed to an agent. Source: support ticket records.
  • Answer consistency against approved articles. Meaning: proportion of answers that match the approved knowledge base. Source: quality review of handled cases.
  • Customer satisfaction for handled cases. Meaning: satisfaction scores given by customers whose cases were handled. Source: post-case surveys.

If this resembles your bottleneck, mention 'e-commerce pre-purchase questions' 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.

Discuss a similar workflow →

Illustrative demonstration — not a client case study.

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.

Discuss a similar workflow →

Illustrative demonstration — not a client case study.

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.

Discuss a similar workflow →

Illustrative demonstration — not a client case study.

Case 4 — Customer support team: ticket triage and consistent answers

At stake: Two customers with the same issue receiving different answers is a consistency problem that becomes a reputation problem.

Example business: a support team handling tickets across email and chat, with uneven response times and answers that vary by agent.

Result to prove in a pilot: urgent tickets answered first, and the same issue answered the same way every time. That result is defined by the measurements below, against your current baseline — it is not a promised improvement.

What it costs today

Urgent tickets wait behind routine ones, agents search for the same answers repeatedly, and customers receive different guidance for the same issue.

Design

1. Tickets are captured from email and chat into one queue. 2. Each ticket is classified by topic, urgency, and sentiment using agreed rules. 3. Urgent tickets are routed first; routine tickets receive a draft answer from approved knowledge. 4. A confidence check flags low-confidence or policy-sensitive drafts. 5. Agents approve, edit, or escalate drafts, and outcomes are recorded for quality review.

Systems to connect

Support ticketing, help centre, chat, email, internal knowledge base.

Human review points

Routing rules are reviewed regularly; sensitive and low-confidence cases escalate to a person; quality review samples approved answers and corrects the knowledge base.

Risk this design prevents: the same issue answered differently for two customers.

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 by urgency. Meaning: time from a ticket's arrival to the first approved response, reported separately for each urgency level. Source: ticket queue timestamps and the sent-response record.
  • Resolution time. Meaning: time from a ticket's arrival to the case being resolved. Source: ticket queue records.
  • Backlog age. Meaning: age of the oldest unresolved ticket, and count of tickets older than the agreed threshold. Source: ticket queue.
  • Share of tickets answered from approved knowledge. Meaning: proportion of answers drawn from the approved knowledge base rather than written from scratch. Source: ticket records and quality review.
  • Reopen rate. Meaning: proportion of resolved tickets that customers reopen. Source: ticket queue records.
  • Quality-review score. Meaning: score given to sampled approved answers against the agreed quality criteria. Source: quality review of sampled answers.

If this resembles your bottleneck, mention 'support ticket triage' 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.

Discuss a similar workflow →

Illustrative demonstration — not a client case study.

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.

Discuss a similar workflow →

Illustrative demonstration — not a client case study.

Case 6 — Document-heavy back office: invoices and onboarding documents

At stake: An invoice total or onboarding document caught late is rework at best — and a posting error at worst, because nothing should be posted before a person approves it.

Example business: a back-office team processing supplier invoices and client onboarding documents by hand.

Result to prove in a pilot: documents processed without re-typing, totals and missing documents caught before posting, and nothing posted without approval. That result is defined by the measurements below, against your current baseline — it is not a promised improvement.

What it costs today

Documents arrive by email, key fields are re-typed, totals and missing documents are caught late, and filing is inconsistent.

Design

1. Documents are received in a monitored inbox and filed by type. 2. Key fields are extracted as a proposal, not a posting. 3. Extracted values are validated against formats, totals, and known suppliers or clients. 4. A reviewer corrects flagged items, confirms missing documents, and approves. 5. Approved data is posted to the finance or onboarding system, filed with the original document, and linked in an audit trail.

Systems to connect

Email inbox, document storage, finance system, CRM or onboarding system.

Human review points

Nothing is posted before approval; mismatches and missing documents are flagged, not silently corrected; the original document is always retained alongside the correction.

Risk this design prevents: a wrong invoice total posted automatically.

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.

  • Processing time per document. Meaning: time from a document's arrival to its approved posting. Source: inbox timestamps and the posting log.
  • Error rate after approval. Meaning: proportion of posted documents later found to contain an error. Source: corrections log.
  • Share of documents posted without a correction. Meaning: proportion of documents posted with no reviewer correction to the extracted values. Source: posting log.
  • Time to complete an onboarding file. Meaning: elapsed time from the first document's arrival to the file being complete. Source: onboarding records.
  • Audit-trail completeness. Meaning: proportion of postings linked to the original document and the approval record. Source: audit trail.

If this resembles your bottleneck, mention 'back-office invoices and onboarding' 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.

Discuss a similar workflow →

How to use these cases

Pick the result closest to the one you need to prove, then discuss it on a call: what your current workflow is, which systems are involved, where a human must approve, and which baseline you would measure against. That discussion is the starting point for a pilot — not a promise of a result.

All examples on this page use synthetic, generic situations. No real client names, no measured results, and no testimonials appear here. Any KPI listed is a metric that could be measured against an agreed baseline before implementation — it is not a result achieved.

What a first pilot looks like

One workflow, one team, and the systems already in use. Human approval points are agreed in advance, a baseline is measured before anything is automated, and a go/no-go review comes before anything wider is proposed. Shape and sequence only — not a promise of an outcome, a timeline, or a price.

Book an AI Opportunity Discovery Call See the interactive demos Explore industries