A new employee's first day can expose gaps across several IT processes at once. The device may be ready while application access is still waiting for approval, or an account may exist without the role-specific tools needed for productive work. For a small MSP, the challenge is to coordinate the technical work without deciding business permissions on the client's behalf. A useful readiness process starts from confirmed requirements and keeps unresolved dependencies visible before the start date.
Work from an authorised starter request
Use the client's established request and approval route to confirm the person's identity, start timing, role and relevant working arrangements. Avoid building access from an informal message that lacks the necessary business authority. If important details are missing, record the dependency rather than guessing from another employee's setup.
Separate standard provision from role-specific access
A baseline device and account configuration may apply widely, while finance, administration, development or other specialist permissions need additional approval. Make that distinction visible. Copying an existing user's permissions can reproduce outdated or excessive access and may not reflect the new starter's actual responsibilities.
Coordinate hardware with the real working location
Confirm where the person will work and which approved peripherals, connectivity arrangements or delivery steps are genuinely required. A device marked as prepared in the MSP's system is not operationally ready if it is still in transit or lacks something essential to the user's working environment.
Track application dependencies individually
Some services may be provisioned directly by the MSP, while others depend on client owners or external suppliers. Record the current state of material dependencies and who owns each action. This prevents a single unresolved licence or approval from being hidden behind a general 'setup in progress' status.
Handle credentials through controlled channels
Use the organisation's approved identity and credential procedures for initial access, authentication setup and any temporary information. Passwords, recovery secrets and other sensitive credentials should not be placed in ordinary ticket notes or general onboarding emails merely for convenience.
Test representative access before handover
Where the service model allows it, verify that the prepared device and relevant accounts reach the expected supported state without impersonating the user's business decisions. Specialist applications may require confirmation from an application owner. Record what was actually checked rather than declaring every part of the setup proven.
Give support a clear first-day handover
Before the starter begins, make outstanding non-blocking actions and known dependencies visible to the service desk. If a first-day ticket arrives, the technician should be able to distinguish a genuine fault from access that is still awaiting an authorised owner. A strong new-starter process therefore does more than create accounts: it aligns approved access, equipment, dependencies and support context so the MSP can respond from a known state.