Start with a recurring task whose output someone on your team can check. Record how often it comes up, how long it takes today and which documents it needs. Drafting a quote from existing notes is easier to test within clear limits than automating an entire sales operation.
Compare AI with a template, a fixed rule or a feature in software you already use. AI is a candidate where varied text or documents need processing and the benefit can outweigh the review effort.
Choose the first workflow
Choosing a tool before defining the task makes comparison difficult: you do not yet know which inputs, outputs and checks it must support. Describe one workflow from the incoming request to final approval first.
Four questions help you find suitable tasks in your own business:
Where does waiting time occur? Tasks that sit idle because a specific person has to review, summarize, or write something up. Where does duplicate work occur? The same information typed in, reconciled, or reformatted multiple times. Where does search effort occur? Knowledge that exists in the business, in folders, inboxes, heads, but has to be laboriously tracked down every time. Where do transfer errors occur? Points where data is moved by hand from one system to the next, and occasionally something slips.
Anyone who can answer these four questions for their own business already has a list of candidates, without a single AI buzzword.
Three honest questions before any AI initiative
Before a candidate becomes a project, three questions help expose missing prerequisites.
First: is a good result clearly defined? If three employees approach the same task differently, establish which differences are useful and which cause errors. A shared example and a named reviewer give you a basis for evaluating the test.
Second: do the data and documents for it exist? A system that is supposed to answer questions about your records needs those records: findable, reasonably current, in readable form. A system that is supposed to draft proposals needs examples of what good proposals look like at your company. Often the material exists, just scattered. Sometimes, though, it only exists in the heads of two long-serving employees. Establish what material needs preparing before you start.
Third: who would use it in everyday work? Name the person who will run the test in their daily work. A tool that nobody builds into their working day is worthless, no matter how good it is technically. If the answer to this question remains vague ("well, anyone could use it now and then"), that is a warning sign. The best first projects have a specific person waiting for the relief.
A brief you can use to compare proposals
“We want to do something with AI” leaves the intended improvement undefined. A more useful brief is: “We want to turn site-visit notes into draft quotes. The responsible employee will check prices and scope before sending.” You can then assess a solution against a task, rather than its demonstration.
Knowledge of your own business is the foundation for this preparation. A concrete example then gives you and a technical partner a basis for assessing feasibility.
For your first candidate, record which task should become easier, who will check the result and how you will recognize an improvement after the test.
Where SMEs typically start
These tasks are possible first candidates when they recur frequently and their output is easy to check:
Recurring texts. Replies to similar inquiries, standard letters, meeting minutes, job postings; everything that is written from scratch every time, even though much of the content repeats.
Searching your own records. "How did we solve this back then?", "What does the contract say about this?", "Which requirements apply here?" Questions whose answers exist in the business, but finding them requires experience or patience.
Transferring between systems. Data from emails, PDFs, or forms that is entered by hand into an ERP, accounting, or planning system. Check existing import features first.
First drafts. A draft proposal, report or document can make the work easier. Measure the time including review and completion to see whether it does.
A limited test exposes errors and correction work before you involve more workflows.
Sometimes the right answer is: no AI project
A reliable workflow can stay as it is. If the likely benefit is smaller than the effort of setup, review and maintenance, an AI project is not worthwhile there. Check whether a template or an existing software feature already solves the problem.
This is especially relevant to fixed rules: routing a form or calculating known values often needs no AI. Keeping those steps deterministic makes them easier to trace.
What a structured start looks like
A shared review of the work is enough to select a first candidate. Implementation effort and budget depend on the task, data and systems involved.
Review your processes. Go through the four questions from the beginning: waiting time, duplicate work, search effort, transfer errors. And don't just ask the leadership level; ask the people who do the work every day. They know best where things get stuck.
Estimate effort and benefit honestly. How many hours per week go into a task? What happens if an error slips through there? Rough estimates are enough, but they have to be honest, even if the result is: not worth it.
Start small and measurable. One process, one clearly named benefit, one time period after which you evaluate soberly: did it deliver the promised relief? Agree in advance how much effort is acceptable and when to stop the test.
Involve employees early. Ask the people doing the work to choose test cases and review results. You will see whether drafts help them or create extra correction work.
Choose a candidate and collect a few typical examples with their current handling times. If several processes compete for attention or data and responsibilities are unclear, our AI workshop helps with that selection. For an initial conversation, describe the task, the people involved and the records available. Discuss your AI starting point.
