Plan around evidence gates, not a promised launch date. The following six-to-ten-week schedule assumes one bounded inbound workflow, one main operational integration and available internal decision-makers. It is an illustrative project plan, not an observed typical duration.
| Stage | Illustrative window | Main work | Exit document or evidence |
|---|---|---|---|
| 1. Establish the baseline | Week 1 | Review demand, current outcomes, costs and alternatives | Baseline workbook |
| 2. Specify the workflow | Weeks 1–2 | Define eligibility, permitted actions, success and exceptions | Pilot charter and policy register |
| 3. Clear access and risk | Weeks 1–3, in parallel | Data map, contracts, calling policy and system permissions | Approved control register and access plan |
| 4. Build the first version | Weeks 3–4 | Agent configuration, knowledge, tools and logging | Versioned agent and sandbox integration |
| 5. Engineer recovery | Weeks 3–5 | Human handoff, transaction recovery and routing fallback | Demonstrated failure scenarios |
| 6. Test before customers | Weeks 4–6 | Policy, audio, telephone, security and load testing | Test report and release approval |
| 7. Run a controlled pilot | Weeks 6–8 | Limited traffic, reconciliation and daily review | Outcome ledger and incident log |
| 8. Decide and expand | Weeks 9–10 | Economics, corrections, training and location checks | Go/no-go memo and operating runbook |
Do not assume a blocked access request can be solved through more prompt engineering. If no approved write API is available, change the scope to verified message-taking or a booking request—or postpone the project.
For a healthcare, multi-system or enterprise deployment, re-estimate every stage. This research does not establish a defensible universal implementation duration for those environments.