Software Support Outsourcing
Dedicated agents who turn "it does not work" into a reproduction your engineers can act on, and who eliminate configuration causes before escalating.

Page guide
On this page
The value is in the reproduction
Software support has a specific job that generic support does not: turning "it does not work" into something an engineer can act on.
A bug report that says a feature is broken costs your engineering team a day of investigation. One that says which version, which configuration, which sequence of actions, what was expected, what happened, and whether it reproduces reliably costs them an hour. The gap between those two reports is what a competent software support team is for - and it is where most of the money is saved, invisibly, on the engineering side of the ledger rather than the support side.
RHI provides dedicated software support agents trained on your application, working your queue and triaging into your engineering process.
What the team handles
- Application faults - features not behaving as documented.
- Configuration and setup issues - frequently the actual cause of a reported bug.
- How-to and capability questions - including the ones where the honest answer is that the product cannot do it.
- Data and import problems - malformed files, unexpected formats, encoding issues.
- Integration and API questions - where your software meets another system.
- Release-related contact - the wave that follows every update.
- Bug triage and reproduction - packaging genuine defects for engineering.
- Feature request capture - recorded properly so your product team receives signal rather than anecdote.
Configuration first, bug second
A substantial proportion of reported software bugs are configuration problems, environment differences or misunderstandings of intended behaviour. Escalating those to engineering wastes expensive time and trains engineers to distrust support tickets.
So the first question is always whether the software is behaving as designed under the conditions actually present. Agents establish version, environment, configuration and recent changes before forming a view - and "recent changes" is the highest-yield question in software support, because most faults appear after something changed.
Reproduction, and what happens when it will not
Where a fault reproduces, the agent documents the exact steps, expected behaviour, actual behaviour, frequency and environment. That package goes to engineering in your issue tracker in the format your engineers asked for, not a support narrative.
Where it does not reproduce, that is information rather than a dead end. The agent records what was tried and under what conditions, gathers logs and diagnostics where your product exposes them, and escalates as an unreproduced report with the evidence attached - clearly labelled, so engineering knows what they are receiving. An intermittent fault escalated honestly is more useful than one quietly closed as user error.
Release cycles change the shape of the queue
Software support volume follows your release calendar rather than a retail one. Every release produces a contact wave: new behaviour that looks like a fault, changed interfaces, regressions, and questions from users who did not read the notes.
We train ahead of releases rather than behind them, which requires you to tell us what is shipping and when. Clients who bring support into the release process early see a materially smaller post-release wave; clients who tell us on release day get a team learning alongside their users. We would rather have the release notes a week early than a heroic first day.
Feature requests as signal
Support hears what the product is missing before anyone else does, and most operations waste that. A feature request logged as free text in a ticket note is invisible.
We capture requests against a defined structure - what the user wanted to do, what they did instead, and how often it comes up - so your product team receives counted signal rather than anecdotes. Where a request is genuinely a documentation problem rather than a product gap, we say so.
Channels, systems and coverage
Written channels dominate, because logs, screenshots and configuration are easier to exchange in text. Most clients run email and ticketing primarily, with chat for quick questions and phone for urgent faults.
Agents work in your help desk and your issue tracker, because a bug report that has to be transcribed between systems loses detail. Our teams are experienced across common help desk platforms and issue trackers - competence, not partnerships. See technology. Coverage is built from shift units, and release windows often justify temporary enhanced cover rather than permanent headcount.
Recruitment and training
We hire for diagnostic reasoning and written precision. A software support agent writes more than they speak, and a vague ticket is a real cost to someone downstream.
Training includes hands-on work in a test environment, not documentation reading. Agents need to have broken the product themselves to recognise how users break it. Nobody takes a live contact before passing assessment.
Quality and reporting
Scorecard criteria specific to this work: was the environment established before investigating, was the configuration possibility eliminated, was the reproduction complete and in the required format, and was the escalation correctly classified. Plus the usual communication and compliance criteria.
Reporting covers first contact resolution, escalation rate, escalation accuracy - the proportion of escalated tickets engineering agrees were genuine defects - reopen rate, resolution time by complexity, and satisfaction. Escalation accuracy is the number that tells you whether triage is working. Figures published elsewhere on this site are historical or representative and campaign-dependent.
Getting started, and what it costs
Priced per dedicated agent per month with a five-agent minimum - published rates and what moves them. Training length is the main variable, and it tracks product complexity.
Bring ticket volume by reason, your current escalation rate and how many escalations engineering rejects, plus your release cadence. Related: technical support outsourcing, tiered support. Talk to us.
Frequently asked questions
Version, configuration, the sequence of actions, what was expected, what happened, and whether it reproduces reliably. A report saying a feature is broken costs your engineers a day; a complete one costs them an hour. Closing that gap is most of what this service is for.
By establishing version, environment, configuration and recent changes before forming a view. "What changed recently" is the highest-yield question in software support, because most faults appear after something changed.
It escalates as an unreproduced report with the evidence attached and clearly labelled, including what was tried and under what conditions. An intermittent fault escalated honestly is more useful to engineering than one quietly closed as user error.
We train ahead of it. Tell us what is shipping and when, ideally a week or more before, and the post-release contact wave is much smaller. Release windows often justify temporary enhanced cover rather than permanent headcount.
Yes, against a defined structure - what the user wanted to do, what they did instead, and how often it comes up - so your product team receives counted signal rather than anecdotes. Where a request is really a documentation gap, we say so.
Escalation accuracy: the proportion of escalated tickets your engineers agree were genuine defects. It is the number that shows whether the team is filtering or just forwarding.