The AI implementation sprint: 30 to 90 days, first build in two weeks

For a while this page described the sprint as a fixed 90 days: a month to audit, a month to build, a month to roll out. That is the shape a large programme takes. It is not the shape most companies want, and it is not how most of our builds run. A leader with one process to fix does not want to read a plan in month two. They want to be testing in week two. So the sprint is now written the way it is actually run: 30 to 90 days depending on scope, with the first working build in your hands within two weeks.

Why the first build lands in week two

Every build we have run improves faster once the people who do the work can try it. A design document cannot tell you that the quote template is wrong for the accounts that pay net sixty, or that the intake line needs to ask for the site address before the name. The first build can, in an afternoon.

So week one maps and sets the price, and week two puts a working build in front of your team. It is connected to the tools the first system reads, it runs on real events, and it holds every result for a person to approve. It is not finished. The point is a short list, written by your team, of what it got wrong. That list sets week three.

The controls do not wait for launch. Review mode is on from the first day the build exists, which means nothing is sent, booked, or moved without a person saying so. That is what makes it safe to hand over a build that is two weeks old.

The four stages

The same shape runs on every install. What changes between a 30 day build and a 90 day one is how long the third stage lasts, not what it contains.

1. 01Week 1: MapThe operating map, the baseline, the first system chosen by value, and the price in writing.
2. 02Week 2: First buildThe first working build, in your hands and ready to test: wired to the tools it reads, running in review mode on real events.
3. 03Week 3 on: Review mode and changesReal work, your team approving every result, a round of changes every week, and narrow authority earned one proven action at a time.
4. 04Day 30 to 90: Launch, then Echelon runs itA measured launch on the date agreed in writing, by scope. Then weekly reports, monitoring, and the next system built on the same layer.

What decides the launch date

The date comes in writing with the price, and the same things set both. The sizing tool walks through them in five questions and gives you a tier and a timeline band, never a price.

1. 01ScopeOne process, one department, or the company layer. One process is the short end of the range. The company layer is the long end, because every department adds connections, records, and approval gates of its own.
2. 02ConnectionsReading from a CRM is one afternoon. Writing back into it, the inbox, the phone line, and the payment tool, both ways, with every connection verified before anything depends on it, is most of a week. Five or more connections usually means one of them is slow to grant access, and that moves the date, not the price.
3. 03Approval complexityMessages, money, and sensitive decisions wait for a person. Each gate is designed, placed, and tested. Regulated work needs more of them, and they are usually the right call. More gates means more weeks in review mode before anything earns narrow authority.
4. 04Your team's time in the queueThe build improves at the speed your team approves results and says why when they reject one. A team that spends twenty minutes a day in the queue reaches launch sooner than one that batches it on Fridays. Both are fine. The date is set with that in mind.

What changes between the first build and launch

Three things. The build handles more: each week it takes on the cases your team saw it stop on, until the exceptions queue is short and the reasons in it are real. The build earns authority: a routine action that has run clean in review mode for long enough starts running on its own, one action and one channel at a time, inside limits, with escalation rules and a full record. Messages, money, and sensitive decisions keep their approval gate all the way through. And the controls get written down: approval paths, limits, and who owns each decision, channel by channel, so launch is a document your team has already read, not an event.

1. 01Week 1A room, the people who do the work, and no software on purpose. The operating map, the baseline, the first system chosen by value, and one set price in writing.
2. 02Week 2The first working build, in your hands. Connected to the tools it reads, running in review mode on real events, with a short list of what to test first.
3. 03Week 3 and onA round of changes every week from what your team saw in the queue. Approval paths and limits written down channel by channel. Routine actions that have proven stable start running on their own, inside limits.
4. 04Launch, day 30 to 90A measured launch on the agreed date, with an exceptions queue and a named owner for it. Then the weekly report, and the next system scoped in writing on the same layer.

What is written down before anything is built

The sprint works because the commitments are in the agreement, next to the price and the guarantee, before week one starts.

• One set price, in writing, after mapping. It moves only if the scope does.
• Review mode before any autonomy. Your team approves every result first.
• Narrow authority for proven routine actions only. The system never moves money on its own.
• Month to month after launch. Thirty days' notice, no minimum term.
• You own every result, the data, and the documentation.
• If at least one system we deploy does not measurably save time, reduce a cost, or support revenue, we keep working until it does.

Where we start

Not every company is ready for a full company layer on the first call. That is a starting point, not a verdict.

• If your process still changes every week, we start by making it repeat.
• If the bottleneck is getting customers, we start with the system that answers and follows up with every lead.
• If nobody inside owns the work yet, we name the owner in the map.
• If one small tool already solves it, we tell you, and build what sits between the tools.

What we can and cannot claim

Echelon Advising LLC was founded in February 2026, so the number of full sprints run under our own name is small. The production numbers on this site come from systems this team shipped and runs. A live voice intake system built on this model answers 200+ calls a day in under a second, and that is a system in production, not a promise about yours.

What we can claim about the sprint is the shape and the controls, because they are written into the agreement next to the price. Bring one process to the mapping call and we will show you where it lands on this timeline. The process page has the six steps, with the output and the control at each one.