IT Helpdesk vendor due diligence: 12 evidence items to verify before signing a contract
Three vendors made it to the final round. Their price quotes do not differ significantly. All three offer Service Level Agreements (SLAs), ticketing systems, multi-tiered technical teams, and commitments to support during incidents.
On paper, it is difficult to spot the differences.
The differences typically only emerge when businesses start digging deeper: Who actually receives the tickets? Who steps in when the primary engineer is on leave? From what point is the SLA calculated? Are administrator privileges granted individually or shared? In the event of an after-hours incident, who retains responsibility for the ticket until the issue is resolved?
At that point, the selection process is no longer about reading proposals, but shifts to verifying how the service will operate in practice. That is the role of IT Helpdesk vendor due diligence.
Below are 12 categories of evidence that businesses can use to verify vendor capabilities before proceeding to a contract.
How does IT Helpdesk due diligence differ from a vendor selection checklist?
A vendor selection checklist typically helps businesses determine what capabilities a vendor possesses. Due diligence goes a step further: verifying whether those capabilities actually exist and can operate within the service scope the business is about to purchase.
A simple distinction can be made:
Vendor claims | Due diligence must verify |
Has a multi-tiered technical team | Who belongs to L1, L2, and L3? When are tickets escalated? |
Has a ticketing system | What data does the ticket record? Who owns the ticket after escalation? |
Has SLAs | From what point is the SLA calculated? How do response and resolution differ? |
Strict security | How are administrative privileges granted, logged, and revoked? |
Has backup staff | Who replaces the primary engineer when they are on leave or overloaded? |
Has experience | Are there references or similar deployment scopes to verify? |
Prior to this step, businesses should clearly define what items are included in the IT Helpdesk scope and which tasks must be separated. If the scope is unclear, it is very difficult for a business to evaluate whether a vendor truly meets the requirements or merely presents a broad list of capabilities.
In other words, scope answers "what the vendor must do"; due diligence answers "what evidence proves the vendor is capable of doing it."
1–2. Verifying the team that actually operates the service
A proposal may list dozens of engineers or numerous technical certifications. However, the company's total headcount does not necessarily reflect the resources that will directly serve the contract.
1. L1/L2/L3 structure and Escalation Matrix
Businesses should request the vendor to describe or provide an organizational diagram showing:
Which team handles initial requests.
Which types of tickets are handled at L1.
When tickets must be escalated to L2 or L3.
Who has authorization to make changes on the system.
Which scenarios require customer approval.
When a ticket is transferred to another team, who retains tracking responsibility.
What needs to be verified is not the labels L1/L2/L3, but the boundaries of responsibility and authority between levels.
A vendor with a clear escalation process can typically explain specifically what happens from the moment a user submits a request to when the ticket is closed, rather than simply stating that "complex incidents will be escalated to experts."
2. Qualifications of Key Roles
It is not necessary to request CVs for all personnel. Businesses should focus on roles that directly impact the service, such as:
Service Delivery Manager.
Team Lead.
Escalation engineer.
On-site engineer (if the contract includes on-site support).
Specialists in charge of specific systems.
If the vendor relies heavily on certifications, it is necessary to check whether those certifications are directly relevant to the service scope.
A useful question to ask is:
"If the engineer assigned to our account goes on leave for a week, who can take over without disrupting support?"
The answer will help assess whether the vendor operates based on an interchangeable team or depends on a few individuals.
3–4. Requiring the vendor to prove processes through actual tickets and reports
"Having an IT Helpdesk process" is a claim that is difficult to verify by looking solely at diagrams in a proposal. Ticketing systems and operational reports generally give businesses a more concrete view.
3. Live workflow demo of an actual ticket
Businesses can ask the vendor to demonstrate a simulated ticket from end to end.
For example: an employee cannot log into Microsoft 365.
Key aspects to observe:
Which channel receives the request.
Whether the ticket is categorized automatically or manually.
What criteria determine priority.
Who assumes responsibility for resolution.
When the ticket is escalated.
Whether communications and actions are logged.
How the user confirms resolution.
What conditions allow the ticket to be closed.
The goal is not to evaluate whether the software interface is sleek or modern, but to verify whether the process is capable of creating accountability and traceability.
4. Sample periodic service report
Businesses should request a sample report with anonymized customer data.
A useful IT Helpdesk report should reflect:
Volume of incoming tickets.
Classification by priority or issue group.
Response time.
Resolution time.
SLA compliance rate.
Backlog tickets.
Reopened tickets.
Recurring issues.
Incidents requiring escalation.
Improvement recommendations, if any.
If a vendor only provides the total number of closed tickets without showing resolution times, backlog status, or root causes of recurring tickets, it will be difficult for the business to evaluate service quality once the contract begins.
5 – 6. SLA: Do not just check numbers, check how they are measured
One of the common mistakes when evaluating IT Helpdesk is looking at a figure like "response within 15 minutes" and treating it as proof of good service.
SLAs must be read in full context.
ISO/IEC 20000-1:2018 is currently the ISO standard for service management system requirements, emphasizing how organizations establish, implement, maintain, and improve a service management system rather than relying solely on a single time metric.
5. SLA matrix
The vendor should be able to provide an SLA matrix displaying at least:
How priority levels are determined.
Response target.
Resolution target or restoration target, if applicable.
Service coverage hours.
Escalation conditions.
Scenarios where SLA clock is paused.
Customer responsibilities during the resolution process.
How third-party-dependent tickets are handled.
It is particularly necessary to distinguish between response time and resolution time. A vendor responding within 15 minutes does not mean the incident will be resolved within 15 minutes.
6. Sample data proving how SLAs are measured
If the vendor states they can report monthly SLAs, request to see a sample report or dashboard.
Questions to ask include:
Does SLA measurement start when the email is sent or when the ticket is created?
Does the SLA clock continue ticking while waiting for a user response?
How are tickets referred to third-party internet or software providers calculated?
Do reopened tickets impact resolution metrics?
Beyond SLA achievement rates, does the vendor analyze reasons for SLA breaches?
Due diligence is not intended to find the vendor with the "prettiest SLA," but to determine whether metrics are defined clearly enough for both parties to understand and verify.
7–8. Security: Verifying how vendors manage access privileges
IT Helpdesk may require access privileges to user endpoints, Microsoft 365 accounts, administrative systems, Virtual Private Networks (VPNs), or other enterprise platforms.
Therefore, security should not end with the vendor signing a Non-Disclosure Agreement (NDA).
ISO/IEC 27001:2022 is the current ISO version for information security management systems, placing risk governance, policies, and security controls within a structured management system.
In IT Helpdesk due diligence, businesses should translate security principles into specific operational questions.
7. Privilege provisioning, modification, and revocation process
Businesses can request the vendor to describe:
Who approves access permissions.
Whether engineers use individual or shared accounts.
Whether Multi-Factor Authentication (MFA) is required.
Whether admin privileges are granted permanently or on-demand.
When access is revoked when an engineer departs or changes projects.
Who performs periodic privilege reviews.
A major red flag is when a vendor requests a shared administrator account for multiple engineers without a mechanism to trace who performed which action.
8. Evidence of logging, data handling, and operational security
Depending on the scope of the contract, businesses may verify:
NDA and confidentiality obligations.
Remote access policies.
Credential storage policies.
Administrative activity logging.
Customer data handling regulations.
How the vendor manages devices or tools used to access systems.
Not every business needs to request a massive set of security documents. The level of verification should be proportional to the data, systems, and access privileges the vendor will be granted.
9–10. Business Continuity Plan (BCP): What happens when vendor personnel or tools are unavailable?
A Helpdesk may function well under normal conditions, but encounter issues when key engineers leave, ticket volume spikes, or after-hours incidents occur.
This is when businesses need to test the operational continuity of the service model.
9. Backup staffing and handover plan
The vendor should be able to explain:
How many personnel can replace the primary engineer.
Where customer documentation is stored.
How system knowledge is handed over.
How active tickets are transitioned.
Who is responsible when workload spikes.
If all customer information resides solely in the head of a single engineer, the business still faces a single point of failure despite hiring a company with numerous employees.
10. Major Incident procedure and after-hours escalation
Consider a scenario:
7:00 PM, multiple users suddenly cannot access a critical system. What happens next?
The vendor must be able to describe:
How users initiate contact.
Who receives the request.
Who has authorization to raise the priority level.
Who gets called when L1 cannot resolve it.
When management from both sides is notified.
What other vendors need to be involved.
Who retains ownership of the incident.
If the business already has an internal IT team, the collaboration model must also clearly define which side handles L1, which side manages systems, and which side holds change authority. The article on Should you still outsource your IT Helpdesk? will provide more detailed analyses of the co-managed IT model and the division of responsibilities.
11–12. References and commercial dossiers: Verifying contract execution capabilities
The final two evidence items do not reside directly within the ticketing system, but help businesses verify whether the vendor possesses adequate foundation to fulfill commitments.
11. Reference clients or similar scenarios
A useful reference does not necessarily have to come from a business in the same industry. More important is the degree of similarity in:
User headcount.
Number of locations.
Remote or on-site support.
Support hours.
Systems in operation.
SLA requirements.
Escalation complexity.
When conducting a reference check, do not simply ask "Is the service good?"
More specific questions include:
How does the vendor respond when tickets are delayed?
Is management escalation frequently required?
Are periodic reports transparent enough?
When replacing an engineer, how does the handover process go?
Does the vendor proactively identify recurring issues or merely close individual tickets?
12. Legal dossiers, contracts, and handover mechanisms
Before signing a contract, businesses should verify the contracting legal entity and inspect terms directly affecting operational capabilities.
Key points to clarify:
Scope of responsibilities of both parties.
Whether subcontractors are utilized.
Who owns operational documentation.
How access privileges must be revoked when the contract ends.
What format ticket data and history are handed over in.
Transition support timeframe when switching to a new vendor.
Obligations remaining in force post-contract termination.
Termination clauses are often overlooked when a business begins a new partnership. Yet this is crucial evidence showing whether the vendor has considered the entire service lifecycle, not just the sales stage.
12-Evidence Checklist for an IT Helpdesk "Evidence Room"
Businesses can consolidate due diligence into a simple evidence room:
No. | Evidence to verify | Key question |
1 | L1/L2/L3 structure and escalation matrix | Who handles requests and when must they be escalated? |
2 | Capabilities of key roles | Who actually serves the contract? |
3 | Ticket workflow demo | How does a request travel through the system? |
4 | Sample service report | What data will the business see each month? |
5 | SLA matrix | How are priority, response, and resolution defined? |
6 | Sample SLA report | How does the vendor measure and prove SLAs? |
7 | Access management process | Who is authorized to access which systems? |
8 | Logging and data-handling evidence | Are administrative activities controlled and traceable? |
9 | Backup staffing plan | Who replaces personnel when they are unavailable? |
10 | Major incident procedure | How are major incidents escalated? |
11 | Comparable references | Has the vendor operated in a similar environment? |
12 | Legal/exit/handover documentation | When starting or terminating the contract, how are responsibilities transitioned? |
Not every vendor needs to build a complex data room. For small businesses and basic Helpdesk scopes, many evidence items can be verified through a technical meeting, ticketing demo, and contract documentation.
Conversely, if the vendor will be granted administrative access to critical systems, support multiple locations, or handle after-hours responsibilities, the depth of due diligence should be greater.
A good due diligence process turns every commitment into a verifiable question:
Who performs it?
Which process is used?
Where does the system log requests?
How are metrics measured?
And what evidence proves it is actually operating?
The 12 evidence categories regarding staffing, ticketing, reporting, Service Level Agreements (SLAs), access privileges, security, Business Continuity Plans (BCPs), references, and contractual obligations help businesses bridge the gap between what vendors present during the sales phase and what actually occurs after service initiation.
If a business has defined its support scope and is evaluating outsourcing options, it can refer to IPSIP Vietnam's IT Helpdesk services to discuss scope, Remote/On-site models, SLAs, and operational requirements prior to receiving a service proposal.
References:
ISO/IEC 20000-1:2018 – Information technology – Service management – Part 1: Service management system requirements
ISO/IEC 27001:2022 – Information security management systems
Comments