Twelve workflows written out end to end: the scenario, how it typically runs today, and how it runs once it is built properly. Labelled honestly, because we would rather show our reasoning than borrow someone else's logo.
Illustrative composites, drawn from how these workflows actually run in each industry. Not named client engagements.
When we have client engagements we are permitted to name, they will appear here as named case studies and be clearly distinguished from these examples.
Legal work is document heavy, deadline driven and confidentiality bound. The constraint is rarely legal skill. It is that intake, status updates and document collection all land on people who are already billing.
A personal injury enquiry arrives through the website form at 9pm on a Saturday. Typically: An auto acknowledgement promises someone will be in touch during business hours. By Monday the client has retained the firm that called back. Built properly: The system qualifies the matter against the firm's intake criteria, asks the incident date, treatment status and insurer, requests the police report and medical records, books a consultation in the available slot, sends the engagement letter for signature, and opens the matter in Clio. A paralegal reviews and approves everything on Monday morning, before anything is final.
An associate has to draft a response to a motion, and knows the firm has argued something close to it before, but not where or when. Typically: Twenty minutes searching the document system by filename, a message to the partner who might remember, and a first draft written from scratch because the prior work never surfaced. Built properly: Searches templates, memos and prior work product in plain language, returns the three closest prior matters with the specific passages cited and the authoring attorney named, and produces a first pass draft that quotes only from those documents. Permission aware, so the associate sees only matters they are entitled to see. Every assertion links back to the document it came from, so the partner reviewing it can check the source in one click.
Retail support is dominated by three questions: where is my order, will it fit, and can I send it back. Answer the second one properly and the third one shrinks.
A shopper asks whether the running shoes will fit if they normally wear a 9.5, and where their previous order has got to. Typically: Please check the size chart on the product page, and track your order using the link in your confirmation email. Built properly: Checks the catalog and the accumulated fit feedback for that model, which runs narrow, and recommends a half size up. Pulls the previous order from Shopify: shipped, arriving Thursday via ShipStation. Logs the recurring fit complaint against the product for the owner dashboard, and queues a Klaviyo review request for the delivered order.
A customer opens a return request for a jacket. Reason given: too small. Typically: A return label is issued automatically. The item comes back, gets inspected and restocked, the refund goes out, and the sale is gone along with roughly fourteen dollars of handling. Built properly: Reads the reason code before issuing anything. Since the reason is fit rather than fault, it checks live inventory for the next size up in the same colour, offers a direct exchange with the replacement shipped first, and only falls back to a refund if the size is unavailable or the customer declines. The fit reason is written back against the product so the size guidance updates for the next shopper.
Support, activation and churn are the same problem viewed at different moments. The signals are already in your helpdesk, product analytics and billing system. They are just not connected.
A trial account opens a ticket saying they cannot connect their billing integration. The trial ends in two days. Typically: Thanks for reaching out, here is our help doc on integrations. The trial expires, no one follows up, and the account is recorded as a non converter. Built properly: Reads the Stripe and Mixpanel state, finds the integration failed on a permissions scope and that the account has never reached activation. Answers with the exact fix from the docs, summarises the ticket into HubSpot, flags the account as churn risk with the reason attached, and creates a task for the CSM to reach out before the trial expires.
A healthy two year account fails its renewal charge. The card on file expired last week. Nobody has noticed. Typically: Three automated dunning emails go to the billing address, which belongs to someone who left the company. The subscription cancels on schedule and the account is counted as churn. Built properly: Recognises this as involuntary churn rather than a decision to leave. Checks product analytics, sees usage is steady and the account is healthy, then routes around the dead billing address: notifies the active admin in the product itself, sends a single card update link, and alerts the account owner in Slack with the usage context attached. If the card is not updated before the retry window closes, it holds the account rather than cancelling, and escalates to a human.
Clinicians did not train for data entry, and the documentation load is now the single largest predictor of burnout. The work is real, it is required, and almost none of it needs a clinical licence to complete.
A specialist orders an MRI. The payer requires documented conservative treatment before it will authorise the scan. Typically: A staff member searches the chart for prior physical therapy notes, imaging and medication history, copies them into the payer portal, waits on hold to clarify a field, and submits. If it is denied for insufficient documentation the cycle repeats. Total elapsed time is measured in days and the patient waits through all of it. Built properly: The system reads the payer's specific criteria for that procedure and plan, retrieves the conservative treatment history, the relevant imaging and the clinical rationale from the record, and assembles a complete packet with each element linked to its source note. The ordering clinician reviews and approves. If a required element genuinely does not exist in the record, it says so up front rather than submitting an incomplete packet and waiting for a denial.
A patient cancels a Thursday afternoon appointment at 4pm on Wednesday, and there is a six week waiting list. Typically: The slot stays empty. Working the waiting list means calling people in order until someone answers and can rearrange their day at short notice, and the front desk is checking in patients until closing. Built properly: The system identifies which waiting list patients match that slot on clinical need, appointment type and travel distance, offers it to them in priority order by their preferred channel, and confirms the first acceptance. It updates the practice management system, cancels the outstanding reminders for the original booking and notifies the clinician of the change. Anything clinically ambiguous goes to a human rather than being decided automatically.
You cannot loosen the controls and you should not want to. What you can do is stop spending most of your compliance capacity on alerts that were never going to be anything, and stop losing good customers to an onboarding flow that treats them like suspects.
A business customer uploads incorporation documents at 11pm. One document is a scan with the registration number cut off at the page edge. Typically: The application queues. Two days later a reviewer opens it, spots the problem, and sends a templated email asking for the document again. The applicant, who has by now started an application elsewhere, does not respond. The case is closed as abandoned and counted as a fraud control working. Built properly: Extraction runs while the applicant is still in the flow. The system detects the truncated field, shows them exactly which corner is missing on their own upload, and accepts a corrected image immediately. The remaining checks run in parallel, the registry lookup confirms the entity, and the case reaches a reviewer complete rather than incomplete. Anything genuinely ambiguous, including anything that touches a sanctions or PEP match, goes to a human untouched.
A transaction monitoring rule fires on a customer whose incoming payment pattern changed this month. Typically: An analyst opens the alert, pulls twelve months of history from one system, the KYC file from another and the prior alert history from a third, reads it all, writes a narrative, and closes it as a false positive. Forty minutes for a case that was never going to be anything, repeated across a queue where nine in ten end the same way. Built properly: The system assembles the evidence pack before the analyst opens it: the history, the KYC file, prior alerts on the same customer, and the specific pattern change that triggered the rule, with a drafted narrative citing each source. The analyst reads, checks and decides. The decision, the evidence and the reasoning are recorded together. Nothing is auto closed, because in this sector the value is in making the analyst faster rather than in removing them.
When everything moves as planned, nobody needs to be involved. The entire operational cost of a freight business sits in the shipments that do not, and in the phone calls asking about them.
A container discharges on a Friday. Free time is five days. The customs entry has not been filed because a commercial invoice value does not match the packing list. Typically: Nobody notices until the broker chases on Wednesday. By the time the discrepancy is traced, corrected and refiled, free time has expired and demurrage is accruing daily on a container nobody can move. Built properly: The mismatch is caught at document ingestion, before discharge, because the invoice and packing list were cross checked the moment both arrived. The coordinator gets one notification naming the two documents, the specific field, both values, and the deadline that is at risk with the daily cost attached. The correction is requested from the shipper the same day, and the entry is filed inside free time.
A customer emails on Tuesday morning asking where three shipments are, two of which have conflicting carrier milestones. Typically: A coordinator opens the TMS, checks each shipment, opens two carrier portals to reconcile the conflicting events, and writes a reply. Twenty minutes, repeated across a queue, by the person who should be solving the exception from the previous scenario. Built properly: The system answers from the live feed and the TMS, gives the current position and revised ETA for each shipment, and where carriers disagree it says so explicitly rather than picking one, flagging that shipment for a coordinator to confirm. The routine two resolve immediately. The genuinely uncertain one reaches a human with the conflict already laid out.
Two businesses share one industry. Brokerage loses deals in the first five minutes after an enquiry. Property management loses margin in a maintenance queue nobody can staff. Both are response time problems, and both are fixable.
A portal enquiry on a three bedroom listing arrives at 8:40pm on a Sunday while the agent is at a family dinner. Typically: An automated portal acknowledgement goes out. The agent sees it Monday at 9:30 and calls at 11 between viewings. The buyer has already spoken to two other agents and booked a viewing with one of them. Built properly: A reply goes out inside a minute in the buyer's channel, confirms the property is available, asks the qualifying questions the agent would ask about timeline, financing and whether they have a property to sell, offers the three viewing slots that are genuinely free in the agent's calendar, and books one. By Monday morning the agent has a confirmed viewing with a qualified buyer and a written summary, rather than a name and a phone number.
A tenant messages at 11pm that water is coming through the kitchen ceiling. Typically: The out of hours line takes a message. It is triaged in the morning by whoever opens the inbox, without the property history to hand, and booked as a routine plumbing visit. By the time anyone attends, the damage has spread into the flat below and the job is an insurance claim. Built properly: The system classifies it against your escalation criteria as an active leak affecting another unit, which is an emergency, and pages the on call contractor immediately rather than queuing it. It pulls the property record, notes the flat below and the last plumbing job at that address, sends the tenant the immediate steps and a confirmed attendance window, and opens the job in the management system with the history attached. Routine requests that arrive the same night are triaged and scheduled without waking anyone.
Each industry page carries the researched pain points, the cited figures and the step by step breakdown of every workflow above.
Thirty minutes on the work your team is actually doing. We will tell you which parts are worth automating and which are not.