AI integration in business: choose use-cases that pay off.

The use-case pitched in the meeting is the exciting one — the assistant, the copilot, the thing you show the board. It rarely pays first. The work that pays is dull: routing tickets, matching invoices, pulling fields off a form. It runs constantly, follows rules, and quietly costs you errors.

Boring is the advantage. A task with clear rules is easy to test, easy to trust, and easy to prove in a week. You learn whether AI helps before you bet a quarter on it. Save the ambitious idea for after you have banked a small, real win.

Volume and rules are not enough. Ask what a wrong answer costs, and whether you would notice. If a mistake is cheap and invisible, automating it saves little and risks trust. If it is expensive but catchable — a mismatched invoice, a misrouted ticket — that is the sweet spot. AI does the first pass; a person checks the flags.

This is also where you draw the data boundary. Name what the model is allowed to see, and what stays out, before anyone writes code. A use-case that only pays if you hand a vendor your entire customer database usually is not worth it.

Take invoice matching. Volume: a mid-size firm processes thousands a month — clears the first test easily. Rules: an invoice matches a purchase order on vendor, amount, and line items, and you can write those rules down — clears the second. Cost of error: a wrong match pays the wrong amount or the same bill twice, and it shows up on a reconciliation — expensive, but catchable. Clears the third.

So the model does the routine matches and flags the rest for a person. Now flip it: 'draft our quarterly board narrative.' High stakes, but it happens four times a year and there is no rule for a good story. Low volume, no clear right answer — it fails two tests. Interesting to demo, wrong to build first.

Most teams do not lack ideas — they have twenty and cannot choose. Score each on the same three axes and the list sorts itself. A task that is high-volume, rule-heavy, and error-prone rises to the top. One that is occasional and judgment-heavy sinks, however good the pitch.

Take the top one all the way to production before starting the second. A single shipped use-case that saves real hours buys more credibility than five half-built pilots. Momentum compounds; a graveyard of demos does not.

Before you build, measure the task by hand: how many times it runs, how long each pass takes, how often it goes wrong today. Those numbers are your baseline. After the build, the same three numbers tell you whether it paid — hours returned, errors caught, cost of the misses that slipped through.

If you cannot state the baseline, you cannot prove the win, and the project turns into a story instead of a result. Proof of the same discipline lives at /work — live products you can open and click, not a slide deck. Judge the craft in production before you commission anything.