What AI is good at in business operations

Most of what a business writes, sorts and reads, a model can now draft, sort or read too. Two things make that statement useful rather than a slogan. The first is that the list of tasks keeps changing as models change, but the two properties a good task has do not change, so the properties are worth more than the list. The second is that none of it saves any time until someone decides how the output gets checked, because a model’s wrong answers look exactly like its right ones.

The list

Drafts of anything written. Emails, briefs, product descriptions, proposals, internal documentation, rewrites. Anywhere the value is getting from a blank page to something worth editing.

Turning one format into another. Long into short, casual into formal, bullet points into paragraphs. English into Hindi, a table into prose, Python into JavaScript. The information stays; the form changes.

Pulling facts out of messy text. Invoice numbers from a stack of PDFs. The recurring complaints in a year of support tickets. The action items in a meeting transcript. A model reads fast and does not get bored. This is the same pattern-matching as everything else here, pointed at a pile of documents.

Sorting and routing. Is this ticket about billing or the product? Is this email urgent? A model can sort thousands of pieces of free text without the hand-written rules such systems used to need. Where the data is already tidy fields with years of history, a classical scoring model is usually cheaper and faster; the language model is for the text nobody tidied.

Generating options. Give it a half-formed thought and get 10 developed versions back. Give it 3 product names and get 30 more in the same style.

Summarising. A meeting transcript down to the decisions. A 50-page report down to one page. Months of customer feedback down to the recurring themes.

Code. Code is text, and the model has seen a great deal of it. It makes anyone who writes code faster, and the measured picture is messier than the marketing: teams ship more, what ships breaks more, and reviewing it all becomes the new bottleneck.

Talking a problem through. “Walk me through this.” “What am I not asking?” “What is the counter-argument?” A model is a usable thinking partner for thinking that improves by being said out loud.

Reading documents, images and recordings. A scanned invoice, a photo of a damaged delivery, a chart inside a PDF, a recorded call. The model reads them and answers in text, which for business work is far more dependable than generating images. Handwriting and bad photocopies are where its reading is weakest, so that is where checking matters most.

Reading very long material in one pass. Current models hold roughly a couple of thousand pages at once, so “read these 400 pages of contracts and list every clause about penalties” is an ordinary request. Quality drops before the advertised limit, which is why the context window is worth understanding before a task depends on it.

The two properties

Every task on that list shares two properties, and together they are the test for any task that is not on it.

The output can be checked quickly. A person reads the draft and judges it. The extracted table is held against the documents, the summary against the transcript. Checking is fast when the right answer already sits somewhere the checker can reach.

Being approximately right is useful. A draft that is 80% there is a good start. A summary that catches 9 themes out of 10 saves real time. The model does not need to be perfect. It needs to save more time than the checking costs.

Put numbers on both and they become one sum: the gain is the time the task took, minus the time the model takes, minus the time the checking takes. When checking the output takes as long as doing the task, the gain is zero no matter how good the output looks.

The checking cannot be casual, because a model’s wrong answer is not sloppier, shorter or less confident than its right answer. It looks the same. So the check has to be part of the task’s design, and the strongest design move is to make the model show its working: ask for the source line next to every extracted figure, and checking stops being “re-read everything” and becomes “read one table”.

Example

Let’s say 40 supplier invoices arrive each week, and someone types the supplier, invoice number, date and total from each into a spreadsheet. Call it 90 minutes. A model is asked to do the same, with two extra instructions: beside every total, quote the line of text it came from, and flag anything unreadable instead of guessing. The table comes back in 2 minutes. The check is 10 minutes of reading down 2 columns, does each total match its quoted line, plus opening the 5 invoices that are scans, where reading is least reliable. On one scan, the quoted line beside the total reads “Credit note issued: 18,400”, which is not how an invoice states a total: the model took the wrong figure, and the quoted line is what exposes it. 90 minutes of typing has become 12 minutes of reading, and the one bad row was caught.

The same sum explains when the answer changes. If that invoice table fed a payment system directly, a wrong row would be money out of the door, and ten minutes of reading would no longer be enough checking. How much checking a task deserves depends on what a wrong answer costs once it is acted on.

When a task fails one of the two properties, there are two moves before giving up on it. Give the model the source material, so its answer arrives with something to check it against. Or hand the part it is bad at to software that calculates rather than predicts. When neither works, when the output cannot be checked, or 80% right is worth nothing, the task is a bad fit, and the next chapter is about exactly those. Testing AI before trusting it is how a team answers both properties on its own work before anything depends on the answer.

What it looks like in place

Two more ways the same produce-then-check shape shows up.

Example

Let’s say support tickets arrive faster than anyone can sort them. The model reads each ticket as it arrives and adds a one-line summary and a suggested category, marking the ones it could not place. A person reads the marked ones and a sample of the rest. Nobody stopped reading tickets; the sorting is what went away.

Example

Let’s say a proposal usually takes a day to write. The model drafts it in minutes from past proposals and the notes from the call. The person then spends most of an hour fixing it, because the pricing paragraph is wrong in a way that reads perfectly well. A day becomes an hour, and the job changes from writing to editing.

In both, the model produces, a person checks, and the checking was designed in from the start. Which tasks in a particular operation deserve this treatment is its own question, and where AI fits takes it up from the operation’s side.

The list at the top will look different in a year. The two properties will not, and they answer for tasks the list never mentions.