Process & timeline
From Pilot POC signature to the day-90 decision. Who owns each step, the three gates that cannot be skipped, and how the thirteen weeks lay out by team.
What happens from the moment a Pilot POC is signed, who owns each step, and when it has to be done by. A pilot runs three months.
Solution Architect owns onboarding enablement on the customer side: demos, platform setup, configuration and getting the customer's team working in the product. Customer Success owns the relationship and every communication. Product owns adoption: whether it sticks after enablement, measured on the analytics dashboard. PM and SA do not run the relationship; they equip CS with the onboarding tracker and the product analytics dashboard.
The four teams
Owns the deal to signature, and the commercial at day 90. Hands over a written success criterion, then steps back.
Accountable for onboarding enablement: demos, platform setup, access and connectors, Brand Brain, configuration, integrations, and delivery of customer requirements. Gets the customer's team working in the product.
Accountable for adoption: does it stick after SA has enabled them. Usage monitoring, intervention, the outcome evidence, plus the tracker and analytics dashboard CS runs on.
Owns the relationship and all communication: the weekly call, status updates, escalations, the day-90 review. The customer's single point of contact.
If a customer needs to be taught, demoed to, or set up, that is Solution Architect. If a customer needs to be told, asked, chased or reassured, that is Customer Success. If a habit has stopped sticking and usage is falling, that is Product. When SA or Product need to reach the customer, the meeting is arranged through CS, not around it.
The end-to-end flow
Paid, with a written success criterion. Nothing starts without both.
Sales walks CS, Product and SA through the problem statement, the success criterion, the buying process and who signs at day 90. CS takes over the relationship from this point.
Platform logins, ad accounts, social handles, CRM. SA specifies what is needed; CS is the one who asks the customer for it.
PM and SA build it in week 1 so CS has a live view of what is done, what is pending and what is blocked, without having to ask.
Crawl, hybrid and client lanes in parallel. Two weeks from the day inputs land.
Sources fresh, calibration accepted. Module configuration does not start before this. CS runs the sign-off conversation.
Only the modules they bought. Approval flows, rules, connectors, goals entered.
Spend, conversions and CRM outcomes match their own numbers. Nothing goes in front of a stakeholder until this is true.
PM and SA build it by end of month 1 so CS can see usage, adoption and goal movement without asking anyone for a number.
One per module bought, on their own data. SA builds it and demos it to the customer team. CS sets the meeting up.
Train the real users, move the habit, watch usage weekly and intervene on decline. This is where Product's ownership starts and ends.
PM and SA coordinate and deliver requirements raised during the pilot, inside months 1 and 2. Requirements landing in month 3 do not get proven before the decision.
Does it stick after enablement. Product reads the analytics dashboard weekly and intervenes when usage falls.
Old process stopped, adoption real, primary goal moving. CS runs the review; Product brings the numbers. New pilot scope closes here.
Product pulls adoption and goal evidence; SA closes the requirement log. CS shapes it into the customer narrative.
Built from real pilot volumes using the pricing model and the scraping calculator, not an estimate.
CS runs the room with the economic buyer present. An honest stop beats a drifting pilot.
Who does what, precisely
| Activity | Sales | SA | Product | CS | Customer |
|---|---|---|---|---|---|
Written success criterion Before signature | A | C | C | R | C |
Handover to delivery Week 0 | R | C | C | A | I |
Access, connectors, security pack Week 1 | I | A | I | R | R |
Platform setup and configuration Weeks 1 to 4 | I | A | I | I | C |
Onboarding tracker built Week 1 | I | R | A | C | I |
Brand Brain built and signed off Weeks 1 to 2 | I | A | I | R | R |
Data reconciliation Week 3 | I | A | I | I | C |
Demos to the customer team Weeks 2 to 8 | I | A | C | R | R |
Onboarding enablement and training Weeks 2 to 8 | I | A | C | R | R |
First wow moment Weeks 3 to 5 | I | A | C | R | I |
Product analytics dashboard built By end of month 1 | I | R | A | C | I |
Adoption monitoring and intervention Weekly | I | C | A | R | I |
Weekly customer call Weekly | I | C | C | A | R |
All customer communication and escalation Continuous | I | C | C | A | R |
Customer requirements coordinated and delivered Months 1 and 2 | I | A | R | C | C |
30 / 60 / 90 reviews At each checkpoint | C | R | R | A | R |
Outcome pack Weeks 11 to 13 | C | R | A | R | I |
Commercial and close Day 90 | A | I | C | R | C |
The two artefacts PM and SA build for CS
CS cannot own the relationship if they have to chase PM and SA for every answer. These two artefacts exist so CS can answer any customer question without a handoff.
Every onboarding task with its owner, status, blocker and target date, live and shared. CS uses it to answer 'where are we?' without asking anyone. SA maintains status; PM owns the format.
Weekly active users against seats, which surfaces get opened, work created per module, goal movement, and usage against estimate. CS uses it to spot a stalling account in week three rather than week eleven.
If CS has to ask PM or SA a question the customer just asked them, the artefact is missing something. Fix the artefact, not the individual answer.
Customer requirements: months 1 and 2 only
Requirements surface constantly during a pilot. The rule is about timing.
- On captureLogged in the tracker the same dayCustomer Success
CS captures what the customer said, in their words. No triage on the call.
- Within 48 hoursAssessed and scopedProduct + SA
PM and SA decide together: deliverable in the pilot, roadmap, or a Never Commit item. CS communicates the answer, whatever it is.
- Months 1 and 2Coordinated and deliveredProduct + SA
PM sequences it, SA builds it. Anything agreed for the pilot lands inside month 2 so it has time to be used and proven.
- Month 3FrozenProduct
No new pilot scope. A requirement accepted in month 3 cannot be adopted, measured or defended by day 90, so it goes to the post-pilot list instead.
A requirement delivered in week 11 has no adoption data and no outcome behind it at the day-90 review. It adds surface area and subtracts evidence. Say yes to the requirement, say no to the timing, and put it in the conversion scope.
Timeline by team
Read it as three bands. Solution Architect front-loads: build then enable, with demos and training running through month two. Product picks up where enablement lands, watching whether it sticks. Customer Success runs the whole length, because the relationship never pauses.
Access, connectors, Brand Brain. Nothing customer-facing works until this is real, which is why SA front-loads it.
Platform setup, demos to each team, training on their own tenant. Getting the customer's people working in the product is SA's primary job to be done.
Does it stick once SA steps back. Usage against seats, surfaces opened, intervention when it dips. Product answers for this, not SA.
SA hands to Product somewhere around week 4 to 6, and the handover is not a date, it is a condition: the customer's team can do the work themselves. Until then it is still enablement and still SA. After that, falling usage is an adoption problem and Product owns it.
The three gates
Gates are the points where the next phase does not start until the previous one is genuinely finished. Every stalled pilot in the pipeline skipped one.
Sources fresh, calibration accepted by the client against their own rulebook. Configuring modules on a half-built graph produces output the client rejects, and the pilot never recovers that time.
Our numbers match their platform. A dashboard that disagrees with their own reporting is worse than no dashboard, and trust is very hard to recover afterwards.
The old process has stopped and weekly actives approach seats issued. New pilot scope closes here. If adoption is not real at day 60, fix that rather than adding a second module.
Escalation
Only CS communicates status to the customer. A blocker explained twice by two different people, slightly differently, is how an account stops trusting the timeline.
The rule that matters: a gap disclosed by us early is a requirement. The same gap discovered by the customer at day 80 is a credibility problem. See Never Commit.
Timing that varies
- Enterprise and BFSI: add two to four weeks before week 1 for security review and access. IIFL ran a formal platform risk assessment with their infosec team; expect the same at any bank.
- Customer-driven evaluations: Kotak Neo runs its own two to three week pilot across several vertical leads before pricing is discussed. Align to their process rather than imposing ours.
- Client-lane delays: the two-week Brand Brain target starts from the day inputs land, not from signature. If inputs are late, CS says so in writing the week it happens rather than absorbing it silently.
Related
- 30/60/90 pilot plan for the module-by-module detail
- Goal setting for the metric checklists per module
- Onboarding SOPs for the full task-level checklist
- Onboarding Planner to generate a tailored checklist for a named customer