Cutting new-centre setup from 9 days to under 3 hours

The situation#

The network was adding centres steadily and planning to accelerate. Head office was the bottleneck, and nobody had quantified it.

Opening a centre meant creating accounts, configuring local pricing and tax, setting up a subdomain and branding, provisioning payment collection, loading the local curriculum calendar, adding staff users and running training. Seven manual sequences across four systems, owned by three different people, coordinated over email.

Measured properly it took nine working days, of which roughly two were actual work and seven were waiting for the next person. Franchisees who had paid a fee were sitting idle for a fortnight before they could enrol a single child.

Underneath that, the platform had drifted into four versions. Centres onboarded in different years were running different builds, because upgrading required a manual migration nobody had time to run across a growing network.

What we did#

Weeks 1–2 — instrumented the opening. Before proposing anything, we timed the real process. The nine-day figure surprised the leadership team, who had been quoting four. The seven waiting days, not the two working ones, were the business case.

Weeks 3–6 — built the provisioning path. A new centre created from a template with its own configuration, users, domain, branding and payment setup, executed as one automated sequence with no manual steps. Infrastructure as code, so a centre is a declarative record rather than a checklist.

Weeks 7–11 — consolidated the versions. The harder half. We modelled the genuine differences between cohorts — local pricing, tax treatment, curriculum variants — into first-class configuration, and retired the rest as accumulated preference. Then migrated every centre onto one build.

Weeks 12–13 — franchisee support automation. The questions head office answered repeatedly, resolved automatically from the platform's own data, with anything novel escalated with context attached.

The variation argument#

The technical work was straightforward. Deciding what franchisees were allowed to configure was not, and it took longer than the migration.

We separated statutory and structural differences — tax, local pricing, state curriculum requirements — which got proper configuration, from operational preferences accumulated because someone once did it differently. The second group was retired, with notice and with help.

That conversation involved franchisees rather than being announced to them, which is why it held. Two centres pushed back hard and one of their objections turned out to be a genuine regional requirement we had misclassified.

What we would do differently#

We migrated the version consolidation as a single cutover per centre, coordinated by head office over six weeks. It worked, and it consumed far more of the client's operational attention than we had budgeted for.

A staged approach — running both versions in parallel per centre for a week, with a franchisee-controlled switch — would have cost slightly more engineering and removed almost all of the coordination burden. We underweighted the client-side effort because the technical migration was low risk, which is a mistake worth naming: a cutover that is easy for us is not automatically easy for them.

We now scope client operational load explicitly alongside engineering effort on any migration touching more than a handful of sites.

Where it went next#

The network moved to a support retainer covering the platform and infrastructure. It has since opened more centres than it had in total when we started, with no increase in head-office operations headcount, which was the actual objective.

Local marketing operations went live the following quarter — centrally run campaigns with per-centre targeting and controlled variation, described under Growth & Demand Generation.