The contract is signed. Sales considers the customer won; operations does not yet have a working customer. This gap creates the familiar email loops: missing master data, unknown contacts, unapproved access and a kickoff where prerequisites are discussed for the first time
Day 0: the starting event
Onboarding does not begin with the first checklist. It begins with an unambiguous event, such as contract approval or a confirmed order. That event creates an onboarding case containing the customer, product, accountable person, target date and rule version
The case imports only verified data. Free text from a CRM does not become a binding delivery address. Uncertain information appears as an open confirmation so the customer can correct it
Day 1: make dependencies visible
Tasks are not a flat list. Credentials can be sent only after an administrator has been named. Technical setup can start only after the domain and security contact are confirmed. The kickoff makes sense once its required information is available
A directed workflow shows those dependencies. If a prerequisite arrives late, the system recalculates affected dates or flags the conflict. It does not silently move everything backwards
Day 3: the right person sees the right task
The customer sees their own outstanding items and overall progress in plain language. Internal teams see their work, risks and blocks. Confidential commercial data is not automatically visible to technical contacts. One organisation can contain several sites and roles
Invitations expire and can be revoked. If the original administrator leaves, there is a controlled transfer. Shared accounts such as customer_admin make accountability impossible and have no place in a new portal
Week 1: documents become decisions
A signed contract, technical specification and logo are not the same upload. Every document type has a purpose, reviewer, version and retention rule. If a file is rejected, the customer receives a specific reason and can submit a new version
Automated text recognition may suggest fields, but critical contract values are confirmed. The original, extracted suggestion and reviewed value remain distinct
Notifications with restraint
Not every completed task needs an email to everybody. Immediate messages suit blocks and security questions. A daily summary suits ordinary progress. Reminders and escalation follow the owner, deadline and impact
The portal remains the authoritative status view. Email contains a notice and secure link, not the complete confidential record. Replies to an unattended sender address must not disappear; they should either be processed or clearly rejected
Transition into normal operations
Onboarding is complete when defined operating conditions are met, not when every optional task is green. Those conditions may include active users, a confirmed support route, successful data transfer and acceptance. Remaining items enter normal operations with an owner and deadline
Completion generates a concise handover: current contacts, purchased services, relevant decisions and known exceptions. The customer portal receives only data that will continue to be maintained
Measures of a healthy introduction
- time from contract to the first usable outcome
- waiting time by dependency and responsible party
- number of master data corrections after submission
- questions about information already provided
- onboardings using an exceptional approval or manual workaround
A short overall duration is not automatically good if risks were bypassed. It matters more whether delays became visible early and were handled correctly
A customer portal can support the later service relationship. The onboarding portal concentrates on the one time transition from commitment to a working relationship. It does not replace every email. It stops the truth about that transition being scattered across personal inboxes