How long does AI implementation take?

Fixed Labs expects a first AI workflow to reach supervised production in three to six weeks after approval, with system access and settled rules. That is our published first-workflow expectation, not an industry average or a guarantee. A demo can come earlier; wider rollout and evidence of business benefit are separate dates.

For established businesses doing $5M+ in revenue, the useful question is not just how fast someone can build. It is when your people can safely use the result on live work. At an accounting firm, that means reserving the billing manager, the IT lead and the partner who decides exceptions—not just booking an engineer.

• Agree what “live” means before accepting a date.
• Separate build effort, waiting for decisions and observing real work.
• Reserve reviewers before the busiest part of the billing or tax calendar.
• Keep client-facing actions and professional judgment with named people.

What date are you actually planning for?

Plan for supervised production, not the first impressive demonstration. A demonstration shows an idea. A pilot checks a bounded workflow against agreed cases. Supervised production handles live work with review. Wider rollout expands the clients, users or processes covered. None of those dates automatically establishes a financial return.

When does the implementation clock start?

Write the start condition in the scope. Our AI implementation service publishes a typical sequence: discovery and assessment in week one, build and testing in weeks two through four, and supervised production in weeks four through six. Those windows overlap; they are not separate durations to add together.

The readiness assessment describes first workflows reaching production three to six weeks after approval. Do not turn that into a promise measured from the first email. Confirm how the working session, report, approval and access dates fit into your own proposal. If the scope is approved but IT cannot grant access yet, record the waiting period separately rather than hiding it inside engineering time.

A department-wide program is a different commitment. Adding a second practice system, a new client category or another approval chain changes the work. Estimate those additions after the first scope is clear; do not multiply or extend a first-workflow range by instinct.

Can existing software do the job?

Check configuration and existing features before commissioning custom development. Microsoft’s AI strategy guidance starts with a business problem, then checks data, skills, capabilities and cost before selecting a build-or-buy path. It does not supply a universal implementation duration.

If your current software can handle the process reliably, configuration may be the right answer. If the work crosses systems, depends on unwritten rules or needs a new review process, allow for that work explicitly. Choosing AI is not a reason to skip a simpler solution.

Copy this first-workflow planning table

Use this table in your project document and replace the blanks with names and dates. It is a planning template, not a completed client schedule or a standard promise. The finish condition matters more than assigning every phase the same number of days.

Sample invoice-draft calendar: keep three columns

Take a sample project that prepares draft invoices from approved time and engagement terms. Staff still decide held time, write-downs and whether an invoice can be sent. Use the rows below to ask for a schedule; fill in dates with your provider. There are deliberately no assumed hours or promised completion dates.

Some work can overlap. IT can prepare access while the billing manager documents rules. Other work cannot: you cannot verify a partner exception whose correct treatment nobody has decided. Record dependencies rather than adding every row into a misleading total.

Keep the implementation budget alongside the calendar. Your staff’s review time is a real input even when it is not part of the provider’s build fee. If the workflow is not chosen yet, use the accounting workflow shortlist first; a schedule for several undecided projects is not a useful commitment.

How much staff time should you reserve?

Ask for role-by-role commitments instead of accepting “minimal involvement.” There is no verified standard number of client hours that fits every workflow. Have the provider estimate the sessions and review work after seeing the scope, and ask each owner to confirm availability.

• Process owner: a walkthrough, the current baseline, and answers when the documented process differs from actual work.
• Experienced billing staff: normal examples, unusual cases, expected results and feedback on draft outputs.
• IT lead or provider: permission review, access setup and confirmation that the intended systems can be used.
• Approving partner or manager: decisions on exceptions, acceptance conditions and the live-use boundary.
• Operating owner and backup: daily review during the supervised start and a clear route for failures afterward.

Put an agreed response date next to each open decision. If a reviewer is away, either name a capable backup or move the affected milestone. Do not ask the build team to compensate by removing approval.

What can delay launch—and what the billing example tells us

Missing access, unresolved rules and unavailable reviewers can move the live date even when the technical work is straightforward. The useful response is to identify which milestone is blocked and who can unblock it, not to call every delay “AI complexity.”

What does our published accounting engagement establish?

Our accounting-firm implementation page describes two weeks spent with one firm’s invoicing team documenting billing rules and exceptions. Across the next three observed weeks, the supervised workflow completed 513 invoices. Staff approved every invoice before it went out.

The two weeks show that rule capture was substantive work. They are not a standalone measure of total implementation time. The three weeks are an operating observation window, not three more weeks of development to add to the preparation period. This engagement does not establish that another firm, another system or another workflow will launch on the same schedule.

The scheduling lesson is narrower and useful: involve the people who know the exceptions before committing to a live date, and retain their approval during operation. Do not trade those steps for a faster demonstration.

When should you start before busy season?

Work backward from a supervised live window when your reviewer and backup can actually participate. Then allow separately for discovery, approvals, access and the scoped build. Ask what happens if an approval slips. If the only available launch window puts unfamiliar live work into your team’s busiest deadline, keep the first release smaller or move it.

Keep a manual fallback and name who can pause the workflow. Decide how pending drafts will be handled if the workflow stops. Agree who monitors failures, maintains integrations and changes rules after launch. A successful first batch is not a substitute for operating responsibility.

For Fixed Labs, the published service includes building the workflow, a supervised start, monitoring, fixes and monthly results reviews. Your agreement should name the actual scope and responsibilities. It should also distinguish the first live workflow from expanding a wider AI program.

To plan your own window, book a discovery call. Bring one workflow, its systems, the process owner and the target window. Do not send client records just to ask about timing. The first decision is whether the workflow is ready to scope, not whether someone can promise the shortest date.