Level 2 Support Overview

Updated on Feb 18, 2026
Published on Feb 5, 2026

2 minute(s) read

A

Article summary

This process describes the steps to fix an issue or defect that requires tech help. It covers the following types of issues:

Coding bugs or defects in any service or product
Data issues
Infrastructure issues
Security issues

Process Type	Ticket
Pipeline Name	Level 2 Support

Process Entry Points:

Client Support Process. When a ticket categorized as Bugs/Defects, Infrastructure & Networking Issues, Security Issues or Data Issues is moved to ‘Elevating’
Client Form. Available from dashboard.usheru.com
- Edit Link: https://app.hubspot.com/forms/2288092/new-editor/5a8d80ab-71ce-4611-a2e2-6a821537657c
- View Link: https://1d1i4.share.hsforms.com/2Wo2Aq3HORhGi4mqCFTdlfA

Process Stages:

STAGE NAME	STAGE DESCRIPTION	DATA REQUIRED TO ENTER STAGE	OUTCOME	OWNER	SLA
Validating	Ops to confirm it’s a real issue + gather minimum reproduction info.. If not an issue → Close (unresolved) or move to the correct pipeline. If any data required for the next state is unknown → contact the client to clarify. If all data is know, issue is understood, try to reproduce it and → move ticket to Replicating Issue.	Category * Ticket Subtype * De-escalation Reasons (when de-escalating)	A proven issue, with severity estimated and maybe replicated by ops	Operations	1 Day
Replicating	QA to get reliable reproduction evidence. If Ops could not reproduce, attempt to reproduce Sense check Severity, Acceptance Criteria, Target URL, Steps to Reproduce the Issue and Scope (affects other clients). When relevant, add/review device specific information (browser, web/mobile, etc) and/or screenshots. If issue can be replicated → move to Estimating If issue can’t be replicated or need more info → de-escalate to Validating Request	Acceptance Criteria * Target URL * Severity * Steps to Reproduce the Issue * Ops Can Reproduce the Issue * Issue affects other clients Client Target Date Company → Company Tier *	A proven and replicated issue, with severity estimated	QA	2 Days
Estimating	Project Manager sets the Estimated Delivery Date (Due Date in Clickup) and verifies the priority based on severity, company tier, client target date and scope (affects other clients) Once issue is fully estimated → move to Fixing Issue (Ready to Do / Fixing) in Clickup	Acceptance Criteria * Target URL * Severity * Steps to Reproduce the Issue * Issue affects other clients * Issue Workaround	A prioritized and estimated (due date) issue	Project Manager	1 Day
Fixing	Estimated Delivery Date is automatically communicated to the client. Any change to the Due Date from this step will also be automatically communicated to the client. Tech fixed the issue and create a Pull Request with the fix Once the Pull Request is ready → move to Verifying Fix	Estimated Delivery Date * Priority *	A fix for the issue (a Pull Request)	Tech
Verifying	QA verifies the issue and confirms it meets Acceptance Criteria. If everything looks good, writes resolution notes and move the ticket to Closed (Resolved) [In Production in Clickup)	Pull Request *	A validated fix for the issue (a merged Pull Request) and a explanation of the resolution	QA	1 Day
Closed (Resolved)	Delivery is automatically communicated to the client.	Merged Pull Request * Resolution Notes *
Closed (Unresolved)	Ticket closure is automatically communicated to the client.	Resolution Notes *

Was this article helpful?