An AI enablement roadmap for mid-market: a framework for the messy middle

Mid-market AI enablement (50-500 person companies) is the work of moving from "individual employees use AI tools" to "the organization has a coherent AI capability." The standard enterprise AI playbooks were written for organizations with internal data science teams, dedicated CIOs, and multi-year transformation budgets. The startup playbooks were written for organizations small enough to make decisions in hallway conversations. Mid-market lives between those, and most of the published frameworks fit poorly. This is the framework we use across mid-market AI enablement engagements — five stages, run as overlapping streams.

Why mid-market AI is different

Three properties define the mid-market position and shape what works:

1. You have enough employees that informal coordination breaks down, but not enough to staff a dedicated AI organization. The 200-person company cannot rely on "everyone uses what works for them" because the coordination cost is too high; it also cannot stand up an AI Center of Excellence with 12 people because the headcount budget is not there.
2. You have data, but it's fragmented across SaaS systems. Unlike enterprise (where data is in a warehouse, even if messy) or startup (where data is small enough to reason about manually), mid-market data lives across Salesforce, HubSpot, the product database, support tools, and 30 SaaS systems with varying API quality.
3. The AI buy-vs-build decision is harder. At enterprise scale, the build option is staffed; at startup scale, building is the default. Mid-market has neither obvious answer. Most engagements we run start with this question.

These three properties collapse the AI enablement problem into a more focused sequence than enterprise frameworks suggest. We do not need 47 capabilities; we need five stages, run with appropriate overlap, by people who also do other things.

The competitive landscape: Accenture, Deloitte, BCG all publish AI enablement frameworks aimed at enterprise. They are good for what they target; they fit mid-market poorly. The category-leading mid-market voice in AI enablement is — frankly — open. We are writing into that gap.

The five stages

The stages are sequential at the start (Discovery before Pilot makes sense) but overlap once Foundation is underway (Pilots can begin before Foundation is complete). The mistake we see: treating them as strict waterfall, which produces 18-month roadmaps that lose momentum.

The realistic timeline: stage 1-2 in months 1-4, stage 3 starting month 4 and running through month 8, stages 4-5 ongoing from month 6.

Stage 1: Discovery

Discovery is the answer to "where could AI plausibly help us, and which of those should we pursue first?"

The standard mistake at mid-market: skip discovery, jump to "build a chatbot" because that's what other companies are doing. The chatbot is sometimes the right thing; more often, the highest-value AI application is something nobody at the company has named yet.

The discovery process we use:

Weeks 1-2: Inventory of pain points.

Run structured interviews with 8-15 people across functions. The questions are not "where could AI help?" — that produces wish-list thinking. The questions are "where do you spend time on work that feels mechanical?", "where do decisions get made on incomplete information?", "where do customers ask the same questions repeatedly?". The answers reveal AI opportunities; the labels come later.

Weeks 3-4: Inventory of data and capabilities.

For each candidate use case, assess: what data exists, where does it live, what's its quality, what's its governance posture. AI applications fail more often from data unavailability than from model limitations.

Concurrent with this: assess the team's existing AI capabilities. Who has done this before? Who has time? Who would champion a use case?

Weeks 5-6: Prioritization and selection.

Score candidate use cases on:

• Feasibility: Is the data available, is the technology ready, is the use case bounded?
• Impact: What's the value if it works? Who benefits?
• Reversibility: If the AI produces a wrong answer, what's the consequence?
• Visibility: Will success be visible to leadership?

A 2x2 of feasibility-impact, with notes on reversibility and visibility, surfaces 2-4 candidates for pilot. Defer the rest.

The output of discovery: a one-page decision document for executive sign-off. What we'll pilot, what we considered and rejected, what we'd revisit later.

Stage 2: Foundation

Foundation is the work of making AI applications possible to build, deploy, and operate at the company. This is not glamorous; it determines how fast everything that follows can move.

Four sub-streams within Foundation:

Data access

The minimum: a way for AI applications to read the data they need without each application building its own integration.

For mid-market, this usually does not require a full data warehouse. It requires:

