L1, L2, L3 in Practice

"VPN drops every twenty minutes." That is the whole of the e-mail Lena sends from home at 08:52 on a Tuesday. And it becomes ticket 4471 at Bluewater Bank before she has finished her coffee. It is a good ticket. It has a symptom, a frequency and a requester who answers her phone. It will still visit three desks before it is fixed. At each desk a different person will do a different kind of work on it. The three desks exist to do three different kinds of work.

Most descriptions of support tiers stop at the labels. This article, part of our Support Tiers series, is about what the labels mean on a Tuesday. L1, the first line, takes every ticket, resolves the known and the simple, and owns the relationship with the user. L2, the second line, does deeper diagnosis with system access and takes the unknown-but-solvable. L3, the third line, is the specialists, engineers and vendors who change systems rather than fix things inside them. Escalation is moving a ticket to a higher tier; a bounce-back is the higher tier returning it. The first article in the series, What Support Tiers Are Actually For, explains why the lanes exist. This one is about what each lane does.

It covers what each tier takes, resolves, never touches, and needs in skills and access. Then come a table of who owns the common ticket types and ticket 4471's full path with the clock running. We cover the one-page tier charter, what a bounce-back must carry, and why tier is not seniority. A war story from Acme about a single missing line follows, then a charter template to fill in before lunch.

What L1 Owns

L1 takes every ticket, without exception, and that is the most important thing about it. Every e-mail, form, chat and walk-up lands in the L1 queue first and is read by a human within the hour. It leaves with an owner, a priority and an acknowledgment that names the next update time. Nothing enters the desk by any other door, including the corridor.

L1 resolves the known and the simple: password resets and unlocks, and access requests that follow a written rule. It resolves the entries on the known-error list (a short list of problems the desk has seen before, with the symptom and the fix). It resolves printer and drive-mapping problems on the standard build, and how-do-I questions with an article already written. The test is whether a competent technician with the list in front of them can resolve it in under thirty minutes without touching a server.

L1 never touches a server configuration, a firewall rule, a database, or anything on the change list. It never holds a ticket past its time box hoping for inspiration. Its skills are reading carefully, searching well, following a procedure and writing a clear note. Its access is a help desk account that can reset passwords, unlock accounts, grant membership of the standard groups, and see the standard build. A tool that searches old tickets as easily as the knowledge base makes the second skill cheap. QuerySolv's full-text search runs across whole conversations, and its agents-only articles are a natural home for a known-error list.

L1 also owns the user relationship for the life of the ticket, even after escalation. The user hears from L1 at the promised times, whichever lane is holding the ticket. This is the part most often dropped, because once a ticket has gone upstairs it feels like someone else's. It is not. The user did not escalate anything; they are still waiting for the person they wrote to.

The word "triage" belongs to this lane. And it means reading the ticket and deciding, in under five minutes, what it is, who owns it and how urgent it is. It is said with more ceremony by people who have never done it at 09:00 with fourteen in the queue.

What L2 Owns

L2 takes what L1 escalates. That is the ticket that is not on the list, or is on the list and did not respond to the listed fix, or passed its time box. It does not take tickets directly from users or from the corridor. If it is taking either, L1 is not the front door, and the tiers are a drawing.

L2 resolves the unknown-but-solvable: a problem that needs real diagnosis, access to logs and consoles, and an hour or an afternoon of uninterrupted attention. It reads the firewall log, traces the e-mail, compares the broken machine with the working one, and finds the cause. Most of what it finds can be fixed within the existing configuration of a system: restart the service, clear the lock, repair the profile.

L2 never changes the design of a system. That means no new firewall rules, no schema changes, no settings on a shared device that other users depend on. The exception is when the charter names that change as within its gift. Its skills are diagnosis, reading logs, and knowing the environment well enough to tell normal from strange. Its access is administrative: local administrator on the fleet, read access to servers and network devices, and write access to a named short list.

L2 is where the interesting problems live, which is why everyone wants to be L2. Nobody wants to be L2 at 16:55 on a Friday. The time box matters here as much as at L1. An L2 ticket with three hours of attention and no cause does not need a fourth hour. It needs a second opinion, a vendor, or a change, and all three are L3.

What L3 Owns

L3 takes what L2 escalates with evidence: a cause, or a documented failure to find one, and a proposed change. L3 is the specialists, the engineers who own a system's design, and the vendors whose product is involved. On a small desk L3 is often one person for each system and a support contract for the rest.

L3 resolves by changing the system rather than fixing something inside it. That could be a firewall timeout, a server setting that affects everyone, a patch, a vendor case, a redesign. The resolving step is a change, so it goes through a change window. That is a scheduled time when a system may be altered with a plan and a way back. The change is documented so that it does not happen again as a mystery.

