Customer onboarding guide
Give a new client a clear path into managed service.
Agree on ownership, access and scope before rolling out agents or moving records. Build the operating baseline in stages, with an acceptance check for each handoff.
Practical evaluation guidance. Check current Dayrook scope and evidence.
On this page7 sections
Illustrative decision map · not a product screenshot
Establish a trustworthy baseline before daily operations begin.
Workspace security, customer boundaries, endpoint identity, policies, and first proof points are completed in a deliberate order.
- 01Prepare
- 02Secure
- 03Map
- 04Enroll
- 05Prove
In brief
What to carry into the workflow
- Turn the signed service scope into an owned onboarding ledger before requesting access or changing the client environment.
- Discover, import, and deploy in controlled waves while existing tools remain available for validation.
- Close onboarding with reconciled coverage, tested service paths, documented exceptions, and customer acceptance.
Turn signed scope into an onboarding ledger
Begin with the service agreement and the people accountable for delivering it. Record each client entity, site, user group, device population, critical service, provider, support window, escalation contact, data obligation, included outcome, and explicit exclusion in one reviewable onboarding record.
Translate the agreement into acceptance criteria before technical work starts. The MSP and client should know who owns each workstream, which evidence will prove completion, which dependencies can stop the sequence, and which residual risks can be accepted only by an authorized person.
- Confirm the signed scope, authorized client contacts, MSP delivery owner, technical owners, and escalation path.
- List sites, users, devices, servers, networks, cloud tenants, SaaS workloads, applications, and critical business services in scope.
- Record service targets, maintenance windows, communication milestones, dependencies, exclusions, and acceptance owners.
- Separate must-pass launch criteria from deferred improvement work so incomplete items remain visible.
Confirm authority, access, and data placement
Do not request credentials, deploy agents, connect a provider, import records, or change client policy until the client has confirmed the MSP's authority for that exact scope. Assign named owners for identity, endpoint, network, cloud, backup, security, billing, and customer communication work.
Choose the documented US or EU client-data placement before customer data is created. Use least-privilege access, MFA, scoped provider consent, secret references, and an approved handoff method; credentials and unrestricted client data do not belong in onboarding notes or tickets.
- Document client authorization for discovery, access, deployment, migration, testing, and any planned change.
- Confirm tenant and customer boundaries, selected data region, role assignments, MFA, approval rules, and separation of duties.
- Inventory provider consents, service accounts, certificates, API access, network paths, and expiry or revocation owners.
- Define stop conditions and the recovery contact before any action that could affect production service.
Discover current state before importing or deploying
Compare the signed scope with authoritative source APIs, supplied exports, live infrastructure discovery, and client interviews. Preserve source, observation time, counts, gaps, unsupported fields, and confidence rather than turning incomplete evidence into an assumed inventory.
Where a supported migration is appropriate, test the source connection, generate a source-bound plan, review mappings and target prerequisites, and inspect a dry run before approving an import. Ambiguous records and destructive conflicts remain blockers until an owner resolves them.
- Reconcile expected and discovered clients, sites, users, devices, services, policies, tickets, credentials, backup sets, and integrations.
- Record stale records, duplicates, unsupported fields, missing authority, mapping conflicts, target prerequisites, and security concerns.
- Approve only the exact source snapshot, mapping, object set, region, and sequence intended for import.
- Keep the source platform and original evidence available until imported records are verified in the target views.
Establish coverage in controlled waves
Start with a representative pilot that can prove enrollment, inventory, monitoring, alert routing, ticket ownership, policy, remote access, backup, reporting, and failure handling without exposing the whole client environment to an unverified change. Expand only after the pilot's acceptance checks pass.
Run new and existing management tools in parallel where coexistence is supported. Removing an old agent, disabling a source integration, or changing a production policy is a separate customer-approved cutover step after replacement coverage and the required recovery state have been verified.
- Deploy agents and collectors in approved waves and reconcile expected devices, networks, identities, sites, and first check-ins.
- Assign only reviewed monitoring, patch, automation, remote-access, backup, notification, service-queue, and escalation policies.
- Test an alert-to-ticket path, a permitted remote or endpoint action, backup verification, and a supported restore path with recorded results.
- Keep denied, failed, deferred, offline, unsupported, and partially completed states visible with an owner and next action.
Reconcile the service and obtain acceptance
Onboarding is complete only when the agreed operating baseline is visible and testable. Reconcile source and target counts, review coverage and exceptions, confirm contacts and service paths, and give the client the documentation, reporting, access, training, and residual-risk record promised in the scope.
Record acceptance by workstream instead of hiding unfinished work behind a single completion flag. Deferred items need an owner, due date, impact, interim control, and next review; rejected or failed checks return to the relevant onboarding step.
- Reconcile users, devices, sites, agents, collectors, cloud tenants, integrations, policies, protection jobs, tickets, and reports against scope.
- Confirm support contacts, escalation, maintenance, communication, customer portal access, reports, documentation, and operator training.
- Review restore readiness, access control, open security findings, exclusions, residual risks, failed checks, and deferred work.
- Capture customer acceptance, cutover approval where applicable, retirement decisions, and the date and owner of the next service review.
Try this in your evaluation
Pilot acceptance before cutover
Illustrative scenario · use it to plan a test, not as proof of a result
Fictional pilot: plan 10 company records; reconcile 9 matches and 1 duplicate exception. The owner withholds go-live until the duplicate is resolved and a sample workflow passes.
Define a successful result
Check these support boundaries
- Source system and supported import objects
- Region, authority and secure credential handoff
- Counts, duplicates, history and exclusions
- Owners, reconciliation and retirement gates
Acceptance record
Record source count, imported count, exceptions, evidence, owner, dependencies, acceptance decision and deferred items. Keep credentials outside worksheets and inquiry messages.
Limits to resolve
The current migration directory evidences company-record scope where stated, not universal ticket/history import. Agent coexistence and deployment combinations require a release-specific pilot.
Questions, answered
Questions to resolve before your next step.
What should be collected before kickoff?
Start with signed scope, authorized contacts, current tools, client and site inventory, critical services, data obligations, access owners, and success criteria.
Should legacy tools be removed during onboarding?
Only after replacement coverage and imported state are verified and the customer approves the documented retirement step.
What proves onboarding is complete?
The agreed inventory, workflows, policies, protection, reporting, access, training, exceptions, and customer acceptance all have reviewable evidence.