Managing Client User Starter Requests in an MSP | 4KM Tech

Updated 27 August 2026

A new employee can need several technology services before their first working day, but an MSP should not build accounts from a vague message saying that somebody is starting. A structured starter request helps the provider confirm authority, required services and timing while keeping the client's own onboarding responsibilities distinct.

Use an agreed request route

Ask clients to submit starter information through the MSP's approved service channel rather than relying on messages to individual technicians. This creates a traceable request and reduces the chance that important onboarding work remains in somebody's personal inbox.

Confirm the requester is authorised

Follow the provider's established client-authorisation process before creating or changing access. A convincing email or urgent phone call should not replace whatever approval controls the MSP and client have agreed.

Collect only the information needed for the setup

Identify the user's relevant business details, start timing and required technology services without turning the IT ticket into a duplicate HR record. The client remains responsible for deciding the person's role and access requirements.

Separate standard access from exceptions

If the client has an agreed baseline for a type of user, apply it through the normal process. Requests for additional privileges or unusual systems should be made explicit and approved appropriately rather than copied from another employee without review.

Coordinate account and device readiness

A user may need both service accounts and physical equipment. Keep these workstreams linked to the same starter request so the MSP can see whether one part is ready while another remains outstanding. Do not mark the onboarding complete simply because an account exists.

Manage lead time realistically

Late starter requests can create pressure for immediate action, especially when equipment must be sourced or third-party services are involved. Give the client a factual status and prioritise within the agreed support process rather than bypassing security or quality checks to meet an unsupported deadline.

Record what was provisioned

Update the relevant service or asset records when work is completed. Clear documentation helps later support and gives the MSP a reliable basis when the client eventually requests role changes or offboarding.

Close with a defined handover

Confirm the technical setup through the agreed client route and handle any initial credentials or activation steps using the provider's approved security process. The client should know what is ready, what remains their responsibility and what outstanding item, if any, still needs action.

Turn a starter request into an approved service plan

The original article begins by warning MSPs against creating accounts from a vague or unauthorised message. Put that into practice with a request that identifies the client, authorised manager, intended start date, job function, business location and services genuinely needed. Keep sensitive employment records in the client's own HR systems; the service desk needs enough information to provision technology, not a copy of every personal document.

Confirm the submission route and approval against current client contact records. An urgent phone call or a message apparently from a senior colleague should not override agreed identity and authorisation checks. If approval is missing, record the outstanding decision, responsible client contact and next review rather than creating broad access while waiting.

Apply a standard role profile without blind copying

Where a client uses agreed access templates, identify the version and business owner of the profile. Match it to the new person's actual responsibilities before requesting accounts and licences. Permissions inherited from a predecessor may include historic exceptions that are inappropriate for a new employee. Treat elevated administration, confidential records and finance functions as separately approved needs.

Record which systems rely on directory groups and which require distinct supplier-side provisioning. A successful main-account creation does not confirm that specialist applications are ready.

Coordinate identity, licences and equipment

Plan the technical tasks in a logical order: approved identity creation, licence availability, application enrolment, device allocation and required security configuration. Note any lead times for new equipment, certificates, third-party approvals or location-specific accessories. Assign a named owner to each dependency so a blocked item does not disappear inside a single open ticket.

Check managed-device enrolment, approved encryption, updates and endpoint protection through the organisation's supported tooling. Use approved onboarding and authentication routes; do not send passwords or recovery codes in ordinary ticket updates.

Account for remote and first-day working needs

Ask the client whether the starter needs office connectivity, supported home access, communications, shared files or specialist peripherals. Translate those needs into approved services, not speculative convenience access. Arrange any verification step that requires the employee's participation, such as enrolment of their own authentication factor.

Document what can be tested before the person arrives and what needs their confirmation. A staged account may exist without proving that a user can complete a business-critical task.

Handle short-notice requests safely

Late requests need a factual assessment of what is possible by the stated date. Separate essential access from enhancements or equipment that may require procurement. If the client authorises temporary arrangements, record the constraints, expiry and review owner. Avoid sharing another user's login or weakening authentication merely to meet an administrative deadline.

Where a supplier cannot confirm licence or device availability, provide a clear status and next checkpoint. A promise based on an unverified shipment or entitlement creates unnecessary first-day disruption.

Use a practical acceptance checklist

Confirm the intended account state and role permissions, that the required device is actually assigned, and that the essential applications can be accessed through approved methods. For specialist services, ask the business owner or starter to verify a representative task. Record any unresolved issues with support references and named owners instead of ticking the entire joiner request complete.

Ensure the client understands which steps remain theirs, such as role-specific training, policy acknowledgement or approval to access particular business records. An MSP should not silently assume those responsibilities.

Preserve a reliable record for later support

At closure, document the approved request, systems provisioned, equipment assignment, exceptions and acceptance point in the appropriate operational records. Keep the access and asset entries maintainable as roles change. This gives the MSP a basis for future access review and offboarding without collecting unrelated personal details.

Review starter cases that repeatedly miss licences, approvals or specialist equipment and improve the client request template at that exact point. The objective continues ART1's theme: a legitimate, traceable request should become usable technology with clear responsibility, not merely a newly created account.