Where to start with AI: a practical first-90-days plan for mid-market teams

Where to start with AI, and what to do in the first 90 days, comes down to four decisions: pick one workflow with a measurable problem, set a single success metric before you begin, run a contained pilot with real users, and make a deliberate scale-or-stop call at the end. That sequence, done with discipline, beats any tool-first approach.

Why most companies stall before they start

The pressure is real. Boards are asking about AI strategy. Competitors are announcing AI initiatives. Your own team is already using AI tools, often without you knowing it. The natural response is to want to “do something with AI,” and quickly.

That urgency produces the most common failure mode: starting with a tool rather than a problem. A vendor gives a compelling demo. Someone buys licenses. A few people use the product enthusiastically for six weeks, and then it quietly stops. According to McKinsey’s 2025 State of AI report, roughly two-thirds of companies have not yet begun scaling AI, they are stuck in the testing phase. The gap between “we tried AI” and “AI is delivering value” is almost always a prioritization and sequencing problem, not a technology problem.

The fix is not to move slower. It is to move in the right order.

The one rule worth keeping

Before anything else: start with a problem, not a tool.

Document the business challenge you are solving before you evaluate any vendor or model. This sounds obvious and is routinely ignored. Research from Cloud Geometry and practitioners across industries points to the same pattern, tool-first initiatives solve problems you do not have while your actual pain points remain untouched.

A useful framing: where does your team spend meaningful time on work that is repetitive, structured, and low-judgment? Those are your candidates. Invoice processing, meeting summarization, first-draft document generation, support ticket triage, data extraction from reports, these are genuine starting points for most mid-market operations teams.

Picking your first use case

Not every high-value use case makes a good first use case. The best first project balances three factors:

Business impact, time saved, cost reduced, or error rate lowered in a way you can measure
Implementation effort, how hard it is to connect to your data, retrain your team, and maintain
Risk, what happens if the output is wrong, and how quickly a human would catch it

The matrix below maps that tradeoff. Start in the upper-left: high value, low effort and risk. Stay away from the lower-right until you have a track record.

BUSINESS VALUE

EFFORT + RISK

HIGH LOW

LOW HIGH

START HERE PLAN CAREFULLY QUICK WINS DEFER Meeting summarization First-draft documents Support ticket triage Invoice automation Predictive analytics Scheduling aids Email drafts Custom LLM build Enterprise-wide agent platform

First use case selection matrix. Map your candidate workflows by expected business value against implementation effort and risk. Run your first pilot from the upper-left quadrant.

Good candidates share a few traits: the workflow already happens (you are automating a real process, not inventing one); a human currently checks the output (so errors are caught); and the volume is high enough that even partial automation creates visible time savings. Brightlume AI’s analysis of mid-market use cases consistently points to document processing, ticket routing, and first-draft generation as the most deployable starting points for teams without a dedicated AI function.

Once you have two or three candidates, pick one. Not a portfolio. One.

The 90-day sequence

A 90-day window is long enough to run a real pilot and short enough to maintain momentum. Here is how to structure it.

• Audit candidate workflows • Score value vs. effort/risk • Define one success metric • Set baseline measurement • Name one owner

• Deploy to 3–6 real users • Human review on all outputs • Weekly feedback loops • Log errors and near-misses • Light access controls in place

• Compare to baseline metric • Interview pilot users • Document what broke • Scale, extend, or stop • Brief your board or CEO

PHASE 1 PHASE 2 PHASE 3

The first-90-days AI adoption sequence One use case. One metric. One owner. A deliberate decision at the end.

The 90-day sequence is not a transformation roadmap. It is a structured way to learn whether a specific AI application delivers real value before you commit further resources.

Days 1–30: assess and pick

Spend the first month doing the unglamorous work. Interview the team members who actually do the work you are considering automating. Measure how long it takes, how often errors occur, and what a meaningful improvement would look like. Then pick one workflow, one metric, and one person who owns the pilot.

The metric matters more than people think. “AI will help us” is not a metric. “The first-pass document draft will be completed in under five minutes, reducing review time by 30%” is a metric. Set the baseline before you touch a tool.

If you have not already taken stock of how your team is currently using AI, this is also the moment to do it. Most mid-market teams already have shadow AI in use, tools your people adopted without IT sign-off. That is not necessarily a crisis, but you need to know what exists before you layer a formal pilot on top of it.

Days 31–60: pilot with real users

Keep the pilot group small, three to six people who actually do the work. A small, honest group will teach you far more than a wide rollout where most participants log in twice and declare success. CohnReznick’s 90-day adoption framework and similar practitioner guides converge on the same point: early success almost always means AI does the first pass and a human confirms, edits, and ships.

During the pilot:

Keep human review on all outputs, do not automate consequential decisions without a checkpoint in the first 60 days.
Run short feedback loops, weekly, not quarterly. Fix what is broken while the pilot is small enough to adjust.
Log errors and near-misses, this data is more valuable than usage statistics.
Put light access controls in place, who can use the tool, what data it can touch, and how outputs are stored. This does not need to be a 40-page policy; it needs to be written down and understood.

