Every problem a client reports becomes a ticket. You live inside tickets as an L2 engineer. Today you learn how tickets are born, how they move, and how fast you need to respond.
Imagine you go to a hospital. You walk in and tell the receptionist your problem. They write it down, give you a token number, and a doctor is assigned to you. If your issue is really serious (like a heart attack) you skip the queue. If it's a small cut, you wait your turn.
Jira is that hospital system. Every client complaint = a ticket. Every ticket has a number, a status, and someone assigned to fix it. SLA is the rule that says "how fast must the doctor respond." A heart attack = respond in 2 minutes. A small cut = respond in 2 hours.
Jira is a tool companies use to track problems and tasks. When a client reports an issue — like "payments are failing" — someone creates a Jira ticket. That ticket tracks everything: what the problem is, who is working on it, what has been done, and whether it's fixed.
As an L2 support engineer, Jira is where your work lives. You'll open it every morning, see what tickets are assigned to you, and work through them one by one.
SLA = Service Level Agreement. It's basically a promise your company makes to the client: "We will respond to your problem within X hours." If you miss that promise, it's a breach — and that's a big deal in fintech. Clients can penalize your company for it.
Different severity levels have different SLA times. A system-down emergency has a much tighter SLA than a minor UI bug.
A ticket should never just sit there silently. Even if you don't have a fix yet, you must update the ticket with what you've tried, what you found, and what you're doing next. This is called adding comments to the ticket.
The client can see the ticket status. If it stays "Open" for 3 hours with no update, they get nervous. Keep it moving — even a comment like "Investigating, found the issue is in the Payments module" is better than silence.
Everything is down. No one can use the system. Real money is being affected right now. All hands on deck. Wake people up if needed.
A major feature is broken but the system is still partly working. For example, payments work but refunds are failing for all users.
Something is broken but it affects only some users or a non-critical feature. There's usually a workaround available.
Minor issues — a wrong label, a UI glitch, a small report formatting error. No one's workflow is blocked.
| Priority | Example in Fintech | First Response | Resolution Target | Who Gets Notified |
|---|---|---|---|---|
| P1 — Critical | All payments down, core banking offline | 30 minutes | 2 hours | L2 + L3 + Manager + Client |
| P2 — High | Refunds failing, login broken for many users | 2 hours | 8 hours | L2 + L3 |
| P3 — Medium | Reports not generating, slow dashboard | 4 hours | 24 hours | L2 Engineer |
| P4 — Low | Wrong date format, minor UI bug | 8 hours | 72 hours | L2 Engineer |
First contact. Picks up the ticket, asks basic questions, tries simple fixes. If they can't solve it in the agreed time, they escalate to L2. (That's where you come in.)
Deeper investigation. You dig into logs, check the database, test in UAT, try to reproduce the issue. You know the product well. If the fix needs a code change or is beyond your access, you escalate to L3.
Code-level fixes. Developers or senior engineers who can actually change the source code. Only get involved when L2 confirms the problem is a real bug — not a config issue or user error.
Never escalate a ticket without first doing your homework. When you pass a ticket to L3, you must include: what the problem is, what you already tried, what you found in the logs, and why you believe it needs a code fix.
Sending a ticket with just "client is complaining, please check" is a bad escalation. It wastes everyone's time and makes you look lazy.
Every ticket must have: a clear title, the client name, which product/module is affected, severity level, steps to reproduce the issue, and what you've done so far. Here's a real example of what a good ticket looks like:
DB_CONNECTION_TIMEOUT starting at 09:01 AM.A ticket comes in at 2 PM marked P1. Your SLA says you must respond in 30 minutes. You stop everything else and jump on this first. Even if you have 5 other tickets open — P1 is always the priority.
You've been working on a ticket for 2 hours and still can't find the fix. Don't sit on it silently. Update the ticket with what you've tried, change status to "Escalated", and send it to L3 with full notes. SLA clock is still running.
A client calls and says "this is urgent, please make it P1." But it's just a report formatting issue. You assess the actual business impact — is any money blocked? Are users unable to work? If not, it stays P3. Severity is based on impact, not the client's mood.
You fixed an issue and moved the ticket to "Resolved." The client replies: "Actually it's still broken on our end." — You reopen the ticket, change status back to "In Progress", and investigate again. Never close a ticket without client confirmation.