The right provider isn't defined by 24/7 availability, but by how clearly it defines what it handles, and how well it hands things off once it hits its limit.
A blocking incident, mishandled because priorities weren’t clear: that’s the most common failure of a poorly scoped outsourced helpdesk, even before the question of technical skill comes up. Outsourcing your helpdesk means entrusting a specialised provider with the technical support given to users on software, hardware, or product usage issues. The central question isn’t just finding a provider available around the clock, it’s knowing precisely what you’re handing over, how far it goes, and how the handoff works when a case exceeds its scope. This guide covers the method for scoping that delegation, then the criteria for choosing the right provider.
Technical support is classically structured into three levels, increasing in complexity. Level 1 handles first contact: common questions, basic diagnostics, resolution using a knowledge base and scripts. The vast majority of requests stop at this level. Level 2 takes over when a problem falls outside standard cases: it draws on deeper technical expertise, advanced diagnostic tools, sometimes system log analysis. Level 3 is reserved for situations revealing a flaw in the product itself, or requiring intervention on code or infrastructure: it generally involves the teams who designed the product.
This distinction isn't a technical detail, it's the key to any outsourcing decision. Levels 1 and 2 delegate naturally to a specialised provider, as long as it has a solid knowledge base and a team trained on your product. Level 3, on the other hand, almost always stays in-house, because it requires access to infrastructure or code that few companies are willing to share. That doesn't mean it never gets outsourced: some providers develop, over time and on sufficiently documented products, enough expertise to handle part of level 3. But that requires a trust relationship and knowledge transfer built over several years, not from the first year of a contract.
For a decision-maker preparing an outsourcing plan, the right reflex is to clarify from the start how far the provider goes, and how the handoff to internal teams works when a ticket exceeds that limit. That handoff, more than advertised availability, is what determines the real quality of the setup.
Analyse the nature of your tickets. Before any provider search, look at the real breakdown of your requests: what proportion is level 1, what proportion already needs level 2 expertise, and how often a ticket escalates to level 3. This snapshot determines the realistic scope of outsourcing, and prevents signing a contract calibrated on a rough estimate.
Define a priority matrix. Not every ticket deserves the same urgency. An incident that completely blocks use of the product doesn't call for the same response time as a minor usage question. Building this matrix before looking for a provider lets you negotiate realistic commitments, rather than accepting a generic grid that doesn't fit your business.
Prepare the knowledge transfer. A helpdesk provider doesn't guess your product. It needs a structured knowledge base, documented resolution scenarios, and access to the right diagnostic tools. The more thorough this preparation, the faster the provider ramps up, and the faster first-contact resolution improves.
Decide the scope of functional escalation. Functional escalation happens when a ticket needs expertise the current level doesn't have. Decide upfront who receives these escalations internally, within what timeframe, and with what information passed along, to avoid a customer having to repeat their problem every time they change contact.
The Service Level Agreement, or SLA, formalises the commitments between you and the provider: response time, resolution time, availability, procedure in case of breach. Many companies reduce it to a contractual formality. That's a mistake: the SLA is above all the exercise that forces you to clarify, before signing, what will otherwise stay vague.
A good SLA always distinguishes first-response time from full resolution time, and applies different rules depending on ticket priority. An incident that completely blocks use of the service doesn't call for the same treatment as a routine usage question. Without this distinction, a provider processes tickets in order of arrival rather than urgency, which can turn a critical incident into a crisis simply because it arrived after ten minor requests.
The metrics that come with a helpdesk SLA almost always come back to the same notions: first-contact resolution rate, which measures the share of requests resolved without transfer or callback, adherence to agreed timeframes, and the re-escalation rate, which reveals whether level 1 or 2 did its qualification job properly before passing a ticket on. These metrics need to be visible continuously, not reconstructed after the fact from a monthly report.
Real technical expertise, not just claimed. A provider that masters your type of product or sector ramps up faster and makes fewer diagnostic errors. Ask for concrete examples of technical cases similar to yours, not just a list of client references.
Clarity on the boundary between levels. A good provider knows precisely where its responsibility ends and how the handoff to your internal teams works for level 3. A provider that's vague on this boundary will waste the end customer's time, who'll have to repeat their problem at every transfer.
Quality of the knowledge base, and how it's kept updated. Technical support ages fast: a product evolves, new bugs appear, old solutions become obsolete. A provider that doesn't continuously update its knowledge base reproduces errors already solved elsewhere.
Availability calibrated to your business, not standardised. 24/7 isn't systematically necessary. A B2B SaaS provider whose users work office hours doesn't have the same need as a consumer platform used evenings and weekends. Calibrating availability to actual usage avoids paying for a service no one would call on at 3am.
Reporting transparency. You need to see, in real time, first-contact resolution rate, adherence to timeframes, and escalation rate, without having to ask at every steering committee.
| Criterion | Why it matters | Question to ask the provider |
|---|---|---|
| Real technical expertise | Reduces diagnostic errors and resolution time | Can you show me a technical case comparable to mine? |
| Boundary between levels | Prevents poorly coordinated handoffs to your internal teams | How does escalation to level 3 work? |
| Knowledge base | Guarantees reliable answers over time | How often is your knowledge base updated? |
| Calibrated availability | Avoids paying for a service disproportionate to actual use | Can you adapt your hours to my real demand peaks? |
| Reporting transparency | Lets you steer without waiting for a monthly report | What metrics are available in real time on your platform? |
Many outsourcing pitches focus on cost reduction and round-the-clock availability. Those are real benefits, but they guarantee nothing if coordination between levels hasn't been thought through. A well-functioning outsourced helpdesk is recognised by one simple sign: the end customer never perceives they've changed contact person, even when their case moves from level 1 to level 2.
That's exactly the logic Armatis applies to its technical support operations: teams trained on first-level contact, able to quickly resolve common issues, with rigorous handling of the most complex requests and clear orchestration between skilled agents and digital tools, rather than a stack of disconnected contact points.
In the energy sector for example, level 1 and 2 technical support covers topics as varied as using a consumption-tracking app or handling a smart-meter anomaly, with close coordination between support teams and internal technical teams for cases that exceed the contact centre's scope. This coordination, more than the technology used, makes the difference between support that reassures and support that adds frustration to an already irritating problem for the user.
This holds true across every technically demanding sector, not just energy. In banking or insurance, level 1 and 2 support handles app and customer-portal usage questions, while deeper anomalies, tied to a complex IT system and strong regulatory constraints, escalate to specialised teams. The principle stays the same: the boundary between levels must be documented before launch, not discovered at the first serious incident.
Yes, that's actually a common setup to start with. Many companies hand first-level contact to an external provider and keep higher levels in-house, while evaluating the quality of the setup before expanding the scope.
In most cases, level 3 stays in-house, since it requires access to the product's code or infrastructure. Some providers do develop, over the long term and with deep knowledge transfer, enough expertise to handle part of level 3. That remains the exception rather than the rule.
There's no universal threshold, since it depends heavily on product complexity and the nature of requests. What matters most is defining this target with the provider before launch, and tracking its evolution over time rather than comparing it to a generic figure found elsewhere.
No. Availability should be calibrated to actual product usage and user profile. Continuous support has a cost, only justified if requests genuinely come in outside standard office hours.
By precisely documenting the handoff from one level to another: information transmitted, response time from the next level, and no repetition required from the customer. This point, more than technical skill itself, often determines final satisfaction.
Outsourcing your helpdesk starts with a simple but often overlooked question: how far does the provider go, and how does the handoff work once it hits its limit. Once that boundary is clarified and formalised in a precise SLA, the right provider is recognised by its real technical expertise, the quality of its knowledge base, and the transparency of its reporting.
At Armatis, technical support is built on trained and certified teams, clear orchestration between support levels, and digital tools managed with transparency, so that speed of resolution never comes at the expense of the customer relationship. Discover our approach to technical support.
Sources
Armatis is a European specialist in customer relations and business process outsourcing (BPO), operating across multiple continents with thousands of employees serving companies of all sizes and sectors. The company designs and manages end-to-end customer service operations: multichannel contact centres, complaints handling, technical support, back-office and digitised processes. Backed by integrated technology infrastructure and the ability to adapt to any sectoral and regulatory context, Armatis helps its clients combine operational performance, quality of experience and cost control, wherever they need it.
Contact our teams to discuss your challenges and find out how we can support you
Join the leaders who trust our multilingual and technological expertise.