Where to start with AI when you have done nothing yet
No AI in your company yet, and the feeling you are late. A four-step method to pick a first project that reaches production instead of a demo.
5 min read
You have not shipped any AI yet. Your board asks about it, a competitor mentions it in every press release, and someone on your team has a ChatGPT subscription on expenses. It feels late. And you are not sure what your teams already paste into it.
It is not as late as it feels. We often meet companies that announced AI two years ago and still have a pilot and a slide. Starting now has one advantage: you can skip the pilot that goes nowhere.
Start here: list the tasks that cost the most hours, check the data behind them, pick one narrow first case, and put it in production. Four steps, in this order.
1. List the tasks that cost the most hours
Do not start from the technology. Start from the calendar: where do your people spend their week on work they would rather not do?
Ask each team lead for the three tasks that eat the most time. Then ask the people who do the task, not only their manager. They know which part takes the time, and it is rarely the part the manager names.
Put it in a table. Copy this one into a shared doc and send it to your team leads:
| Task | Team | Hours per month | Where the input lives | Examples of good output |
|---|---|---|---|---|
| Rewrite the same answers to customers | Support | ? | Helpdesk | Past answered tickets |
| Update the CRM from call notes | Sales | ? | Notes, recordings | Clean CRM records |
| Match supplier invoices to orders | Finance | ? | PDFs, email | Validated invoices |
| Copy data from emails into the ERP | Operations | ? | Shared inbox | Correct ERP entries |
Fill in the hours with a rough number, and add who does the task. A task that takes 40 hours a month from three people is a candidate. A task that takes two hours a month from the CEO is not, however annoying it is.
This list is worth more than any AI strategy deck. It tells you where a project can pay for itself, in your own numbers. If you want to take it further, our scope template turns the best row into a brief.
2. Check the data before you get attached
Every task on the list needs inputs and a correct answer. AI only works if both exist somewhere you can reach. The last two columns of the table already ask the question.
For each candidate, check three things:
- Where does the input live? A shared inbox, a folder of PDFs, a database, someone's head.
- Can we see past examples of good output? Answered tickets, validated invoices, approved quotes.
- Who is allowed to see it? Customer data, health data and HR files come with rules, and those rules decide where the system can run.
This is where most lists shrink. The invoice task looks perfect until you learn that suppliers send scans of paper, some of them handwritten. The support idea survives because three years of answered tickets sit in the helpdesk.
Data rules are rarely a blocker, but they shape the build. The system can run on servers in Europe, in your own cloud or on your premises. Decide that early, not the week before launch, and decide what your teams may paste into public tools in the meantime.
3. Pick one narrow first AI project
You now have two or three tasks that cost real hours and have usable data. Pick one. Then make it smaller.
"Automate customer support" is not a first case. "Draft a reply for tickets that ask where a delivery is, for an agent to check and send" is one. The second version ships in weeks, has an obvious measure, and leaves a person in the loop while you learn.
A good first case has five traits:
- one team uses it, so you get feedback from people who know the job
- you can measure it: hours saved, tickets handled, errors caught
- a wrong answer is cheap, because a person reviews it before it goes out
- it works inside the tools the team already opens every morning
- someone on your side owns it, with a few hours a week to test it and say what is wrong
That last one decides more projects than the model does. Without an owner, the project waits for feedback that never comes.
The temptation is to pick the most visible case, the one the board will like. The first project has one job: to reach production and prove the method works in your company.
The visible one can be second.
4. Put it in production, not in a pilot
This is the step most companies skip. They build a demo, show it in a meeting, everyone nods, and it never reaches the people who were supposed to use it.
A demo answers "can it work". Production answers "does it work on Tuesday, with real tickets, when the person who built it is on holiday". Only the second one saves hours.
In practice, production means a few unglamorous things:
- it runs inside the existing tools, not in a separate tab nobody opens
- someone watches the quality every week and fixes what drifts
- the team that uses it can say when it is wrong, and that feedback goes somewhere
- there is a number, agreed before the build, that says whether it worked
None of this needs a transformation programme. It needs one case and one owner.
That is the usual range on our projects, with a demo every week so the people who will use it see it take shape.
What it costs to wait, and what it costs to rush
Waiting has a price, but it is not the one the press releases suggest. It is the 40 hours a month your support team keeps spending on the same answers. You can count it.
Rushing has a price too. A pilot built in a hurry, on the wrong task, with data nobody checked, costs a few months and a lot of goodwill. The next AI idea in your company will meet a room that remembers the last one.
The four steps above are slower than buying a tool on Monday. They are much faster than a pilot that has to be restarted.
Where the free audit fits
The first three steps are what our free audit does with you: one hour on where your hours go, then a short document with the opportunities we see and the ones we advise against. Step 4 is the build, and it is the same team that does it.
Book a free audit and bring your list, or let us start it with you.
