The default way companies pick their first AI project is to ask leadership what would be impressive. This reliably produces a demo that nobody uses. The work worth automating is almost always unglamorous, already annoying somebody, and invisible from an org chart.
Start from an uncomfortable premise: nobody in your company can accurately tell you how they spend their time. Not because they are hiding it, but because the tedious parts of a job are exactly the parts people stop noticing. Ask someone what takes them longest and they will name the hard thinking. Watch them for a day and it is forty minutes of moving information between two systems that do not talk.
So do not lead with a survey. Surveys return the work people think they should be doing.
Watch, then ask a narrower question
Sit with someone for an hour while they do their normal work and say almost nothing. You are looking for four specific things, and they are all visible without understanding the job:
- Retyping. Anything moved by hand from one screen to another. The information already exists in a structured form and a person is acting as the connector.
- Waiting on a person for a judgment they make the same way every time. If the answer is predictable from the inputs, the delay is pure cost.
- Documents produced from a template plus lookups. Quotes, reports, summaries, status updates. The shape is fixed and the content is assembled from things stored elsewhere.
- Work that happens because someone might ask. Reports nobody reads, prepared weekly, just in case. This is the highest return item on the list because the correct automation is often deletion.
Then ask one question, and phrase it exactly this way: what is the part of your week you would pay out of your own pocket to never do again. That phrasing beats every variant I have tried. It forces a ranking instead of a wish list, and it surfaces annoyance, which predicts adoption far better than importance does.
Selection rule
Automate the thing somebody already resents doing. Resentment guarantees you a user. Importance guarantees you a stakeholder, which is not the same thing and is worth much less.
Find what is already running
Before you build anything, find out what people are already using. Not to punish anyone, and it is worth saying that out loud before you start asking, or you will get nothing.
The answer is always the same shape. Several people are pasting company information into consumer tools on personal accounts. One person has built something genuinely useful in a spreadsheet or a script. Nobody has told anybody. That person is your most valuable find in the building. They have already done the hard part, which is caring enough to try. Show up curious rather than official and they will tell you exactly where the friction is.
This inventory is also your first real governance artifact, and it costs nothing to produce. You cannot write a sensible rule about a tool nobody has looked at. You cannot claim to know your exposure until you know which systems hold company data today.
Sort what you find
Once you have a list of candidate tasks, sort each one on two axes before you consider how to build anything.
How often does it happen, and how long does it take. A four hour task done once a quarter is sixteen hours a year and is almost never worth automating. A six minute task done thirty times a day is three hours a day and is worth a great deal. People consistently pick the four hour task because it feels significant. The six minute task is where the money is.
What does being wrong cost, and how fast would you notice. A drafted email that comes out wrong is caught by the person about to send it. A price quote that comes out wrong may go to a customer, get accepted, and become a contract. Same amount of automation, wildly different exposure. The second is not off limits. It needs a person in the path, built in from the start rather than retrofitted after the first bad quote.
Work one through
Take a real example. A quoting process at a small company. A request arrives by email. Someone reads it, looks up current pricing, checks whether this customer has negotiated terms, writes the quote, and sends it. Say it takes twenty five minutes and happens twelve times a day.
Split it into pieces and the picture changes completely:
- Reading the request and pulling out what was asked for. Messy input, plain output. One model call.
- Looking up current pricing. A database query. This has never been an AI problem.
- Checking negotiated terms for this customer. Also a lookup, assuming those terms are recorded somewhere. If they are not, you have found a much more important problem than the quoting time.
- Assembling the document. A template.
- Deciding whether an unusual request should be priced differently. Judgment. A person should own this, and it happens on maybe one quote in eight.
- Sending it. A person, for now, because this is the irreversible step.
Six pieces, one of which needs judgment and one of which needs a model to read messy text. The rest is plumbing that has been solvable for twenty years and simply was never plumbed. The twenty five minutes becomes about four, and almost none of the saving comes from the AI. It comes from noticing that five of the six steps were only manual out of habit.
What to do with the list
You will end up with more candidates than capacity, which is the good problem. Pick the first one on these grounds and no others: someone visibly wants it, being wrong is cheap and obvious, and you can finish it in under two weeks. Impressiveness is not a criterion. The first one exists to prove the loop works and to give you a real thing to point at when you write the policy in chapter thirteen.
Keep the rest of the list. It becomes the register, and having it written down is what lets you say no to the next shiny request without sounding like an obstacle.
Revision trail