A turnkey brand deployment is the configuration of an existing operator platform for a new brand: the software, the back office and the integrations already exist, so the work is configuration, coordination and verification rather than development. The sequence is broadly fixed — the delivery model and scope are confirmed, a launch runbook is built, the brand is created in the back office, roles and permissions are set, the customer onboarding journey is configured, the brand is localised for its market, compliance and finance approvals are cleared, and a go-live sequence is run before the brand is handed to the team that will operate it.
This guide describes that sequence from the inside: what is configured at each stage, who has to sign what, and where launches usually slip. It is written for the coordinator, back-office administrator or operations lead who has been handed a target date, not for the executive deciding which platform to buy.
Why most guides on this topic do not answer the question
Search for how a new brand is launched on an operator platform and many of the results are supplier marketing pages. Those pages exist to persuade a company to buy a turnkey solution, so they describe the outcome — a brand, live, quickly — and skip the work that produces it. If you are the person who has to produce that outcome, that framing is of little use to you.
What "turnkey" means in practice
A turnkey deployment means the platform, its back office and its integrations already exist. You are configuring an instance of them for a new brand rather than building software. Your work is configuration, coordination and verification.
That distinction shapes the whole project. The critical path is rarely the platform. It is the external dependencies — corporate accounts, contracts, market approvals, payment method enablement, domains, communication infrastructure and content agreements — that must exist before configuration can be finalised or tested end to end. A team that spends week one in the back office and week six discovering an unsigned dependency will struggle to hold its date. A team that maps dependencies first is working on the right problem from the start.
Who is involved
- Delivery or project side — owns the schedule, the dependency register and the escalation path.
- Back-office configuration — creates the brand, sets locales, roles, customer journeys, promotional rules and reporting.
- Receiving operations team — the people who will run the brand after launch. They must be trained before go-live, not after it.
Step 1 — Confirm the delivery model and the real scope
Before anything is configured, write down what is included in the deployment and what is not. Turnkey agreements vary enormously in where the boundary sits: reporting depth, support hours, who administers customer accounts, who owns communication templates, which integrations are standard and which are custom work with their own lead time.
The output of this step is a one-page scope statement everyone has read. A frequent source of late disputes is not disagreement about quality but two teams holding different assumptions about who owned an item.
Step 2 — Build the launch runbook
A launch runbook is a single controlled document that lists every task required to take a brand live, in dependency order, with a named owner, a target date and a verification step for each item. It is the backbone of the whole project.
A working runbook normally contains:
- The scope statement and the delivery model.
- The external dependency register, with the earliest date each item can realistically land.
- Back-office configuration tasks, grouped by area.
- Localisation and market-setup items.
- Access and permission grants, with the approver for each.
- Test gates and sign-offs, stating who signs and what evidence they need.
- The go-live sequence, hour by hour, including the rollback position.
- The handover checklist for the operations team.
The point of a runbook is not documentation for its own sake. It is to make the critical path visible while there is still time to change it.
Step 3 — Create the brand in the back office
Brand creation is the first configuration milestone: the brand entity, its domains, its default locale and currency, its identity assets, its communication sender identities and its position in the reporting hierarchy. Reporting structure deserves attention early, because it is far harder to restructure once historical data exists behind it. Decide before launch how this brand rolls up alongside others for transaction reporting and performance review.
Step 4 — Configure roles and permissions before anyone gets access
Roles should be defined by job function, not by person. Start from the tasks each function must perform, grant the minimum permissions those tasks require, and treat anything that can move money, change customer records, alter promotional rules or export personal data as a permission needing a named approver and an audit trail.
Two practices save a great deal of trouble later: keep a documented list of who approved each role grant, and schedule a review of access immediately after launch, when temporary project access tends to become permanent by accident.
Step 5 — Configure customer onboarding and account management
This is the registration and account journey: which fields are captured, how identity is verified, what documentation is requested and when, how account states change, what limits and controls are available, communication preferences, and the tooling customer support will use daily. Configure it with the support team in the room. They are the ones who will live with every decision made here, and they usually spot the impractical ones immediately.
Step 6 — Localise the brand, and remember localisation is not translation
Platform localisation is the configuration of a brand so it behaves correctly in a specific market. Translated text is one layer of it. The rest includes locale and time-zone settings, currency and rounding behaviour, market-appropriate payment methods, jurisdiction-specific legal and terms content, date, address and name-format handling, right-to-left layout support where relevant, support channels and hours in the local language, and every automated message a customer receives.
A brand can be fully translated and still be unusable in its target market. Treat localisation as a configuration workstream with its own checklist and its own sign-off, not as a translation ticket.
Step 7 — Market-specific setup and compliance artefacts
Every market brings its own required documents, disclosures, record-keeping obligations and reporting formats. Identify who inside the business owns the compliance position — it is never the configuration team — and get the required text and settings confirmed in writing. Note which compliance artefacts must be reproducible on request after launch; those need a defined owner and storage location, not an inbox.
Step 8 — Promotional rules and finance approvals
Promotional mechanics need eligibility rules, exclusions, expiry behaviour, reporting visibility and a documented approval chain before anything is switched on. Finance should sign off on how promotional cost is recorded and reconciled. Testing a promotional rule after launch, on live customer accounts, is a bad way to discover an eligibility gap.
Step 9 — Go-live week and handover
Go-live week is a rehearsal followed by a performance. The rehearsal is a full walkthrough in a non-production environment against the runbook, with the receiving operations team performing the steps rather than watching them. The performance is the launch sequence itself: a defined order, a named decision-maker, a communication channel everyone is already in, an agreed rollback point, and a monitoring window afterwards.
Handover is the step commonly compressed, and compressing it is what turns a successful launch into a difficult first month. A real handover transfers the configuration record, the access list, known open items with owners, the escalation path, and the operational procedures the team will use daily. Until that transfer is accepted, the launch is not finished.
Where launches actually slip
- Dependencies mapped late, so the true critical path appears in the final weeks.
- Scope assumed rather than written down.
- Localisation treated as translation.
- Access granted informally during the project and never reviewed.
- The operations team trained after go-live instead of before it.
None of these are technical failures. They are coordination failures, which is why the role exists at all.
Learning this deliberately
Many people learn this sequence by being thrown into it once and reverse-engineering what went wrong afterwards. If you would rather see the whole shape of the work first — delivery models, runbooks, brand creation, roles and permissions, onboarding configuration, localisation, market setup, promotional approvals and handover — the Pronet Pro Certificate is a self-paced independent course covering exactly these nine areas, ending in a dated completion record. It is an independent training product, not an accredited qualification and not a supplier credential, and it is worth being clear about that before you decide whether it fits what you need.
If the work that interests you begins after the launch rather than before it — terminal sessions, end-of-day reconciliation and the written shift handover that transfers accountability for a counter — the BC Pro Certificate covers that side instead. A side-by-side comparison of all five programmes is at /guides/which-certificate.