The access-control question is worth pausing on. IBM’s AI guardrails guidance and Databricks’ AI governance best practices both point to role-based access, output logging, and clear human review steps as the minimum controls for any production AI workflow. These are not bureaucratic overhead, they are what allow you to diagnose problems quickly when something goes wrong.

Days 61–90: measure and decide

At the end of 90 days, you should have a simple answer to a simple question: did the pilot hit the metric you set on day one?

Compare your baseline to your current numbers. Interview the pilot users directly, what works, what frustrates them, what they stopped using and why. Document what broke. Then make a deliberate decision: scale it, extend the pilot, or stop.

“Stop” is a legitimate outcome and a sign of a healthy process. A pilot that fails cleanly and quickly is far less costly than a project that drifts for a year. Master of Code’s 2026 AI ROI research found that organizations moving AI from pilot to production at meaningful scale see an average return of 1.7x, but only when they measure rigorously and make honest scale-or-stop calls.

Build vs. buy: the short answer for most mid-market teams

For a first pilot, buy. Build later, selectively, only for processes that are genuinely core to your competitive differentiation.

The math on building custom AI solutions is unfavorable at the start: custom builds typically cost three to five times more upfront than purchasing an existing product, with ongoing maintenance running 25–35% of initial development cost annually, compared to 15–20% in subscription fees for commercial tools. Helium42’s build vs. buy framework and the McKinsey-informed analysis at Graph AI both arrive at the same recommendation for mid-market: buy the infrastructure, build the differentiated layer only after you understand the problem deeply from having used commercial tools.

Buy first. Prove value. Then decide what to own.

The people problem nobody budgets for

Google Cloud’s DORA 2025 report attributes 70% of AI transformation value to people, organizations, and processes, not technology. Yet most AI budgets are spent almost entirely on tools.

The two things that matter most in the pilot phase:

Tell your team why. Seventy-five percent of employees worry AI will affect their jobs, per a 2024 EY survey. If you do not address that directly and honestly, you will get passive non-adoption instead of real feedback. The pilot group needs to understand that the goal of the pilot is to learn, not to prove a predetermined conclusion.

Name a single owner. AI Smart Ventures’ analysis of mid-market pilot failures identifies single-person ownership as the most common structural gap, when the technical champion’s attention shifts, the project has no institutional home. One named owner, with explicit time allocated, is not optional.

If you want a structured view of your organization’s readiness before committing to a use case, the AI readiness assessment walks through data quality, team capacity, and process maturity, the three factors that most reliably predict whether a pilot will succeed.

A light governance layer from the start

You do not need a full AI governance program on day one. You do need a few things written down before you go live:

What data the AI tool is permitted to access
Who reviews outputs before they are acted on
How errors are logged and escalated
What the tool is not permitted to do

That is it for a first pilot. The goal is to establish the habit of governance, not to build a compliance infrastructure. If your company operates in healthcare, financial services, legal, or another regulated sector, the requirements are more specific, the AI governance framework and the cost of the AI compliance gap cover what regulated firms need to add. For most first pilots in unregulated contexts, the four bullet points above are sufficient to move responsibly.

When you are ready to scale beyond one use case, governance scales too. IntellaGrow’s Command Center platform deploys AI agents with permissioning, audit logging, and approval gates built in, designed for teams that want to move at speed without creating ungoverned sprawl.

The question is not whether to start with AI. It is whether to start with the right problem. Pick one. Measure it honestly. Decide at the end of 90 days. That discipline, not the tool you choose, is what separates organizations that extract value from AI from those that collect pilots.

Frequently asked questions

How do I know if my company is ready to start an AI pilot?

You are ready enough when you can name one specific, repetitive workflow that costs your team meaningful time, identify a person who will own the pilot, and commit to measuring a defined outcome. You do not need a perfect data infrastructure or an AI strategy document first. Those come after you have learned something real from a small pilot.

How long does it take to see ROI from a first AI use case?

Most well-scoped first pilots produce measurable output within 30–60 days, though converting that into a dollar figure takes the full 90 days to baseline properly. Research from Agility at Scale finds that organizations moving from pilot to production scale see an average 1.7x return, but only when baseline metrics are set before the pilot begins, not reconstructed afterward.

Should we build our own AI tools or buy commercial products?

For a first use case, buy. Commercial AI tools have matured significantly and are faster to deploy, cheaper to maintain, and lower-risk to start with than custom builds. Reserve internal development for workflows that are genuinely core to your competitive differentiation, and only after you understand the problem deeply from having used commercial tools first.

What is the most common reason mid-market AI pilots fail?

Most pilots fail for process and people reasons, not technology reasons. The three most common causes are: no defined success metric before the pilot begins; no single named owner responsible for outcomes; and no structured decision point to scale or stop. The technology is rarely the limiting factor. McKinsey’s 2025 State of AI report confirms this, two-thirds of companies stuck in pilot purgatory are held back by organizational, not technical, constraints.

Do we need an AI governance policy before we can start?

Not a full policy, but a few written rules: what data the tool can access, who reviews outputs, how errors are logged, and what the tool cannot do. That minimum is achievable in a day and is enough to run a responsible first pilot. More structured governance becomes necessary as you scale to more use cases or enter regulated workflows. The AI readiness assessment can help you gauge where your governance gaps are before you expand.