Most organisations already have a service desk. An internal IT team or a managed service provider answers the phone, logs the ticket and fixes what it can. Then an incident lands that nobody on first line can fix: the line-of-business application is throwing errors, an integration has stopped posting invoices, or a page that worked yesterday now times out. That ticket needs software engineers, and that is where things usually slow down.
Assemblysoft integrates with your service desk to provide second- and third-line support for the applications we build and maintain, and for applications others have built that we have taken on. This article explains how that works in practice.
First, second and third line in plain English
- First line takes the call, logs the incident, gathers details and resolves known issues: password resets, access requests, documented workarounds. This usually stays with your own IT team or MSP.
- Second line is deeper technical investigation: reproducing the fault, reading logs and telemetry, checking configuration, data and integrations, and restoring service with a fix or workaround.
- Third line is engineering: changing code, fixing data at its source, correcting infrastructure, and finding the root cause so the incident does not come back.
We cover second and third line together, so an incident never bounces between "the support people" and "the developers". The engineers who investigate it are the ones who can fix it.
We work inside your service desk, not beside it
The most common failure in escalated support is ticket ping-pong: incidents forwarded by email, updates lost, and the SLA clock running in one system while the work happens in another. We avoid it by integrating with the service desk you already use, whether that is ServiceNow, Jira Service Management, Freshservice, Zendesk, TOPdesk, HaloITSM or Microsoft-based tooling. Depending on the platform and your preference, we connect in one of two ways:
- As agents in your tool. Our engineers work tickets assigned to an Assemblysoft resolver group directly in your service desk.
- Through a two-way API integration. When an incident is assigned to us, it is created automatically in our engineering board. Status, priority, comments and resolution notes then sync both ways, so your team sees every update without chasing.
Either way, your service desk stays the system of record. The ticket number your users know, your SLA timers and your reporting all stay where they are.
What happens when an incident reaches us
- Triage against an agreed severity matrix. Severity is defined by business impact and agreed with you in writing. Response targets follow it; see our indicative response and resolution targets.
- Investigation with real evidence. Application Insights and Azure Monitor telemetry, logs and recent deployments are checked first, so diagnosis starts from data, not guesswork.
- Restore service. A workaround or fix is applied, and the ticket is updated in your desk in language first line can pass on to users.
- Fix the cause. Third-line changes go through the same tested release pipeline as feature work, never as untracked hot fixes on a live server.
- Close the loop. Significant incidents get a short post-incident review, and recurring ones are raised as problem records so the pattern is removed, not just the symptom.
Tickets before your users notice
The best incident is the one a user never has to report. Because we run monitoring for the applications we support, alerts for failed integrations, rising error rates or slow responses can open incidents in your service desk automatically, tagged with the right category and assigned to us. First line sees the problem, and that it is already being worked, before the phones ring.
Security and access
Service desk access follows least privilege. Our engineers get only the queues and permissions they need, integration credentials are held in Azure Key Vault, and every action is attributable in your audit trail. Security incidents follow our documented incident response process, including prompt notification.
What we need from you
To set it up we agree the severity definitions and escalation contacts, create the resolver group or API user in your service desk, and connect monitoring for the applications in scope. Onboarding also captures how each application works into runbooks, so knowledge sits in documentation, not in one person's head.
If your first line is drowning in application incidents it cannot resolve, see how our Managed Application Support fits around your existing team, or get in touch to discuss your service desk.
