Intelligent Automation Use Cases: A Worked Example

Plain automation follows a fixed rule: if the field matches this pattern, do that. Intelligent automation adds a layer that can read something unstructured first — a scanned invoice, a customer email, a paragraph of notes — and turn it into the structured fields the rule-based part then acts on. That reading step is the actual value and the actual risk, because it is the part that can be confidently wrong.

Most lists of "intelligent automation use cases" stay abstract: a bullet point per industry, no example anyone could actually run. This one works through a single task from real-looking input to real output, names exactly where it breaks, and sets out the checks worth running before it touches anything live — the same shape find the repetitive part uses to decide whether a task is worth automating at all.

What makes automation "intelligent" rather than just automation

The Stanford AI Index tracks a widening gap between how fast these tools get adopted and how much productivity actually shows up in the numbers afterward — a gap that mostly traces back to the reading step. Wiring a spreadsheet row to a notification is a solved problem, covered in no-code automation. What is new is the step before that: pulling the vendor name and the amount out of a document that was never in a fixed format to begin with, well enough that the fixed-format rule after it has something reliable to work with.

Four use cases worth automating

• —Invoice and receipt capture — pulling vendor, amount, date and line items out of a PDF or a photo, so the figures land in a ledger without being retyped.
• —Support ticket triage — reading an incoming message and routing it to the right queue with the right priority, instead of a person sorting every ticket by hand.
• —Contract clause flagging — scanning a document for a specific kind of clause, an auto-renewal date or a liability cap, and surfacing it for a person to actually read.
• —Expense categorisation — turning a scanned receipt into the right expense category and cost centre, the IT-heavy version of the same reading-then-routing pattern.

All four share the same shape: an unstructured input, a model that reads it into structured fields, and a rule-based step after that acts on the fields. Data automation tools covers the equivalent pattern for cleaning up a dataset rather than a document. The rest of this post works through the first one end to end.

A worked example: invoice capture

Example input — the kind of text a PDF-to-text step actually produces, not a clean form:

INVOICE Bright Path Office Supplies Inv# BP-20940 Date: 09/12/2026 Bill to: Coursium Ltd Item: Printer toner x4 ......... 148.00 Item: A4 paper, 5 reams ....... 22.50 Subtotal 170.50 Tax 8.5% 14.49 TOTAL DUE: 184.99 Due 30 days from invoice date

The prompt worth writing is specific about the fields and the format, not "extract the details": "Read this invoice text and return exactly five fields — vendor, invoice number, invoice date, total due, and due date — as a single line of comma-separated values in that order. If any field is not present in the text, write MISSING instead of guessing."

A usable result from that prompt: `Bright Path Office Supplies, BP-20940, 2026-12-09, 184.99, 2027-01-11`. Notice the date is ambiguous in the source — "09/12/2026" could be 9 December or 12 September depending on which country wrote the invoice — and a model asked to just "extract the date" will silently pick one format and move on. The version above only works because the prompt forces a stated year-month-day output, which makes a wrong guess visible the moment someone checks it against the original line.

Where this actually breaks

• —Date format ambiguity, as above — the model resolves it silently unless the prompt forces an unambiguous output format.
• —A handwritten total, or a total that does not match the sum of the line items — the model will usually report whichever number it read most confidently, not flag the mismatch, unless explicitly told to check the arithmetic.
• —Multi-currency invoices, where a symbol or a code gets dropped and a number reads as correct in the wrong currency.
• —A second page the extraction step never saw, silently missing a line item with no indication anything is missing.

What AI is actually bad at covers the underlying reason: a model produces its most fluent-sounding answer, not necessarily its most checked one, and fluent, confident output is not the same claim as correct output — the two are indistinguishable from the outside until someone checks the source document.

The checks to run before it touches anything real

1. 01Run it against ten invoices you have already entered by hand, and compare every field, not just the total — a wrong invoice number is as costly as a wrong amount once it is in the ledger.
2. 02Deliberately include one invoice with a missing field and one with an ambiguous date in that test batch, and confirm the output flags them rather than guessing.
3. 03Add an explicit arithmetic check as a second step: does the subtotal plus tax equal the stated total? A mismatch is the single highest-value flag this kind of automation can raise.
4. 04Set a spot-check rate once it is live — a fixed percentage of extracted invoices a person actually opens and compares against the source, on a schedule, not only when a number looks wrong.

Checking an AI answer when you are not the expert sets out the general version of that spot-check habit, and it applies as much to a five-field extraction as to a paragraph of prose. The NIST AI Risk Management Framework frames this the same way: monitoring an automated system is ongoing, not a one-time check performed before launch and then forgotten.

The pattern behind all four use cases

Task-level research using real usage data keeps finding the same shape across knowledge work broadly: these tools are strongest at creating, processing and communicating information, and weakest at anything that needs judgement about a specific, high-stakes fact. Invoice capture sits mostly in the first category — reading and structuring — right up until the moment a total does not reconcile, which is exactly the moment it needs a person. Microsoft’s own research on the same question makes the same distinction: a tool being able to assist with a task is a different claim from a tool being able to own it end to end, and the gap between those two claims is exactly where the checks above earn their keep.

That shift shows up in the labour data too. Challenger, Gray & Christmas tracked 54,836 US job cuts attributed to AI in 2025 alone, concentrated in exactly this kind of document-processing work, while separately PwC has measured a growing wage premium for workers who use these tools well — 62%, up from 57% the year before. Building the automation and knowing how to check it are the skill that premium is actually paying for, a pattern Indeed’s Hiring Lab finds holding across job postings more broadly.

What to do Monday

Pick one document type you currently retype by hand at least weekly, and write the specific-fields, MISSING-not-guessed prompt shown above for it — writing a prompt that works on the first try covers the same discipline for any task, not only this one. Test it against ten real examples before it touches a live ledger, and decide the spot-check rate you will run once it is switched on. Workflow AI covers the wider design question of stitching several of these reading-and-routing steps together once the first one is solid.

Coursium teaches this practical layer directly — describing a task precisely enough that a tool’s draft is actually usable, and knowing exactly what to check before trusting its output. Stay ahead of AI by learning the tools on your phone.