• Read-only API access to the SaaS systems that hold relevant data (Salesforce, HubSpot, support tools, etc.)
• A small data store (Postgres, BigQuery, Snowflake — your choice; the scale doesn't usually demand a specific platform) for data that needs to be aggregated or persisted across systems
• A documented inventory of "what data is available where, with what governance restrictions"

The mistake we see: trying to build the perfect mid-market data platform before any AI application exists. Build the data infrastructure for the pilots; expand from there.

Tooling baseline

Pick a default LLM provider (Anthropic, OpenAI, Google, or a managed Bedrock/Vertex deployment) and a default deployment pattern (managed serving, self-hosted, or third-party platform like Vellum or Langfuse for observability). Single defaults reduce coordination cost; teams can opt into alternatives with justification.

For mid-market, we typically recommend:

• One frontier API provider for primary use cases (Anthropic Claude has been our default for the last 12 months for most engagements; OpenAI for use cases with specific OpenAI-only features; Gemini for Google Workspace integration)
• A default observability stack (Langfuse for LLM-specific traces; sometimes integrated with existing observability like Datadog)
• A default vector database for retrieval use cases (Qdrant, Pinecone, or pgvector depending on team preferences and scale)

The defaults should be reviewed every 6-9 months. The market moves; what was the right default in early 2025 is not necessarily right today.

Governance baseline

Three documents, kept short:

1. Acceptable use policy. What kinds of data can go into AI tools, what are the boundaries, what's prohibited.
2. Vendor evaluation criteria. What questions get asked before a new AI vendor is approved (security review, data handling, contract terms).
3. Incident response process. What happens if an AI application produces a wrong answer that has consequences.

These exist to enable, not gate. Governance documents that try to anticipate every scenario become checklists that nobody reads. Governance documents that name the principles and the decision-making process get followed.

We cover this in more depth in the LLM governance framework piece.

Skill development

The mid-market AI enablement engagement always involves bringing some team members up to speed on the practical work. Specifically:

• Engineers who will build AI applications need exposure to prompt engineering, evaluation, and the ecosystem
• Product managers who will own AI features need a working understanding of LLM capabilities and limits
• Operations staff who will support AI applications need familiarity with the failure modes

This is best done through hands-on work on the pilots, not through abstract training. Pair an engineer who has done LLM work before with one who hasn't; the second engineer leaves the pilot with practical capability.

Stage 3: Pilot

Pilot is the production deployment of 2-4 AI applications selected during Discovery, built on the Foundation laid during Stage 2.

The principles that determine pilot success:

Bounded scope. Each pilot solves one specific problem with one specific application. "An AI customer support assistant" is too broad; "an AI assistant that suggests relevant knowledge-base articles to support agents during ticket triage" is bounded.

Honest evaluation. Each pilot has explicit success criteria written before launch. Not "users will be satisfied" but "ticket-handle-time reduces by 15%, measured over 4 weeks."

Visible outcomes. Each pilot reports its results to the leadership cohort that approved it. Wins and losses both. Pilots that disappear into "ongoing optimization" never get the executive credit that funds the next stage.

A typical pilot timeline:

• Weeks 1-4: Build (or integrate vendor solution)
• Weeks 5-8: Internal testing and refinement
• Weeks 9-12: Limited rollout (one team, one customer cohort)
• Weeks 13-16: Full rollout or kill

The pilots that survive to "full rollout" are the foundation for Stage 4. The pilots that get killed are also valuable — they teach what doesn't work and free engineering capacity.

In our engagement experience, roughly 60-70% of mid-market AI pilots survive to full rollout. The 30-40% that don't survive are usually killed for one of these reasons: data quality below what the use case required, the AI's value-add was smaller than expected, the integration overhead exceeded the benefit. All three are legitimate kill reasons.

Stage 4: Scale

Scale is the transition from "we have AI applications" to "we have an AI capability."

The signals that the company is ready for Stage 4:

• Multiple AI applications in production
• Engineers across different teams asking "how do we build something like that for our area?"
• Operations team handling AI-related tickets routinely
• Leadership asking about AI-related cost, governance, and roadmap as recurring questions

Stage 4 work:

Establish an AI capability team or guild. Not necessarily a separate organizational unit; sometimes a working group across engineering teams. The role is to maintain the patterns, evaluate new tooling, support teams building new AI applications, and represent AI in technical decisions.

Develop reusable patterns. Common needs across AI applications (prompt management, evaluation, monitoring, retrieval) get factored into shared tooling rather than re-implemented. This is platform engineering work for AI specifically.

Build evaluation infrastructure. Pilot-stage evaluations are often manual. Scale-stage evaluations need to be automated — model behavior over time, regression testing for prompts, cost monitoring per use case.

Refine governance. The minimum governance from Foundation expands as the surface area grows. Per-use-case risk classification, audit trails, model-version management.

The AI Center of Excellence piece covers the structure choices in more depth. The short version: at mid-market, a guild model (engineers who own AI in their teams plus a coordinator role) usually beats a separate-team model.

Stage 5: Optimize

Once the capability is in place, the ongoing work shifts to optimization. This is also the work that compounds — every quarter of disciplined optimization produces results that exceed the previous quarter's baseline.

The optimization streams that matter at mid-market:

Cost. AI applications at scale produce real cost. The framework we cover in our companion piece on GenAI cost is the structured approach.

Quality. Model behavior drifts; user expectations rise; prompt engineering evolves. Continuous evaluation against a held-out evaluation set catches regressions and surfaces improvement opportunities.

Governance. The acceptable-use policies written during Foundation need refresh as the use cases expand. New AI capabilities (agents, multi-modal, longer context) raise governance questions that the original policies don't address.

Adoption. AI applications that work but don't get used produce no value. Tracking adoption, identifying friction, closing the gap between "available" and "actually used."

Sequencing in practice

The five stages, mapped to a typical 12-month engagement:

The overlap is intentional. Strict waterfall — finish Discovery before starting Foundation — produces 18+ month timelines and loses leadership patience. The overlap requires acceptance that some Foundation work happens before Discovery is complete (because Pilot needs both); that's fine.

Where this framework breaks

Honest limitations:

• Highly regulated industries. The Foundation stage in regulated industries takes 2-3x longer because of compliance review cycles. The framework still applies; the timeline stretches.
• Companies with no existing data infrastructure. If you have no system of record for the data the pilots need, the Foundation work is much larger and may be the entire engagement. The framework assumes a data baseline exists, even if fragmented.
• Companies whose AI ambitions are all customer-facing. Customer-facing AI raises additional product, brand, and risk considerations that the framework treats lightly. We adapt for this; the structure holds.
• Companies that are pre-Series A or in active fundraising. The 25-30% of cross-functional time the framework needs doesn't exist in those moments. Defer the practice; revisit when capacity returns.

How to assess where you are today

Score 0-3 on each stage:

• 0: Not started
• 1: Initiated, output not yet produced
• 2: Output produced but not yet acted on
• 3: Output acted on; practice runs ongoing

Score interpretation:

• 0-4: Pre-stage. The work to do is mostly procedural — naming the working group, scoping discovery. Internal lead can drive without external help.
• 5-8: In progress. The framework helps prioritize the next 90 days. Identify the lowest-scored stage and bring it to a 2 before adding work elsewhere.
• 9-12: Mature for mid-market. The remaining work is sustaining and adapting to new AI capabilities. Capability evolution becomes the primary work.

FAQ

Q: At what company size does this framework start to apply? Roughly 50 employees, or about $5M ARR for typical SaaS. Below that, AI enablement is informal and the framework's overhead exceeds the benefit. Above that, the coordination cost of "everyone does what they want" starts to bite.

Q: How is this different from the enterprise AI frameworks from Accenture, Deloitte, etc.? The enterprise frameworks assume staffed AI organizations, multi-year budgets, and a CIO-led transformation. Ours is a focused subset designed for mid-market constraints — existing engineers do the work, the budget is real but not strategic, and the timeline is months not years. We use the enterprise frameworks for genuine enterprise engagements; the mid-market specialization is the work that doesn't pay back to apply enterprise patterns at smaller scale.

Q: We are already mid-Stage-3 (have pilots in production) but never did Stage 1 properly. Should we go back? Not entirely. Audit the pilots: are they solving the highest-value problems, or did they happen because someone was excited about a specific tool? If the pilots are well-aligned, proceed to Stage 4. If they're not, run a lightweight Discovery on the broader question of "what are we missing?" while continuing the existing pilots.

Q: How much does this cost? The internal cost is roughly 25-30% of cross-functional time (engineering, product, ops) over 12 months, plus tooling and infrastructure (typically $30k-$150k annually depending on scale). External consulting cost varies; we'd characterize a typical mid-market engagement as supporting a 3-9 month period of the work, not the full 12 months.

Q: Can we hire a Head of AI to do this instead of using a framework? You can. The Head of AI brings their own framework. The question is whether the hiring market is favorable, whether the role fits at your scale (often it doesn't until 200+ employees), and whether you have a strong opinion on what kind of AI leader you need before you hire. We have seen both paths work; we have seen both fail.

Q: How does this interact with our broader digital transformation roadmap? AI enablement is one stream of broader transformation; integrate the planning. Specifically: the data work in Foundation overlaps with broader data strategy; the governance work overlaps with broader IT governance; the platform engineering work overlaps with broader platform investments. Coordinate; don't build in isolation.

*If you're evaluating where your organization sits against this framework and would like a working session to map the next quarter, our team can help. The framework is open; you can run it yourself from this post without engaging us.*