Section 1
The use cases that pay back fastest
Classification is the workhorse. Route this ticket to the right team. Mark this lead in scope or out. Tag this transaction. It is cheap, measurable against a labelled sample, and it removes a decision people make hundreds of times a week without enjoying any of them. Extraction is next. Invoice totals, contract dates, delivery addresses in an email, specifications in a request for quote. Anywhere a person retypes information from one system into another, extraction is the intervention, and [AI-Powered Document Processing for Startups](/blog/ai-powered-document-processing-for-startups) covers the mechanics. Search is the underrated one. Semantic search retrieves by meaning rather than exact words, so an agent asking about a customer charged twice finds the article titled duplicate billing. For a startup with scattered internal knowledge, this often beats any generative feature.
Section 2
Sometimes a rule is the better answer
A model is not automatically the right tool. If the text you are processing has consistent structure, a rule will be faster, cheaper, fully predictable, and debuggable by anyone on the team. Invoice numbers in a fixed format, dates in a known layout, a form with defined fields: use pattern matching. Keep models for genuine variation, where the same idea arrives in fifty phrasings. The strongest architecture is usually both. Rules handle the predictable majority deterministically, a model handles the rest, and anything neither resolves goes to a person. Teams that skip the rules layer pay per token for work a regular expression did perfectly in 2004.
Section 3
You need an evaluation set before you need a model
The question that stalls most projects is how do we know it is working. The answer has to exist before deployment, not after. Build an evaluation set: two hundred real examples with correct answers assigned by a human. It takes a day. It then serves as your permanent test bench. Every prompt change, model upgrade, and vendor swap runs against it, and you see the effect in numbers rather than in impressions. Without it you are flying by anecdote, and language systems fail in exactly the way anecdote cannot catch: fine on the cases you check, systematically wrong on a category you never sampled. Startups that skip this step discover the gap through a customer.
Section 4
Sequencing it inside a startup that has no spare people
Pick the task with high volume, low complexity, and a cheap mistake. Ticket routing, not contract review. Run it in suggestion mode first. The system proposes, a person accepts or corrects, and every correction becomes evaluation data. You get the accuracy measurement and the productivity gain at once, without any exposure. Move to automatic only where agreement has been consistently high, and keep the rest in suggestion mode indefinitely. Partial automation is not a failure state. For most startups it is the end state, and it is far more robust than an all-or-nothing switch that gets turned off after the first bad week. Build sequencing generally is covered in [AI Automation in Product Development: From Idea to Launch](/blog/ai-automation-in-product-development-from-idea-to-launch).
Section 5
The risks that come with text
Text carries personal data by default. Support conversations, sales emails, and application forms contain names, addresses, financial details, and occasionally information a person did not intend to share. Anything sent to an external model is a data transfer, and it needs to be described in your privacy notice in terms a customer would recognise. There is a second risk specific to language systems: text you did not write can contain instructions. A document or an email processed by a model may include content designed to change its behaviour. Treat all incoming text as data to be analysed rather than instructions to be followed, and never let a system with an email inbox also hold the ability to send money. A third risk is quieter. Models perform unevenly across dialects and languages, so a classifier tuned on your largest market can quietly under-serve another. Test by segment, not just overall.
Section 6
Metrics, and knowing when text is the wrong tool
Measure accuracy against the evaluation set, broken out by category rather than averaged, since the average hides the class where it fails. Watch the correction rate in suggestion mode fall over time. Then measure the operational number that justified the project: handling time, time to first response, hours of retyping removed. One thing worth stating plainly. If your text volume is small, a person reading everything is a legitimate answer, often a better one, because they notice things no classifier is looking for. Automation earns its cost at volume, and knowing when a technique does not apply is a discipline in itself, which is the case [When Not to Use Storytelling in Business](/blog/when-not-to-use-storytelling-in-business) makes in a different domain.