Before requesting after-hours service desk proposals, decide what needs to happen when a user contacts support. Is the provider expected to acknowledge the request, resolve an agreed set of issues, or escalate to your team? During which hours, and for which systems?
Put those requirements in a short document and give the same version to each bidder. The checklist below covers the details needed to compare scope and identify questions that still need an answer.
Why an answered call is not a resolved incident
Define response and resolution separately. Ask each bidder what starts and stops the relevant clock, which hours count, and how escalations or dependencies affect the target.
For example, a response target might measure acknowledgement by a support person, while a resolution target uses agreed criteria for completing the incident. Check whether an automated receipt counts as a response and whether restoring service with a workaround counts as resolution. Do not assume different proposals use the same definitions.
A provider may respond overnight but need your administrator or another vendor to complete the work. If that would not meet your coverage needs, identify the necessary access, authority and supporting services before agreeing the scope.
Coverage is not the same as monitoring or field response
Three different things get lumped under “after-hours support.” Separate them in your document so each bidder prices what you actually asked for.
- Service desk coverage is people answering users: password resets, access requests, application problems, “my laptop will not connect.” It is user-facing and ticket-driven.
- Security monitoring and response involves reviewing security alerts and taking or recommending action within an agreed remit. It needs defined security responsibilities; do not assume a service desk contract includes it.
- Field response is someone physically arriving at a location to swap hardware, restart equipment that has no remote path, or work with a local vendor. It has travel time, site access requirements, and a very different cost structure.
If you need all three, request an explicit scope for each, whether the provider bundles them or prices them separately. If a service is excluded, record who will supply it and how the handoff works.
The requirements checklist
Work through each item and write down your answer. Blank fields are fine if you genuinely do not know yet. Mark them as open questions and ask bidders how they would handle them.
1. Hours and time zones
State the exact after-hours window in your primary time zone, and every other time zone where users work. “After hours” for a Minnesota headquarters with a European sales office is a different service than “after hours” for a single Twin Cities site. Note holidays and whether your definition of a holiday matches the provider’s.
2. Users and sites
How many people can contact the desk, and where are they? List each site with its operating hours. Include available ticket volumes by time of day, site and issue type. If you lack that history, identify the estimates so bidders can state their assumptions.
3. Contact channels
Phone, email, chat, a portal, a Teams app, or all of them. Say which channels must be staffed live overnight and which can be queued for the morning. If users are expected to use your existing ticketing tool, say so, and ask how the provider will work inside it or integrate with it.
4. Severity definitions
Define priority levels in business terms, with an example for each. State who assigns and can change a priority: the user, the agent or an agreed rule. If you already have definitions in your internal tooling, attach them and ask bidders to identify differences from their own model.
5. Response versus resolution targets
For each severity level, state the response time you expect and, separately, whether you expect the provider to resolve or to escalate. Be explicit about what the provider is authorized to resolve without you. Ask bidders to confirm targets per level rather than quoting one headline number.
6. Escalation authority
Define which roles the provider contacts, in what order, and for which events. Keep current names and contact details in the operational contact list. Agree fallback contacts, permitted actions and limits when the primary contact cannot be reached, including who owns unresolved incidents during that period.
7. Remote and on-site boundaries
State what the provider is expected to handle remotely and what they are not. If on-site work after hours is required at any location, say which locations, how access works, and who the local contact is. If on-site work is out of scope, say that plainly so no bidder assumes it.
8. Vendor handoffs
List the third parties the desk may need to contact overnight: your ISP, your phone system vendor, your line-of-business application vendors, a facilities contractor. State whether the provider is expected to open tickets with those vendors on your behalf and whether they have authority to do so. Attach a contact list if you have one.
9. Security incidents
Describe what happens when an after-hours ticket looks like a security event. A user reporting a suspicious email, a login from an unexpected country, a ransomware note on a screen. Who does the desk notify, what are they allowed to do (disable an account, isolate a device), and where does the handoff to a security team or SOC happen? If you have no SOC, say so. It changes what you are buying.
10. Reporting
Say what you want to see and how often. Ticket volume by hour and site, first-contact resolution, response and resolution against targets, escalations by reason, and repeat issues. Ask whether reporting comes from the provider’s system, yours, or both, and whether you get access to the raw ticket data.
11. Onboarding
State what you can hand over: documentation, a knowledge base, an asset list, standard procedures, admin access. Ask bidders how long they need before overnight coverage starts, what they need from you, and how they handle the first weeks when they know the least about your environment.
12. Exclusions
Ask every bidder to list what is excluded from the quoted service. Compare those lists alongside the price, then identify any additional services or internal effort needed to cover the excluded work.
How to use the document once it exists
Send the same requirements to every provider. Ask each to respond section by section, including the sections they cannot meet. A provider who says “we do not do on-site work overnight, here is how we would handle it instead” is giving you more useful information than one who says yes to everything.
Build a comparison table with one row per requirement and one column per bidder. Use written responses and ask for clarification where an answer is missing. Differences in scope can help explain a price difference, but also compare staffing assumptions, service levels and exclusions.
If you have an internal team, add a column for its retained work. After-hours coverage can be part of a co-managed arrangement. State which duties stay internal during each coverage window rather than assuming that “after hours” transfers all responsibility.
Discuss after-hours support with Virteva
Virteva provides a 24/7 IT service desk using ServiceNow. Ask which coverage, request types and escalation arrangements are available for your organization. The checklist describes requirements to evaluate, not a list of services automatically included in a Virteva engagement.
If you are earlier in the decision and still working out whether you need a help desk or a full service desk, this comparison covers the difference.
Frequently asked questions
How much detail do bidders really need? Start with user count, sites and hours, supported systems, channels, priority definitions and targets, and exclusions. Include ticket history and dependencies where available. Ask bidders to identify any missing information and pricing assumptions.
Should we specify our current ticketing tool as a requirement? Specify it as a fact, and ask how each bidder would work with it. Confirm the access, integration, reporting and associated costs in the proposal rather than leaving them for onboarding.
What if we cannot define severity levels yet? Ask each bidder for their standard definitions and use the requirements process to choose one. Just make sure the version in the contract is the version your users and your internal team will actually use.
Next step
To discuss service desk coverage, contact Virteva with your operating hours, supported locations and the work you want help handling. Include any requirements you have already documented.
