SaaS L2/L3 staff augmentation for a field-service software company: product escalations down from 34 a week to 9
A field-service management SaaS kept its first-line provider and engaged TechSupport Team for technical escalations. The engagement added dedicated L2 (second-level) and L3 (third-level) engineers by day, a managed on-call rotation for Sev 1 and Sev 2 at night, and tenant-scoped access. Escalations reaching product engineers fell from 34 per week to 9.
Summary
TechSupport Team supplied two dedicated L2/L3 engineers by day and a managed on-call rotation at night to a field-service SaaS company. They supported its Python, PostgreSQL and AWS product behind the client's first-line provider. Over the first 90 days, escalations reaching product engineers fell from 34 per week to 9, according to the client's tracker export. The client kept customer communication, release approval and tenant-data controls.
Engagement facts
| Fact | Value |
|---|---|
| Industry | B2B SaaS, field-service management |
| Client location | United States, anonymized region |
| Application type | Multi-tenant product with single sign-on (SSO), webhooks, billing events and large data exports |
| Stack | Python and Django, PostgreSQL, background workers, AWS |
| Roles supplied | Two dedicated L2/L3 engineers by day; three engineers on a managed night on-call rotation |
| Seniority | Senior L3 engineer, two mid-level L2 engineers |
| Engineer count | 2 dedicated by day, 3 on the night rotation |
| Engagement duration | Ongoing, first reviewed at 90 days |
| Coverage hours | Day: client business hours; night: on-call for Sev 1 and Sev 2, every night |
| Time zones | One US time zone by day; night rotation covers the same zone plus overlap |
| Reporting line | Day: the client's support director; night: TechSupport Team rotation lead with escalation to the client's duty manager |
| Model | Staff augmentation by day; managed on-call coverage at night |
Why the client needed engineers
The client's first-line provider handled customer conversations well, but tenant-specific incidents kept reaching the product team. They included single sign-on failures after certificate rotations, looping webhook deliveries, missed billing provider events and export jobs that timed out for the largest tenants. The baseline at assessment was 34 technical escalations reaching product engineers per week, with a median of 26 hours before useful evidence appeared.
Hiring two senior support engineers internally was slow and would not cover nights. The client chose augmentation to add depth behind its provider immediately, kept the provider for customer contact, and added managed night on-call after the day model proved itself.
Team composition and responsibilities
By day, two dedicated L2/L3 engineers worked in the client's tracker under the client's support director; the senior engineer carried L3 code changes. By night, a managed rotation of three engineers covered Sev 1 and Sev 2 on-call, led by a TechSupport Team rotation lead with an escalation path to the client's duty manager. The provider kept all customer conversations; our engineers returned plain-language technical summaries. The product team kept release approval and all data-correction decisions.
Selection and onboarding
Role brief and interviews
The client interviewed three proposed engineers and selected two. Time from signed agreement to first shift was two weeks, including tenant-scoped access approval.
Tenant-scoped access
Access was limited to named tenants and tools agreed in the assessment; a safe test dataset replaced any need to copy customer records.
Shadowing and drill
The day engineers shadowed live escalations with the provider and passed a drill on evidence standards and handoff format. Night engineers passed the same drill plus an on-call triage drill before their first rotation.
Independent work
The client approved independent work after two weeks for the day engineers; the night rotation went live one month in, after the day model was reviewed.
Technical work performed
- Investigated SSO failures from Security Assertion Markup Language (SAML) logs, isolating tenant configuration from product defects.
- Traced looping webhook deliveries and prepared replay plans accounting for duplicate and out-of-order events.
- Confirmed missed billing provider events and prepared handler changes tested in the provider's test mode.
- Diagnosed API rate-limit and authentication errors per tenant, including version mismatches on client integrations.
- Reproduced large-export timeouts and shipped a batched export with completeness and duplicate checks.
- Updated the runbook and reproduction notes for every confirmed incident class.
One representative incident
- Intake
One tenant's users could not log in after the tenant rotated its identity provider certificate. The first-line provider collected reports but could not locate the fault.
- Investigation
The L2 engineer checked the SAML logs for the affected tenant and confirmed the tenant settings still held the old certificate, a configuration fault rather than a product defect.
- Action
The finding returned through the provider with plain steps for the tenant's administrator, and a monitoring check for certificate mismatches was proposed.
- Approval
The tenant approved the configuration update on its side; the client approved the new monitoring check as a product change.
- Restoration and permanent fix
Login restored the same day. The monitoring check, released two weeks later, caught two further rotations before users noticed.
Login was restored the same day. A cross-tenant certificate check now flags rotations before users report them, and SSO stopped being a recurring escalation class for this client.
Measured results
| Metric | Baseline | Result | Window | Sample | Source |
|---|---|---|---|---|---|
| Escalations reaching product engineers | 34 per week | 9 per week | First 90 days | All technical escalations | Client tracker export |
| Tickets closed without product-engineering help | 41 percent | 82 percent | First 90 days | All closed technical tickets | Client tracker export |
| Reopened tickets | 11 percent | 3 percent | First 90 days | Closed tickets reopened within 14 days | Client tracker export |
| Median time to useful investigation evidence | 26 hours | 5 hours | First 90 days | Escalations with evidence attached | Incident records |
| Repeat incidents with the same cause | 7 per quarter | 1 | First 90 days | Confirmed repeats in the root cause analysis (RCA) log | RCA log |
Evidence and limitations
The metrics come from the client's tracker export and the incident records our engineers wrote in the client's tools. A product release in month 2 fixed an unrelated defect class, which may contribute to the repeat-incident drop alongside the new runbooks. Ticket volume rose 8 percent during the window, so the lower escalation count is not explained by quieter demand. The client's support director reviewed this case study before publication; tenant-identifying details are anonymized with approval.
Questions buyers ask
Who talked to the tenants?
The client's first-line provider kept every customer conversation. Our engineers wrote technical summaries for non-specialists, and the provider turned them into tenant updates.
How did three parties share one queue?
One tracker, named owners and a handoff format were agreed at assessment. The provider owns first line and customer contact, our engineers own technical investigation, and the product team owns defects that reach the roadmap.
How was tenant data protected?
Access was scoped per tenant with named accounts, and a safe test dataset stood in for customer records. Any production check needed client authorization, and no customer records were copied.
How did the night on-call rotation work?
Three engineers shared the rotation, covering Sev 1 and Sev 2 every night. Each rotation engineer passed the same drill as the day team plus an on-call triage drill before their first shift.
Could the client add more engineers later?
Yes. The agreement allows adding or removing engineers with notice; the night rotation already scales this way without changing the client's own headcount.
Contact us
Tell us which engineers you need, or ask a question. For a detailed request, use the engineer request form.
- We reply by email.
- We agree a call about the roles, your stack and the hours.
- If there is a fit, we propose engineers after an assessment.