L3 never takes a ticket straight from a user. It never works one that has not been through L2 (except by a written exception for outages). It never resolves one without writing down what changed. Its skills are the deep ones: the product, the protocol, the vendor's support process. Its access is whatever the system needs, which is why its lane is the one most worth protecting from resets.

L3 is slow by design. A change made quickly, without a window, has a different name in the incident report.

The Table of Ownership

The table lists the ticket types every small desk sees, the lane that owns each, and the reason. The reason is the part to copy, because your ticket types will differ and the rule will not. The owner is the lowest lane that can resolve the ticket within its access and its time box.

The outage row is the one written exception where L3 starts at once. L1's job in an outage is the job it always had: owning the users while someone else owns the fix.

One Ticket, Three Lanes: The Path of 4471

Ticket 4471 arrives at 08:52 and Sam, on the L1 lane, opens it at 09:03 during the morning triage pass. He searches the known-error list for "VPN" and "drops" and finds nothing that matches a twenty-minute cycle. He calls Lena, has her send the client log, and learns she has already tried the wired dock with the same result. The log shows a clean disconnect every twenty minutes, not an error, and the wired test rules out her wireless. At 09:17, after fourteen minutes with nothing left on the list to try, he escalates to L2 with the four-line handoff note. It covers what Lena reported, what he tried, what he found, what he is asking. He tells Lena the next update will come by 11:00.

Priya, on L2, picks it up at 09:40. She has read access to the firewall and opens the VPN session log for Lena's account. Every session ends with an idle-timeout entry at exactly twenty minutes. Lena's work that week is reading long documents, so her tunnel often carries no traffic for that long. The profile is dropping her on purpose. By 10:20, after forty minutes, Priya has the cause and the fix: raise the idle timeout on the profile. She may not make that change; the charter puts firewall changes in L3 and in a window. She escalates to Marcus with the log excerpts, the profile name, the proposed timeout and the three other open tickets that match. She gives Lena a workaround until then: keep the mail client open, because it polls every five minutes.

Priya could change the firewall. She has done it before. The charter says Thursday, and the charter is right. The last time a timeout was changed on a Tuesday morning it took four sites off the VPN for an afternoon.

Marcus, as L3 for the firewall, accepts the ticket at 10:35 and raises a change for the Thursday 18:00 window. In the window he raises the timeout, tests from a laptop on the guest network, and writes the change note. He adds "VPN drops at a fixed interval while idle" to the known-error list. He resolves 4471 at 18:40 and merges the three matching tickets into it. Sam, still the owner of the user relationship, writes to Lena that evening. He explains what was wrong, what was changed, and what to do if it returns. She confirms on Friday at 09:10. Elapsed: two and a half working days. Hands-on: fourteen minutes at L1, forty at L2, about an hour at L3.

Notice what did not happen. Nobody at L1 spent an hour reading firewall documentation. Nobody at L3 phoned Lena to ask what "drops" meant, and nobody changed a shared device on a Tuesday morning. The ticket was slower than a hero on a good day and faster than the same hero on the day he was in a server room.

Writing the Boundaries Down

The boundaries hold only if they are written on one page that everyone on the desk has read, and that page is the tier charter. It answers three questions: what L1 resolves without escalating, what L2 may change on its own authority, and what goes to L3 and by what route.

The L1 section is a list, not a description. "Known and simple" is not a boundary. The list "password resets, unlocks, access to the standard groups, the twenty entries on the known-error list, and how-do-I questions with an article" is. Add the time box (thirty minutes of effort, then escalate) and the two things L1 may never do (change a server; hold past the box). A technician on their first Monday should be able to work the lane from this section alone.

The L2 section says what L2 may change, because "may change" is the boundary that leaks. Write the short list: restart these services, clear these locks, repair these profiles, change settings on one user's machine. Then the rule for everything else: a change to a shared system goes to L3 with evidence and a proposal, however small it looks. Add L2's time box (three hours of effort, or the moment the fix is a change) and the bounce-back rule from the next section.

The L3 section names the systems, the people, and the route in: "Firewall and VPN: Marcus, by change request with the evidence attached; outage route: phone." Name the vendor for each system under contract and who may open a case. This section goes out of date fastest, because people move and vendors change, so give it a review date.

A charter that is not written down lives in the memory of whoever is on leave. I have written three charters. The first two were longer and worse, because they described the lanes instead of listing what each could do.

The Bounce-Back

A bounce-back is the higher tier returning a ticket to the lane it came from, and it is allowed, once, with a reason. The reason is one of three. The ticket was on the lower lane's list and should have been resolved there. Or the handoff note was missing something the higher lane needs and cannot get itself. Or the higher lane found the cause and the fix is on the lower lane's list. The third is the good kind. The first two say the boundary or the handoff needs work.

