You're the person who keeps one company's business software working after the developers have moved on to the next project. Help desk resets passwords and fixes laptops; you figure out why the billing system skipped a whole batch of invoices overnight. The day below is a second-line analyst supporting a claims platform at an insurer, but the shape holds for ERP, banking and hospital systems too.
Before anyone else logs in, you open the job scheduler and look at last night's batch runs. The payment export finished, but the document-generation job failed halfway. You read the log, spot a timeout against the database, rerun the job with the operations team's okay, and note it in the shift handover so nobody gets surprised at stand-up.
The support team runs through open incidents in ServiceNow. Most tickets are small: a user who can't see a claim, a report that's missing a column, a field that won't save. You reproduce each one in the test environment, and a good share turn out to be permissions or bad data rather than a bug. Those you fix yourself. The real defects get written up for the dev team with steps, screenshots and the exact log lines.
Adjusters start reporting that claims are stuck in a pending status. It's spreading, so you raise a major incident, open a bridge call, and start querying the claims table in SQL to find what the stuck records have in common. They all came through the new partner feed. You give the incident manager a plain update every half hour while a developer confirms a mapping change broke the status code.
Once the fix is in, you run a data correction script that the dev lead reviewed, then check a sample of claims by hand. After that comes the part people skip: a knowledge article so the service desk can spot the symptom next time, and notes for the problem record so the root cause actually gets fixed, not just patched.
A new version goes out tonight. You walk through the deployment runbook with the release manager, confirm the rollback steps, and line up the smoke tests you'll run once it's live. You're on call this week, so your phone stays loud until the release is signed off.
Support teams are usually split into lines. First-line is the service desk taking calls. Second-line is you: you know one or a handful of applications deeply, you can read logs and query the database, and you can fix configuration and data problems without a code change. Third-line is the vendor or the in-house developers who change the code. The job lives or dies on how well you judge which problems stop with you and which need to go further, and how clearly you hand them over when they do. A vague escalation wastes a developer's afternoon; a sharp one with a reproduction and a suspect log entry gets fixed the same day.
This is the most common route. You spend time on the help desk, become the person who knows the finance or HR system best, and ask to shadow the application team. Learning SQL on the side is what turns that interest into a transfer.
Power users often cross over. A claims handler, a payroll clerk or a lab tech who already knows the workflow can learn the technical half faster than a technician can learn the business half. Hospitals and banks hire this way a lot.
A degree or course gets you in the door at larger employers, especially graduate schemes with a support rotation. You'll still need to show you can read a log file and write a query, so bring a small project that proves it.
7% of openings are fully remote.
$87,280 – $130,920
Typical range in the 11 of the newest 60 postings that list pay.
It's one of the better ones, because you see how a real system behaves in production, which a lot of developers never learn. The catch is that some people stay in the queue too long. Push to take on scripting, monitoring or release work so you have somewhere to go next.
IT support looks after devices, accounts and networks for everyone. Application support looks after specific business software: the ERP, the trading platform, the patient record system. You'll spend far more time in logs, databases and vendor documentation, and much less time with hardware.
The common next steps are site reliability or DevOps if you lean into automation and monitoring, business systems analyst if you prefer shaping how the system should work, or a team lead running the support function. Some move into development on the same product, since they already know its weak spots.
HeroApply applies to them for you, so you can keep doing the job you have.