From Pilot to Rollout: Scaling Past Your First Kiosk

You scale past the first kiosk by treating site one as a template rather than a trophy: agree on pilot exit criteria before you extend, sequence the next sites by how different they are from the first, and manage content centrally with per-location overrides so every new building inherits what already works. Much of the four-to-six-week first-site timeline was one-time work, and it does not repeat at every address.

This piece assumes the hard part is behind you: a kiosk is live, people use it, and someone has asked the obvious next question. What follows are the decisions that only appear at site two.

Decide what "the pilot worked" actually means

Pilots often run 60 to 90 days, long enough for the original success criteria to blur into impressions. Someone liked it. Reception says it is quieter. That is not enough to justify a rollout budget, and it will not catch the problems that multiply across ten locations.

Write the exit criteria down before the pilot ends, and take them from the analytics the platform already reports — volume, intents, language mix, peak times, resolution rate, and unmet queries — rather than from anecdote:

• Resolution rate above a threshold you set in advance. Pick the number yourself, based on what the front desk was absorbing before — what matters is choosing it before you see the result.
• Unmet queries trending down, not flat. A pilot that logged unanswered questions and never folded them back into the knowledge base has proven the hardware, not the operating model.
• Intent coverage that matches reality. Compare the intents the assistant actually received against what staff predicted during discovery. A large gap means your content model needs work before it is copied to other sites.
• A language mix you understand. The assistant handles 50-plus languages, auto-detected and switchable mid-conversation, but you should know which ones your visitors actually use — it changes what is worth maintaining locally.
• Peak-hour behavior. Judge the busiest hour, not the average one. Rollouts are justified by peaks.
• A verdict from the people at the desk. Staff who worked alongside the pilot know whether it removed work or simply added a new thing to babysit.

If a criterion fails, fix it at one site. Fixing it at eight is the same problem multiplied by eight buildings, eight schedules, and eight sets of local staff.

Separate the one-time work from the work that repeats

A first kiosk typically runs about four to six weeks through discovery, build, tuning, pilot, and go-live — the sequence our kiosk deployment guide walks through in detail. The useful thing to notice at rollout time is how much of that was structural work you do once.

Done once, inherited by every later site: the core knowledge base, the persona and tone, the escalation policy, and the integrations — notifications through Slack, Teams, email, and SMS; lead capture into your CRM; ticketing; directory lookup through Azure AD, Google Workspace, or Okta; anything bespoke wired over REST APIs and webhooks. The internal security review belongs here too: your team makes that case once, not once per building.

Repeated at every site: the physical install, acoustic tuning for that specific room, the local content, a briefing for the local team, and a short observation window after go-live. All real work, but a far smaller job than the first one.

So the honest answer to "how long does site two take" is a shape, not a number: the same phases, with discovery and build largely pre-answered and the effort concentrated in install, local content, and tuning. Deep integrations stay the exception — a location that introduces a system the pilot never touched is its own project, and deep integrations generally run about eight to twelve weeks.

Sequence sites by difference, not by size

The instinct is to go to the biggest location next. Better to pick one that differs from site one in exactly one meaningful dimension, so that when something behaves unexpectedly you know what caused it.

Three dimensions matter more than the rest:

1. Acoustics. A hard-surfaced atrium, a busy store floor, and a small clinic reception are three different problems. Far-field multi-mic beamforming and voice activity detection let a kiosk pick one speaker out of a noisy space, but the tuning is per-room.
2. Language mix. A site with a materially different visitor population will surface content gaps the first site never did.
3. Local systems. If a location runs a scheduling, records, or badge-printing setup the pilot site did not, that is an integration, not a copy.

Change one variable at a time for the first few sites. After that, batch the lookalikes: locations that share acoustics, language profile, and back-end systems can go out together, because the learning has already happened.

Central content with local facts layered on top

The content model is what makes multi-site scaling tractable, and it has two layers.

The shared layer

Everything true everywhere lives once, centrally: what the organization does, policies, standard procedures, escalation rules, tone of voice. Edit it in one place and every kiosk reflects the change. That is also how you avoid the slow failure where ten locations drift into ten different answers to the same question.

The local layer

Each site then overrides the facts that are specific to it: opening hours, the floor plan behind wayfinding and the on-screen map, room and department names, the local staff directory used for check-in and host notification, and nearby services. The test is simple — if the answer would be wrong at another site, it belongs in the local layer.

Governance follows the same split. Role-based access separates admins, editors, viewers, and auditors, so a central team owns the shared knowledge base while a named person at each site keeps their own hours and directory current. Local ownership is not optional at scale: nobody at head office knows the third-floor meeting room was renamed last week.

What the cost does as you add sites

Scaling economics is one of the few genuinely simple parts of this. Kiosk AI is $500 per kiosk per month with unlimited interactions and no per-message fees, and no setup fee for standard deployments. Hardware is quoted separately, because the right enclosure and microphone array depend on the space, and enterprise deployments are custom-priced.

Two consequences matter for a rollout plan. The platform line is linear and forecastable: ten kiosks cost ten times one kiosk, with no step changes to discover halfway through the year. And because interactions are unlimited, a location far busier than the pilot does not cost more than a quiet one — success at a flagship site does not generate a bill. If leadership wants the business case rebuilt at rollout scale, our ROI breakdown covers the value side.

What actually compounds after site one

The reason rollouts accelerate is not that installation gets quicker. It is that four things accumulate:

• The knowledge base. Every answer written for site one is available to site nine on day one.
• The unmet-query backlog. Questions nobody anticipated at the pilot are already answered by the time the next kiosk switches on, so later sites launch closer to their ceiling.
• The integrations. Host notification, CRM capture, and directory lookup are configured once and reused, so the tenth site inherits a connected assistant rather than a standalone one.
• The playbook. Who briefs staff, what the go-live checklist is, which questions the local team always asks. This is the least glamorous asset and often the one that saves the most time.

Comparing locations is also where reporting stops being a per-kiosk curiosity and becomes a management tool: when one site shows a lower resolution rate than its peers, the cause is usually local content, not the platform. Our piece on voice AI analytics covers how to read those signals.

Be honest about what does not get faster

Some things stay stubbornly per-site, and a plan that pretends otherwise slips. Installation and acoustic tuning happen in each room. Local content has to be gathered from people busy with their real jobs. And change management resets at every location: the staff at site seven did not sit through the pilot and have their own version of the same worries.

What speeds up across a rollout is everything that lives in software. What stays the same is everything that lives in a building.

Plan the software side as inherited and the building side as new work each time, and your schedule will hold.