A 21-working-day installation is possible when the lead sources, CRM and ownership decisions are available at the start. The timetable covers a controlled first release, not the automation of every sales process.
What the 21 working days cover
The first release takes a defined set of high-intent enquiries from capture to acknowledgement, ownership, escalation and reporting. Typical sources include demo, pricing and contact-sales forms. The workflow can enrich and qualify those enquiries where the decision rules are agreed.
The timetable starts after the client has supplied access to the agreed standard integrations and approved the process map. Delays caused by unavailable access, third-party approval or a change in scope move the relevant dates. They should not be hidden inside rushed testing.
Every in-scope qualified enquiry is captured, assigned and acknowledged inside five minutes when the connected services are available. Human engagement is measured separately against the coverage promise the team can support.
The stages overlap where the dependencies allow, but approval and testing gates remain explicit.
- Days 1–3Audit
Confirm sources, timestamps, current delays and access.
- Days 4–7Design
Approve qualification, ownership and escalation rules.
- Days 8–13Build
Connect the stack and create the observable workflow.
- Days 14–17Test
Exercise normal, edge and failure paths.
- Days 18–21Launch
Release gradually, monitor and hand over.
Before day one: establish the implementation boundary
We begin by naming the exact forms, inboxes, territories and lead types in scope. We also identify the systems that hold the source data, the final CRM owner and the approved acknowledgement messages.
The client supplies the relevant administrative access through an agreed secure method. Credentials are not placed in project documents or sent in ordinary email. Where possible, service accounts and least-privilege access are used so the workflow can be operated without a personal login.
The starting pack
- A list of in-scope forms, inboxes and lead types
- CRM, automation, messaging and enrichment access
- Current territory, account and product ownership rules
- Primary and backup owners, including out-of-hours expectations
- Approved acknowledgement language by enquiry type
- Recent representative leads for testing
Days 1–3: audit the current response path
We trace each in-scope enquiry from the buyer’s submission to the first meaningful sales action. The audit records the systems crossed, manual handoffs, missing fields and timestamps that are currently available.
The result is a baseline and an exception list. It shows where a lead can wait, lose its original time, receive no owner or fail without an alert. If the existing data cannot support a reliable baseline, the first release adds the missing timestamps so improvement can be measured after launch.
Days 4–7: approve the process map
The process map turns sales policy into explicit rules. It defines which signals start the clock, which exclusions are safe, how conflicting ownership rules are resolved and what the buyer is told.
This is the main decision point for sales, marketing and operations. The workflow cannot settle an unresolved territory dispute or decide who covers an absent rep. The ownership and escalation template makes those questions concrete before configuration begins.
| Decision | Required approval | Recorded output |
|---|---|---|
| Qualification | Which signals enter, review or leave the sales route | Decision table and rule reason |
| Ownership | Which rule wins when account, territory and product conflict | Precedence order and fallback owner |
| Buyer response | What can be promised for each enquiry and coverage window | Approved message templates |
| Escalation | When a lead moves from primary to backup or manager | Timers, stop conditions and recipients |
Days 8–13: build the observable workflow
The workflow captures the original event, normalises the fields, applies the approved rules and writes the final owner and route reason to the CRM. Acknowledgement and internal alerts are tied to the result rather than sent independently.
Retries, duplicate protection and error handling are built with the successful path. The workflow keeps enough context to identify the affected lead and recovery action without placing unnecessary personal data in alert messages.
What is visible after the build
- Original submission and processing timestamps
- Qualification result and the rule that produced it
- Resolved CRM owner and fallback status
- Acknowledgement delivery state
- Acceptance and escalation state
- Workflow failure category and recovery owner
Days 14–17: test the paths that normally get missed
Testing covers expected examples and deliberate failures. We replay representative leads in a safe environment or agreed test mode, then verify the result in the CRM, messaging channel and workflow history.
- Known account, new account and unmatched territory
- Existing customer, open opportunity and duplicate enquiry
- Missing enrichment result and provider timeout
- Inactive or out-of-office primary owner
- CRM rejection, acknowledgement failure and workflow retry
- No acceptance before the first and final escalation timers
A test only passes when the buyer-facing action, internal owner and audit record agree. A successful automation run with the wrong CRM owner is still a failed business outcome.
Days 18–21: launch under observation
The system starts with the agreed sources and a named monitoring owner. We watch every in-scope route during the controlled launch, correct configuration defects and compare the live records with the approved process map.
The handover includes the current workflow inventory, operating rules, credential ownership, recovery procedure and reporting definitions. Managed optimisation then focuses on missed SLAs and recurring exceptions, not changes made for appearance’s sake.
What is included in the first release
- Response-path audit and baseline definition
- Approved qualification, routing and escalation process map
- Implementation across the agreed standard integrations
- Buyer acknowledgement and internal notification templates
- Failure handling, duplicate protection and audit fields
- Test evidence, operating notes and initial reporting view
Unusual legacy systems, custom middleware, large data migrations and newly discovered business processes are scoped separately. The aim is to put one commercially important response path into reliable operation, then extend from evidence.
What this means for your team
The technical build is rarely the slowest part. Fast implementation depends on quick access, one decision owner and written answers to the exceptions that currently live in people’s heads.
- Name a client-side owner who can approve routing decisions.
- Make primary and backup coverage explicit before testing.
- Provide awkward historical examples, not only clean demo leads.
- Keep the first release narrow enough to observe every live route.
How the 21-working-day guarantee is applied
If the agreed standard integrations are not live after the client supplies access and approves the process map, the first management month is waived. The guarantee applies to the agreed implementation boundary. It is not a promise of revenue, meeting conversion or third-party availability.
Before deciding whether the scope is a fit, use the diagnostic to document your lead volume, response time and funnel assumptions. That gives both teams a clearer starting point for the implementation conversation.