The Glamour Projects Fail First
Every operations leader I talk to wants to start with something impressive. A predictive model that anticipates equipment failure three weeks out. A conversational agent that answers any question a field technician might ask. A system that reads a contract and flags every risk clause with legal precision. I understand the instinct. These are the projects that get budget approved and get someone promoted for vision.
They also fail at a rate that should embarrass the industry. Not because the technology cannot do those things eventually, but because you are asking a new system to handle ambiguity, edge cases, and high-stakes judgment before you have learned how the system actually behaves in your environment. You find out it hallucinates a maintenance schedule. You find out the contract agent misses a jurisdiction-specific clause that a junior lawyer would catch. You find out the field technician does not trust it and stops using it after week two.
The project that survives and compounds is the one nobody wanted to pitch. It is the one that processes the same document in the same format with the same fields extracted, a thousand times a day, with a human checking a sample. Boring. Repetitive. Exactly right.
Why Volume and Repetition Are the Real Signals
When I am scoping a first deployment with a new client, I am not looking for complexity. I am looking for three things together: high volume, low variance, and a measurable outcome that already exists.
High volume means the compounding effect of even modest accuracy improvements is enormous. In a distribution operation I worked with, the team was manually keying line items from supplier invoices into their ERP. Roughly 2,400 invoices a week, each with between 8 and 40 line items. No single invoice was hard. The task was just relentless. An agent handling that extraction does not need to be clever. It needs to be consistent and auditable. The manual work removed per week was measured in hundreds of hours, not a rounding error.
Low variance is what makes a first deployment survivable. If 95 percent of your inputs look essentially the same, you can build a tight evaluation set, you can define what good looks like, and you can catch model drift before it causes a real problem. The moment you introduce high variance, you are in the business of handling exceptions, and exceptions require judgment, and judgment requires a level of trust you have not yet earned with your stakeholders.
A measurable outcome that already exists means you do not have to invent your success metric. If a human was doing the task, you know the throughput, the error rate, and the time cost. You have a baseline. That baseline is what lets you prove value in week four instead of month fourteen.
What This Looks Like Across Sectors
In financial services, the dull high-volume win is almost always document processing. Trade confirmations, loan application packets, compliance checklists, remittance advice. One team I worked with had analysts spending a meaningful portion of their week pulling data from PDF statements to populate a monitoring spreadsheet. The statements were structured. The fields were consistent. The analysts hated it. An agent now handles the extraction and flags the rows where confidence is below threshold for human review. The analysts spend their time on the flagged rows and on actual analysis. Speed gained is real. The work they were hired to do is what they actually do now.
In manufacturing, the equivalent is usually quality inspection logging or shift handover documentation. Technicians filling out the same form at the end of every shift, describing the same categories of events in slightly different words each time. An agent that reads the free-text notes and structures them into a consistent log format is not exciting. It is genuinely useful because the structured data feeds downstream reporting that was previously unreliable due to inconsistent inputs.
In field operations, think about work order processing. A field technician closes a job and submits a short written summary from a mobile device. That summary needs to be categorized, the parts used need to be confirmed against the job code, and a follow-up flag needs to be set if certain keywords appear. This is not a hard reasoning problem. It is a pattern recognition problem at volume. An agent handles it cleanly, and the dispatcher who used to spend two hours a day triaging those summaries now has two hours back.
How to Pick Your Boring Win
I use a short filter when I am helping a team identify their first project. Run every candidate process through these four questions in order.
- Can a competent new hire do this task correctly after a one-hour briefing? If yes, the task is likely low enough variance to be a good candidate. If it requires six months of institutional knowledge, it is not your first project.
- Does this task happen more than 500 times a week across the team? If the volume is low, the compounding math does not work in your favor. You need volume to justify the instrumentation and oversight infrastructure you are about to build.
- Is there already a human quality check on the output? If yes, you have a natural safety net and a way to measure accuracy against ground truth. If the output goes straight into a downstream system with no review, you need to add that review layer before you automate anything.
- Would removing this task from a skilled person free them to do something that actually requires their skill? This is the framing test. If the answer is yes, you have a project worth doing. If the task is low-volume and low-skill and nobody is doing it consistently anyway, you are solving a problem that does not have a real cost.
If a process passes all four, you have found your first project. It will not win an award. It will build the internal credibility, the operational muscle, and the evaluation infrastructure you need to attempt the harder problems later.
The Hidden Value of Starting Dull
There is a second-order benefit to the boring first project that most teams do not anticipate. You learn how to run an AI system in production.
This sounds obvious until you have done it. Running a model in production means building logging so you can see what the agent actually did. It means defining a sampling strategy so a human reviews enough output to catch degradation. It means building a feedback loop so errors get captured and fed back into evaluation. It means figuring out what happens when the input format changes slightly and the agent starts failing silently. It means having a conversation with your team about when to trust the output and when to escalate.
None of that is the AI. All of that is the operations layer around the AI. And you cannot learn it on a high-stakes, high-ambiguity project without serious risk. You learn it on the invoice extraction or the work order categorization, where a bad week means some extra review time, not a compliance incident or a customer escalation.
Every enterprise AI deployment I have seen succeed had a boring first project somewhere in its history. The teams that skipped it and went straight to the impressive use case spent the next 18 months rebuilding trust with stakeholders who watched the first deployment stumble.
One Practical Takeaway
Before your next AI project scoping session, pull your team's task log or ask each person to write down the three things they do most often that feel like they could be done by a very attentive robot. Do not filter for importance. Filter for volume and consistency.
The task that comes up most often, that everyone slightly dreads, that produces a structured output, that a smart new hire could do after an hour of training, that is your first project. Not because it is easy, but because it is the one where you can actually prove you shipped something that works, measure it honestly, and use that proof to earn the right to do something harder next.
The boring win is not a consolation prize. It is the foundation. Build it first.