Introducing AI in the Mid-Market: the First 90 Days

Many mid-sized companies consider themselves behind when it comes to artificial intelligence. There is a pilot group, a few experiments with a chat tool, perhaps a presentation from the IT department. But no robust plan. No figure that demonstrates the benefit. The usual outcome is standstill: a great deal of trial and error, little decision-making. This guide describes a sober roadmap for the first 90 days. It is built so that, at the end, a well-founded decision is in place: expand, adjust or stop.

Why 90 days is the right time horizon

Ninety days is enough to test a genuine use case in production. It is short enough to enforce discipline. Those who allow themselves a year lose the pressure to decide. Those who expect a result in two weeks are merely measuring enthusiasm rather than impact. The framework is divided into four phases: stocktaking (weeks 1–2), use-case selection (weeks 3–4), pilot (weeks 5–10) and measurement with a decision (weeks 11–13).

The sequence matters. Failed AI projects rarely fail because of the technology. They fail because of a missing question. Only once it is clear which bottleneck is to be solved is it worth selecting a tool.

Weeks 1–2: stocktaking

The first two weeks are not about AI but about your own company. Three areas are recorded:

• Processes: Where do recurring, rule-based or text-heavy tasks arise? Which ones consume a great deal of qualified working time without the result needing to be individual? Typical candidates are research, document creation, classification of enquiries and data transfer between systems.
• Data: What information is available, in what quality, and who is permitted to use it? An AI system is only as good as the data it can access. Scattered, outdated or legally unclear data holdings limit any use case.
• People and rules: Who would work with the result? Which internal policies, data protection requirements and works agreements are affected? If the eventual user group is not involved, the result is a solution that no one uses.

At the end of this phase there is a short, honest list: three to five bottlenecks, each with a rough estimate of the time tied up. Anyone wishing to structure this stocktaking and make it comparable can underpin it with an AI readiness assessment, that is, a systematic evaluation of processes, data situation and organisational maturity.

Weeks 3–4: use-case selection

From the bottleneck list, exactly one first use case is selected. The temptation to start several in parallel is strong and usually a mistake. Attention and measurability become spread thin. In the end, no result can be cleanly attributed.

A good first use case meets four conditions:

• Definable: a clear beginning and a clear end, not an entire business area.
• Measurable: there is a metric that can be compared before and after, such as processing time, error rate or throughput time.
• Tolerant of errors: an incorrect interim result causes no immediate harm, because a person checks it before it goes out.
• Relevant: the solution addresses a noticeable bottleneck, not just a peripheral issue.

This is why internal use cases are better suited to getting started than a public chatbot. A system that pre-sorts support enquiries or prepares a draft quotation can be tested under controlled conditions. An assistant that talks to customers unchecked shifts the risk outwards before the quality is known.

A shared language is helpful here. Terms such as agent (an AI system that carries out several steps independently), RAG (answers based on your own documents rather than only on training knowledge) or hallucination (an invented but plausible-sounding statement) should be understood the same way across the team. The glossary provides short, self-contained definitions for this. Whether a simple assistant is sufficient or a multi-step automation makes sense becomes apparent when looking at existing agent solutions.

Weeks 5–10: the pilot

In the pilot, the selected use case is actually built and deployed with a small user group. The aim is not the perfect system but a working version that reflects real work. Three points determine how meaningful it is:

Real data, real tasks

A pilot based on invented examples yields no robust insights. Use real enquiries, real documents and real workflows, within the bounds of data protection and with clear authorisation. Only then does it become apparent where the system holds up and where it fails.

A human in the loop

In the pilot, a qualified person checks the results before they take effect. This guards against errors and at the same time provides the data for measurement. How often was the result directly usable, how often did it need reworking, where did the errors lie?

Record the effort realistically

Note not only the successes but also the effort: setup, maintenance, corrections, ongoing costs of the tools used. A solution that saves time but permanently requires support has a different business value than one that, once built, largely runs on its own.

At the latest here, the question of in-house development capability is decided. As long as standard tools suffice, a pilot can often manage without programming. Once your own workflows, interfaces to existing systems or a controlled data connection are required, technical implementation is needed. Vetted specialists for this can be found in the overview of AI freelancers.

Weeks 11–13: measurement and decision

At the end there is a comparison against the initial state. The metric from the use-case selection is evaluated, set against the effort and supplemented by the feedback from the user group. From this follows one of three decisions:

Even a stopped pilot is not a failure if, within 90 days and with a manageable outlay, it has led to a clear answer. It is not the quick stop that becomes expensive. What becomes expensive is the project without a measurement point that runs on for years without anyone knowing its value.

The most common mistakes, honestly named

• Starting with the technology: Buying a tool first and then looking for ways to use it leads to solutions without a problem. Reverse the sequence.
• Too many use cases at once: Parallel starts dilute measurement and attention. One first.
• No metric: Without a baseline figure, no benefit can be demonstrated. Enthusiasm is not a measurement.
• Considering data protection and data quality too late: Both determine feasibility and belong in the stocktaking, not in the sign-off.
• Not involving the eventual user group: A technically successful pilot that no one accepts still fails.
• Ignoring the limits: AI systems produce plausible-sounding errors, they do not understand context the way a person does, and they do not replace responsibility. Where results are legally or commercially binding, a human check remains necessary.

Conclusion and recommended action

The first 90 days are decided less by the technology used than by the way of working. Those who begin with an honest stocktaking, select exactly one measurable use case, test it with real data and arrive at a clear decision at the end gain a reliable foundation. This holds true regardless of whether the first pilot is expanded or stopped.

A concrete recommendation: set the framework this week. Appoint a responsible person, block out two weeks for the stocktaking and define in advance which metric will determine success. Anyone wishing to translate the roadmap into a robust roadmap will find the right framework in the AI strategy offering; a structured positioning is provided by the AI readiness assessment.