Almost every mid-sized company we talk to describes the same situation. Leadership knows artificial intelligence can add value, there is a long list of ideas, and no one is sure where to start. Some ideas come from a vendor, some from a conference, and some from a department that has been asking for help for years. The real risk is not picking the wrong technology. It is picking a first project that cannot be measured, depends on data that does not exist, or that nobody in operations actually wants to use.
The first use case carries outsized weight. If it succeeds, it unlocks budget and builds confidence for what comes next. If it turns into a pilot that never ends, the internal verdict is usually "AI isn't for us," even when the real problem was the selection. That is why it pays to spend a few weeks on analysis before writing a single line of code.
Start with the problem, not the tool
A useful opening question is not "Where can we use AI?" but "Which task consumes valuable time, happens often, and produces a result we can check?" Walk through each department with that question and list specific processes: answering quote requests, sorting customer service emails, reviewing supplier documents, reconciling invoices, or putting together weekly reports.
For each process, write one line covering who does it today, how often it happens, and what goes wrong when it fails. Even an imperfect inventory like this is more useful than any list of technologies.
Four criteria to narrow the list
With the inventory in hand, score each candidate on four dimensions. You do not need a sophisticated formula; a one-to-five scale and a candid conversation with each process owner are usually enough.
- Business value. How much time, money, or risk is at stake if the process improves? Frame the benefit in terms your finance team will recognize: hours freed up, shorter cycle times, errors avoided, or sales currently lost to slow responses.
- Data availability. Does the data the solution needs exist in digital form, and can you reasonably access it? A brilliant idea that depends on information scattered across personal spreadsheets or paper files carries a high hidden cost.
- Risk and control. What happens if the system gets it wrong? First projects work best when a person reviews the output before it reaches a customer or a critical system. That way, mistakes become lessons rather than incidents.
- Adoption. Is there a team that wants the solution and an owner willing to use it every day? Without someone in operations who owns it, even a good model ends up unused.
The highest-scoring candidates are rarely the flashiest. They tend to be frequent, somewhat tedious support processes where the team welcomes the help and the output is easy to compare against manual work.
Define success before you build
Before kicking off, agree on three things with the owning department: the baseline (how the work is done today and how long it takes), the primary metric you expect to change, and the threshold at which the project counts as a success. If you cannot measure the current state, measure it for two or three weeks before you start. Without a baseline, any result is open to debate.
It also helps to define what the system will not do. A tight scope, such as "classify warranty emails and draft a reply without sending it," lowers risk and speeds up delivery.
Plan for production from day one
A prototype that runs on an analyst's laptop is not a solved use case. From the design stage, ask where the solution will live, which systems it connects to (ERP, CRM, email, WhatsApp), who will maintain it, and how you will notice if its quality starts to slip. These questions do not slow the project down. They keep it from stalling as a demo.
If the use case involves personal data from customers or employees, factor in privacy obligations from the start. In Colombia, that means Law 1581 of 2012: a clearly stated purpose, the data subject's authorization where required, and appropriate security measures. Designing around these rules is far cheaper than retrofitting them later.
A realistic plan for the first quarter
- Weeks 1 to 3: build the process inventory, score it against the four criteria, and select a primary use case plus a backup.
- Weeks 4 to 6: measure the baseline, review the data, and build a prototype using real information.
- Weeks 7 to 12: deliver a version embedded in the actual workflow, with human review, visible metrics, and an explicit decision at the end: scale, adjust, or stop.
Stopping a project is a perfectly valid outcome if the decision is based on data. What you want to avoid is the pilot that never ends.
The best first use case is not the most ambitious one. It is the one that proves measurable value within weeks and leaves behind capabilities, such as clean data, integrations, and quality criteria, for the next one.
If you would like an outside perspective on your list of candidates, our initial assessment is designed for exactly that: organizing the ideas, reviewing the data you have, and recommending where to begin.
