Describe the tickets you need handled
Gather representative categories such as sign-in issues, new-device setup, printing, email and application access. Distinguish requests that require approval from faults that a technician can investigate immediately. Describe frequent problems without including passwords, private messages or sensitive customer data.
List applications and devices that users will ask about. An infrastructure help desk may not configure a specialized business application. Ask what is resolved directly, what goes to another provider and who keeps ownership during that handoff. Include personal-device and home-network boundaries if staff work remotely.
Define coverage and contact methods
Provide user time zones, working patterns and required contact channels. Ask whether users can call, submit a ticket or use a portal when email is unavailable. Clarify accessibility needs and how employees who cannot use the usual channel receive assistance.
Out-of-hours service may differ from daytime service. Find out whether it is staffed troubleshooting, on-call escalation or message-taking. If language or location requirements matter, ask providers to confirm them rather than assuming coverage. A proposal should say exactly which hours and services are contracted.
Read service levels precisely
A response target is not the same as a resolution target. Ask when the clock starts, what qualifies as a response and how waiting for a user, approval or vendor affects measurement. Define severity using business impact rather than letting every ticket be marked urgent.
Request examples of incident communication and escalation. A support agent should be able to explain the next action and expected update even when restoration timing is uncertain. Avoid treating a service-level agreement as a guarantee that all applications, devices or external vendors will remain available.
Protect account changes and remote support
Password resets and access requests are sensitive even when they appear routine. Ask how the help desk verifies identity, obtains manager approval and records changes. Describe the boundaries of remote-control sessions, including user visibility and technician access.
Decide which administrative actions require escalation and which can be completed from documented instructions. New-user and departure workflows should identify an authorized business owner. The provider should not infer access rights from whoever contacts the desk or from information contained in a user-editable profile.
Evaluate onboarding and improvement, not only ticket closure
An engagement may include a knowledge base, application-owner directory, device inventory and trial of escalation procedures. Ask how new support staff learn your environment and how instructions are kept current. A handoff without usable documentation can create repeated questioning and avoidable delays.
Compare per-user, per-ticket and minimum-volume models, including project work and on-site exclusions. Review reopen rates, recurring issues and user feedback in context rather than rewarding closure counts alone. Arrange access to relevant records and a clear transfer of open tickets if you change providers.
Before requesting proposals
Your preparation checklist
- Collect ticket categories, supported applications and device types.
- List time zones, working hours and accessible contact requirements.
- Define business-impact severity and authorized approvers.
- Identify vendor escalation contacts and knowledge-base owners.
Questions for prospective MSPs
- What counts as an initial response, and when does the clock pause?
- Who owns a ticket while another vendor investigates?
- How do you verify an account-reset request?
- What onboarding documentation and on-site services are included?