How long does AI implementation take for a small business?
An Implementation Sprint runs 4–12 weeks after scope is agreed. About 90 days is our planning frame for taking a workflow through discovery, build, testing, and handoff. A separate AI Readiness Audit takes 2–4 weeks only when substantial investigation is needed. A defined workflow can go directly to sprint scoping.
A short pilot and a production workflow can have different schedules. Compare the acceptance criteria, integrations, training, and support in each proposal. The timeline below is a planning example, not a requirement that every workflow takes thirteen weeks. What follows is the arc broken into its three phases, a week-by-week table, the levers that genuinely make it faster or slower, and one sequencing lesson from our largest published build. The full version of how we work is on the method page; this is the calendar view of it.
What happens in weeks 1–2?
Discovery and mapping: we watch the workflow run inside your real operation and write down where the hours, files, and decisions actually go. Validate the work before automating it.
The work is unglamorous on purpose. We interview the people who do the task, watch them do it, inventory which systems hold the data and who can export it, list the edge cases everyone “just handles,” and pin down what done means — in numbers, agreed in writing. The documented process may differ from what people actually do. Mapping exposes that gap before it becomes software. The depth of discovery depends on what is already known: a well-defined workflow may need confirmation rather than a separate audit. Our method starts with understanding the work, not with a mandatory discovery duration.
What happens in weeks 3–10?
The build — inside your real operation, on your real files. Integration, data preparation, and testing often take more time than the initial model setup. A working demo is a starting point, not an acceptance test.
This surprises most buyers, so it bears spelling out. Modern models are astonishingly capable out of the box; the hard part is everything around them. Data access and permissions to your system of record. Handling the invoice that arrives as a photo of a crumpled page. Teaching the system your terminology, your formats, your exceptions — the work the essay Teaching the Machine Your Business describes. Then testing on real files, because real files are where demos go to be humbled: a healthcare practice we would map, for instance, gets intake paperwork as faxes, phone photos, and handwriting, and the system has to route all three or staff will stop trusting it after the first miss. Weeks 3–10 are mostly this: plumbing, edge cases, and testing against reality until the exception rate is boring.
What happens in weeks 11–13?
Handoff and training: your team runs the system while we watch, and by the end they own it outright. No dependency by design.
The deliverables are concrete — documentation written for the people who will use it, training sessions for the operators and the exception-handlers, and an escalation path for the day something odd appears. Training is not a webinar; it is your bookkeeper processing Thursday’s real invoices through the new system with us in the room, hitting a real exception, and handling it. People trust what they have personally seen recover from a mistake, and manufacturing that moment on purpose is what the last fortnight is for. The important part is the posture: we do not hold the keys. The system, the prompts, the integrations, and the documentation are yours at handoff, and if you never call us again it keeps working. If you would rather someone else watch it long-term, Managed Services is a monthly retainer with no lock-in — but it is an option, not a tether. A vendor whose timeline has no training phase is planning to be permanent. Ask where handoff is on their calendar; if the answer is vague, so is your ownership.
What does the timeline look like, week by week?
This illustrative thirteen-week calendar shows the full process. It is not extra time added to every sprint. Your written scope sets the actual milestones; a separate paid audit is included only when needed.
| Phase | Weeks | What ships | What you should be doing |
|---|---|---|---|
| Discovery & mapping | 1–2 | Workflow map, data inventory, edge-case list, a written definition of done | Granting data access, naming one owner, telling staff why we are watching them work |
| Build & integration | 3–10 | The working system, wired to your tools, tested on your real files | Reviewing weekly outputs, flagging exceptions fast, keeping approvals to days not weeks |
| Handoff & training | 11–13 | Documentation, trained operators, an escalation path — you own all of it | Running the system yourselves while we watch, and telling us where it fights you |
The sprint band is 4–12 weeks. About 90 days describes the planning frame, while the delivery guarantee covers the scoped workflow: if it is not live within 90 days, we keep building at no charge until it is. Confirm the start date and acceptance criteria in the written scope. For the decisions that commonly hold up a build, see what delays an AI implementation.
What does a “two-week AI implementation” actually deliver?
It depends on the scope. A narrow workflow with ready data, an existing integration, clear acceptance criteria, and available reviewers may be delivered in two weeks. Other offers use that window for a prototype, a configured chat tool, or a pilot. The calendar alone does not tell you which one you are buying.
Ask what will run in your actual operation at the end: which systems it connects to, which tasks it completes, which exceptions it handles, and who can operate it without the builder. Check whether testing, training, and support are included. A pilot is useful when it answers a defined question before a larger commitment; a production workflow needs acceptance criteria appropriate to its risks. Our published Implementation Sprint range is 4–12 weeks after scope is agreed. A shorter offer can be credible without being equivalent to that scope.
What makes implementation faster — or slower?
Faster: exportable data, one named owner, and one workflow instead of five. Slower: approval bottlenecks and no system of record.
Both sides affect the schedule. Accessible data and a named owner who can make decisions reduce avoidable waiting; the builder must also confirm access early, surface dependencies, and bring testable work for review. A blocked approval can delay a milestone, especially when later work depends on it. Starting with one workflow keeps review and testing manageable. Paper records, missing permissions, or an unclear system of record may require preparation before the build can proceed. Use the free 20-point readiness checklist to identify those gaps before committing — being unready is a fixable condition, not a verdict.
Multiple workflows can run in parallel when dependencies are understood, access is ready, and each has enough delivery and review capacity. When they share untested connections or the same decision-makers, sequencing is often the safer choice. For example, a professional-services firm might stabilize intake before adding proposals so the second workflow can reuse tested records and handoff rules. A proposal for several workflows in one quarter should show the staffing, dependencies, and acceptance criteria for each. It may describe production work or pilots; the number of workflows alone does not decide that.
When should the highest-stakes work get built?
Last. In the MARCUS build at B:Side Capital — 14 agents across 7 departments — the highest-exposure work was deliberately sequenced last, after the low-stakes agents had run long enough to earn trust.
That ordering is the opposite of the demo instinct, which wants the most impressive thing first. But trust is the actual product of an implementation, and trust is built by boring reliability on low-stakes work — which is also why consequential actions in that system require human approval. Sequencing a deployment of this breadth takes more than software build time: the calendar also includes testing and building your team’s justified confidence in it. Plan discovery if it is needed: an audit takes 2 to 4 weeks at $3,500–$8,500. A defined workflow can go directly to sprint scoping; the sprint is $18,000–$60,000, fixed in writing before work begins. Both prices are on one page.