A bounce-back must carry at least as much as the escalation did. It says what was looked at, what was found, and exactly what the lower lane is being asked to do. "Not ours" is not a bounce-back; it is a ticket thrown back over a wall, and the user is standing between the walls. Write it as an internal note so that it travels with the ticket rather than in a chat thread. In QuerySolv an internal note is never mailed to the requester, which is what makes it safe to be candid in one.

Never bounce silently. A ticket that reappears in the L1 queue with no note and a new assignee teaches the lower lane that escalation is a lottery. Say why, every time. The full rules for what travels up and what may come back are in Escalation Boundaries That Hold. The charter needs only the one-line version.

Tier Is Not Seniority

A tier is a lane for a kind of work, not a grade for a kind of person. The L1 lane staffed by a senior administrator on rotation is fine. It is often the best week the queue has, because the known-error list gets corrected by someone who knows why the entries are wrong. The L3 lane staffed by a junior engineer who owns one small system is also fine, if the charter says so. Whoever is in the lane needs the list, the rights and the time box that go with it, and nothing else about them matters.

The rank reading makes tickets move for the wrong reasons. Read as rank, L1 is a place to escape from, so tickets are escalated for status rather than need. In that reading, L3 is a place that does not take resets, so the queue waits while a free engineer looks elsewhere. Read as routing, the free engineer takes the lane for an hour, resolves nine resets, and goes back to the firewall. Nothing about them changed. Only the lane did.

The specialist who is also L1 on Fridays is not a contradiction. The specialist who is L1, L2 and L3 on Fridays is a one-person desk with a diagram, and the diagram is not helping. I have been that person. The diagram was on the wall behind me, and it was very tidy.

A War Story: The Acme L2 Queue

Acme introduced tiers in the spring with a two-page charter. The desk had an L1 lane staffed by Dana and Tomas, and an L2 queue for the two senior administrators. Within a month the L2 queue held sixty tickets, and forty-one of them were password resets. Dana had read the charter carefully. She found that the L1 section listed "account questions" but never said L1 could reset a password. She escalated every reset rather than guess at a right she was not sure she held. The senior administrators had been doing the resets from the L2 queue for four weeks and assuming the volume was temporary. The fix was one line in the L1 section, "password resets and unlocks, using the help desk account", and the right to match it. The L2 queue was down to nine tickets by the following Friday. Nobody had made a mistake; the charter had an edge, and the edge had been found by someone doing exactly what it said.

Every charter has an edge like that. The desk finds it by watching what is escalated in the first month. For each ticket, it asks whether the sending lane could have resolved it if the page had said so.

The Tier Charter Template

The template fits on one page, and the blanks are meant to be filled in by the people on the desk. Keep the lists short enough to be read. Review it when anyone joins or leaves, and whenever an escalation surprises you.

TIER CHARTER                                   Desk: ____________
Owner: ____________   Reviewed: __________   Next review: __________

L1, FIRST LINE                        Staffed by: _____________________
Takes:    every ticket, by every route, before anyone else.
Resolves without escalating:
  [ ] password resets and unlocks (help desk account)
  [ ] access to the standard groups and shares, per the approval rule
  [ ] known-error list entries: _____ entries, kept at _______________
  [ ] printer, mapping and profile problems on the standard build
  [ ] how-do-I questions with an article (send it, confirm it worked)
  [ ] __________________________________________________________
Never:    changes a server, device or shared setting; holds past the box.
Time box: ____ minutes of effort, then escalate with the four lines
          (reported / tried / found / asking).
Owns:     the user relationship for the life of the ticket.
Access:   _______________________________________________________

L2, SECOND LINE                       Staffed by: _____________________
Takes:    tickets escalated by L1 with the four lines. Not from users.
Resolves: the unknown-but-solvable within the existing configuration.
May change on its own authority:
  [ ] restart these services: _____________________________________
  [ ] clear locks, repair profiles, settings on one user's machine
  [ ] __________________________________________________________
Never:    changes a shared system's design or a device others depend on.
Time box: ____ hours of effort, or the moment the fix is a change.
Bounce-back: once, with a reason and a note, never silently.
Access:   _______________________________________________________

L3, THIRD LINE                        One line per system
System            Owner        Route in              Vendor / case by
________________  __________   change request + evidence  ______________
________________  __________   ___________________   ______________
________________  __________   ___________________   ______________
Outage exception: L1 logs and informs users; L3 starts at once by phone.
Every L3 resolution is a documented change and a known-error entry.

Read it back as the newest technician. Where they would have to ask, the page has a gap, and the gap is the next thing to write.

Lena's ticket is closed, and the timeout is documented. The next person whose VPN drops at a fixed interval will be resolved at L1 in five minutes by someone reading the entry Marcus wrote. That is what the three lanes are for. Whether yours are working, and how to tell from four numbers, is the subject of Measuring Whether Your Tiers Work.

Frequently Asked Questions