Using OpenAI in a business automation: the jobs it is good at, and the ones it is not

Almost every automation conversation now arrives with "and can we put AI in it." Usually the answer is yes, and usually the useful version is much narrower and less exciting than what people picture. A language model is not an automation engine. It is one step inside an automation — a very good step for a specific family of problems, and a genuinely dangerous one for a different family. Knowing which is which is most of the skill.

The dividing line: judgement versus arithmetic

Here is the heuristic that has held up across every build we have done. A language model is the right tool when the task requires understanding unstructured human language and would otherwise require a person to read something and decide. It is the wrong tool when the task has a correct answer that can be computed.

Read an email and decide whether it is a booking request, a complaint or a supplier invoice: excellent fit. Add up the line items on that invoice: terrible fit — use arithmetic, in code, where it is right every time.

The failure mode people underestimate is that a language model asked to do arithmetic will not refuse. It will produce a confident, plausible, wrong number, formatted exactly like a right one. There is no error state to catch. This is why the boundary matters more than the prompt.

Five jobs LLMs do reliably in small business workflows

1. Classification and routing

Sorting inbound messages into categories so the rest of the workflow knows where to send them. Give the model a fixed list of categories and require it to pick one. This is the single highest-value LLM step in most small business automations, because it unlocks everything downstream.

2. Structured extraction

Pulling named fields out of messy text — customer name, address, job type, requested date — from an email a human typed in no particular format. Ask for JSON with a fixed schema and validate the result before you use it.

3. Drafting, for a human to approve

Quote follow-ups, review responses, appointment confirmations. The model produces the draft; a person presses send. This is the highest-value use of an LLM in a small business and also the one people skip, because sending automatically feels more impressive. It is not worth it.

4. Summarising

Turning a long thread, call transcript or day's worth of enquiries into something a busy owner reads in thirty seconds. Low risk, because a slightly imperfect summary of something you can still open is not harmful.

5. Normalising messy input

"Tues arvo", "next Tuesday PM" and "Tuesday afternoon" all becoming the same structured value. Traditional parsers are brittle here and language models are unusually good at it.

How OpenAI billing works

OpenAI’s pricing pages block automated fetching, so we will not reproduce per-token figures we could not read directly — they also change often enough that a hardcoded number is a liability. The structure is what you budget against: you pay per token, input is cheaper than output, and both caching and batching cut the rate. Source: the vendor’s own pricing page, read August 5, 2026. Prices change — verify before you commit.

The four failure modes to design around

• Confident fabrication. Asked something it does not know, a model will often produce a fluent, specific, invented answer. Never let raw model output reach a customer as fact — about your prices, your availability, your policies, or anything else.
• Non-determinism. The same input can produce different output on different runs. If a downstream step expects an exact string, validate and constrain rather than assuming stability.
• Silent drift. Model versions change. A prompt tuned six months ago can behave differently today. Anything running unattended needs periodic spot-checking against known inputs.
• Prompt injection. If your workflow feeds customer-written text into a model, a customer can write instructions in that text. Treat everything that arrives from outside as untrusted data, never as instructions, and never give the model the ability to take a consequential action on its own.

A pattern that works

The architecture we keep returning to is deliberately boring, and it is boring because it is safe.

1. A deterministic trigger fires — an email arrives, a form is submitted.
2. Code does the mechanical parts: fetch the record, check the database, calculate anything numeric.
3. The model does exactly one job: classify, extract, or draft. It receives only what it needs.
4. Its output is validated against a schema. Anything malformed, out of range, or low-confidence is routed to a human rather than guessed at.
5. Code performs the action. The model never writes to a system of record directly and never sends anything to a customer unreviewed.

Structured this way, the worst case when the model gets something wrong is that a person has to look at it — which is exactly what was happening before you automated anything. That is the property you are protecting.

This step slots into whichever engine you have chosen: Zapier, Make and n8n all have native OpenAI actions. And it pairs naturally with Slack as the place drafts go for human approval before anything is sent.

What this costs to run

For classification and extraction on small business volumes, LLM costs are usually not the expensive part of an automation — the build and maintenance are. A classification step handling a few hundred messages a month sends very few tokens, because the input is one email and the output is one word.

Costs escalate in three predictable ways: stuffing large documents into every request, generating long output, and running the model on high-frequency events rather than at a decision point. If a bill surprises you, it is almost always one of those three. Trimming the input and caching repeated prompt prefixes are the first two things to try.

For a wider view of what automation investment looks like overall, see our breakdown of what AI automation actually costs.