A company with twenty branches decides to put an assistant on its website. The instinct is to launch everywhere on the same day.
What happens instead is that every gap in the answers surfaces at twenty sites at once, twenty managers who were not asked start telling customers to ignore it, and the whole thing is judged a failure within a fortnight.
The same project, started at two branches with the managers involved, finds the same gaps quietly, fixes them, and reaches all twenty with everybody expecting it.
Step 1: write the network answers once
Everything true across all locations. Prices, policies, services, process, which is the foundation in consistency of answers across every location.
Step 2: define what is genuinely local
Hours, address, access, parking, stock, staff and anything a particular site offers that others do not.
Step 3: collect the local data in a fixed format
The same short set of fields from every branch, so it can be maintained centrally rather than as twenty separate documents.
Step 4: pick two pilot branches deliberately
One straightforward and one complicated. A pilot at two easy sites teaches nothing about the ones that will actually be difficult.
Step 5: involve the branch managers first
Before anything goes live. A manager who was asked supports it and a manager who was told undermines it, and that is the whole rollout.
Step 6: agree what reaches a person
Which conversations go to the branch, in what form and with what expected response, so nobody at a site feels replaced or ambushed.
Step 7: run the pilot long enough to see the gaps
A fortnight of real traffic produces the list of questions the answers do not cover, which is the actual output of a pilot.
Step 8: close the gaps before extending
Each unanswered question becomes an answer, and the set that reaches branch three is considerably better than the one branch one started with.
Step 9: extend in groups rather than all at once
Five at a time, with a pause between, so any remaining problem affects a quarter of the estate rather than all of it.
Step 10: give each branch its own view of what arrived
Volume, questions and outcomes for their site, which is what makes the thing feel useful rather than imposed.
Step 11: set up the reporting centrally too
Across locations, which is the problem described in reporting across locations without ten spreadsheets.
Step 12: decide who maintains the answers
One named owner centrally, with a route for branches to report that something has changed, or the whole thing decays within a year.
Step 13: review the unanswered questions monthly
That list is the roadmap. It tells you what the network is being asked and cannot yet answer, which no other source will.
Step 14: plan for the branch that resists
Every estate has one site that will not engage. Forcing it produces a worse result than leaving it out of the first rounds and letting the reporting from the other nineteen make the argument on your behalf.
Step 15: treat it as a change programme, not an installation
An assistant across twenty locations succeeds or fails on whether the managers were involved and whether the answers were maintained, which is the same lesson as rolling out a change across several teams. Set it up through install the widget and train your bot, with the multi site detail in how to roll out a chatbot across a multi. The sector view sits under b2b.