Why pilots die

The pattern repeats: a team builds an impressive demo, leadership gets excited, and six months later the project is stalled. The causes are almost always the same three.

  • There was no business metric defined before starting. Without a baseline — hours, dollars, error rate — it's impossible to demonstrate improvement, and what isn't demonstrated doesn't get budgeted.
  • The data wasn't where it was assumed to be. Scattered, without clear permissions, or of insufficient quality. Data preparation is usually 70% of the real work.
  • Nobody owned the process. Automation changes how an area works; if that area didn't participate from the design stage, the result gets rejected.

The use cases with the best track record

Document processing

Extracting structured data from invoices, contracts, policies, records, or receipts. It's the use case with the most consistent return because the manual process is measurable to the cent and human error is high. It works especially well in operations with volume and varied formats.

First-line support

Not replacing the support team, but resolving the share of repetitive queries and routing the rest with context. The numbers we've seen hold when the scope is bounded: when you try to have it answer everything, quality drops and users lose trust.

Sales-conversation analysis

Summarizing calls, extracting frequent objections, and detecting risk signals in accounts. The value isn't in the summary but in the aggregation: understanding which objection repeats across fifty calls changes product and messaging decisions.

Anomaly detection

Fraud, billing errors, atypical consumption, operational failures. It's a domain where machine learning has worked for years and where the return is direct when there's enough history.

Quick filterA good AI use case has three characteristics: the process happens many times, a person does it repetitively today, and there's a historical record of how it was done well. If any of the three is missing, it's probably not where to start.

Build, buy, or combine

For most mid-sized companies, building models from scratch makes no economic sense. The real decision is between buying a solution specialized for the process, or integrating existing models on top of your own data.

The second option gives more control and is usually cheaper in the medium term, but requires internal technical judgment or a development partner. The first accelerates the start in exchange for less flexibility and vendor dependence.

What to resolve before scaling

  • Data governance. What information leaves the company, where to, and under what contract. In regulated sectors this is non-negotiable.
  • Human oversight. Define which decisions the system can make alone and which require review, with traceability.
  • Continuous measurement. A model that worked in the pilot degrades when the input data changes. Without monitoring, quality drops silently.

How we approach it

When we support a client on this, the first deliverable is never a model: it's an inventory of candidate processes with their volume, current cost, and data availability. From there comes a shortlist, and from that list one — just one — is chosen to take to production end to end. One case running in production generates more internal budget than five impressive pilots.