What makes a good first applied AI project for a company to build?

A good first applied AI project has a single, well-defined input and output — a support ticket comes in, a category and priority go out — rather than an open-ended goal like "improve customer experience." It should be a task a human already does by hand often enough to give you a measurable baseline, and its failure mode should be cheap, such as someone re-tagging a mis-classified ticket, rather than reaching a customer directly with no review step. Ticket classification, first-pass response drafting, document summarization for internal review, and data extraction from structured forms all fit this pattern.

Why is a customer-facing chatbot usually the wrong first AI project?

A chatbot fails the criteria for a good first AI project on every count: its failure mode is public, since a wrong answer or a made-up policy happens in front of the customer in real time with no queue to catch it first. Its scope isn't bounded, because customers can ask about billing, products, complaints, or anything else the business has no policy for, so you can't test every input in advance the way you can with a fixed classification task. Its baseline is also unclear, since there's no single consistent comparison point — a human agent, a FAQ page, a phone line — so a chatbot belongs at the end of an AI roadmap, after lower-stakes, human-reviewed projects have built confidence, not at the start.

When starting an applied AI project, is the model or the data usually the bigger obstacle?

It's almost always the data, not the model — general-purpose models handle classification, drafting, and extraction well out of the box. The real blockers are things like inconsistently tagged history that leaves no clean label set to evaluate against, responses scattered across multiple systems with no single export, and free-text fields that mix several formats because an intake form changed over time. Before evaluating any model, pull a sample of 200-300 real examples of the task; if you can't easily assemble a clean, representative sample, fixing that data access and labeling problem is the actual project, not model selection.

Where to Start with Applied AI

The best first applied AI project is narrow, bounded, and measured against work a human already does — think classifying inbound support tickets or drafting first-pass replies for an agent to edit, not an open-ended "AI strategy" initiative. Pick a task with a clear before-and-after number, keep a person reviewing the output, and prove the return before you touch anything customer-facing. Everything else about model choice, tooling, and rollout follows from getting that first choice right.

Pick a task with a scorecard, not a vision statement

Teams that start with "we need an AI strategy" spend months in workshops and ship nothing. Teams that start with "we need to cut ticket triage time" ship something in weeks, because the task defines its own success criteria. A good first project has three properties:

A single, well-defined input and output. A support ticket comes in; a category and priority go out. An intake form comes in; a summary goes out. Not "improve customer experience."
A human doing the task today, by hand, often enough that you can measure it. If nobody currently does the task, you have no baseline and no way to know if the model helped.
A failure mode that's cheap. If the model mis-tags a ticket, someone re-tags it. If the model drafts a bad first-pass email, a human catches it before it sends. Compare that to a failure mode that reaches a customer directly.

Ticket classification, first-pass response drafting, document summarization for internal review, and data extraction from structured forms all fit this pattern. Each has an existing manual process to benchmark against, a bounded scope, and a low cost when the model gets something wrong.

The real blocker is usually your data, not the model

Most teams assume the hard part is picking the right model or the right framework. In practice, the model is rarely the bottleneck — general-purpose models handle classification, drafting, and extraction well out of the box. The actual blocker is almost always data quality and access:

Ticket history that's inconsistently tagged, so there's no clean label set to evaluate against.
Support responses scattered across three systems with no single export.
Free-text fields that mix five different formats because the intake form changed twice in two years.
No audit trail showing who approved what, which matters the moment you want to measure accuracy.

Before you evaluate a single model, pull a sample of 200-300 real examples of the task and look at them. If you can't easily assemble a clean, representative sample, that's the project — not model selection. Fixing data access and cleaning up labeling conventions is unglamorous work, but it's the work that actually determines whether the AI layer on top does anything useful. Skipping straight to model comparison on messy data just produces a demo that works on the ten examples you tested and falls apart on the next fifty.

Keep a human in the loop for version one

The first version of any applied AI project should have a person reviewing every output before it goes anywhere that matters. This isn't a permanent design decision — it's how you build the baseline you'll need to justify expanding scope. Concretely:

Route model output to a queue a human already checks, not directly into a downstream system. A drafted response goes to the agent's inbox for edit-and-send, not straight to the customer.
Log agreement and disagreement. Every time a human accepts, edits, or rejects the model's output, record it. That log is your accuracy number, and it's the only thing that tells you whether the project is working.
Run the manual process in parallel for a defined period — two to four weeks is usually enough for a task with daily volume. Compare time spent, error rate, and consistency against the AI-assisted version side by side.
Set the bar before you start, not after. Decide what "worth expanding" looks like — for example, the model's suggested category matches the human's final choice on 85% of tickets, or drafted responses need editing on fewer than half of cases — before you see the results, so you're not moving the goalposts to match whatever number you get.

Only after you've cleared that bar with a human checking every output does it make sense to talk about reducing review, automating routine cases, or expanding to a second task.

Why a chatbot is the wrong place to start

A customer-facing chatbot is the single most common first AI project companies pick, and it's usually the wrong choice. It looks appealing because it's visible and demo-friendly, but it fails the criteria above on every count:

The failure mode is public. A chatbot that gives a wrong answer, makes up a policy, or gets rude with a customer happens in front of the customer, in real time, with no review step. There's no queue to catch it first.
The scope isn't bounded. Customers ask anything — billing questions, product questions, complaints, requests the business has no policy for. You can't test for every input in advance the way you can with a fixed classification task.
The baseline is unclear. What's a chatbot being compared against — a human agent, a FAQ page, a phone line? Each has different cost and quality, which makes "did this help" hard to answer cleanly.

Put a chatbot at the end of the roadmap, after you've built confidence with lower-stakes, human-reviewed projects and have real data on where the model is reliable and where it isn't. Starting there instead of ending there is how a promising initiative turns into a headline about a company's bot promising a customer something it shouldn't have.

What comes after the first project

Once a bounded, human-reviewed project clears its baseline, expanding it is a much smaller decision than starting it was. You already have the data pipeline, the accuracy log, and a working definition of "good enough." From there, reducing the review burden on the highest-confidence cases, extending the same approach to an adjacent task, or increasing automation on the original one are incremental steps — not new bets. The first project's job isn't to prove AI works in the abstract. It's to give you a real number, on a real task, that tells you whether the second project is worth building.

Where to Start with Applied AI: A Practical First Project