Client offer
What the client believes they are buying, the language promised, and work represented as included.
Operable onboarding Démarrage exploitable
Launch starts when everyone knows what to bring.
Onboarding turns a sold offer into an operable service. It does not follow a promised number of days; it closes a sequence of verifiable decisions.
Inputs to prepare Entrées à préparer
Technical context
Environments, users, tools, authorized access, and constraints already known.
Contacts and decisions
People who approve changes, receive risks, and speak with the client.
Working paths
Where requests arrive, where notes live, and how a declared urgent issue returns.
Five stages Cinq étapes
Align
Compare the sold offer with the delivery catalogue and name gaps.
Output: Service map and open-decision list.
Prepare
Gather useful context without copying secrets into the brief.
Output: Bilingual launch brief and contact matrix.
Validate
Walk a sample request, approval, and escalation through the named owners.
Output: Accepted workflow and ready return messages.
Activate
Open only the paths, access, and work that have actually been confirmed.
Output: Launch register with prerequisite status.
Observe
Review early loops for missing information or ambiguous expectations.
Output: Owned adjustment list without an invented performance grade.
Owner decisions Décisions et responsables
Client voice
Who drafts or approves client-visible messages?
Access
Who authorizes, creates, reviews, and removes each access path?
Exceptions
Who decides that a need becomes a project or new scope?
Languages
Which language serves the client, partner, and internal notes?
Onboarding exit criteria
- The offer and delivery catalogue tell the same story.
- Owners can explain their decisions without depending on one absent person.
- A test request can enter, be handled, return, and be found again.
- Required access is confirmed; unnecessary access is not opened.
- The first review cadence and its recipient are named.