New User Training Guide
A complete onboarding program for new operations team members. This guide walks you through every system, workflow, and standard you will use in your first weeks — one step at a time, with context for each decision you will be asked to make.
Orientation — What This Guide Will Do for You
Welcome to the operations team. This training guide is your primary onboarding resource. It is not a list of policies to memorize or a summary of things you should already know — it is a complete, step-by-step walkthrough of every system, workflow, and standard you will encounter in your first weeks on the job.
Read this guide in order the first time through. Each section builds on the one before it. After completing the full guide, you may use it as a reference document, navigating directly to any section you need. The sidebar tracks your progress through the training milestones.
- Log in to and navigate all required systems independently
- Receive, classify, and acknowledge an incoming ticket without assistance
- Apply the correct Standard Fix for routine issues from the Tier 1 resolution playbook
- Recognize the escalation criteria and escalate a ticket correctly to Tier 2
- Execute the shift handoff procedure as both outgoing and incoming agent
- Write a customer communication that meets the team's tone and content standards
- Understand what documentation is required and why it matters
You will not be expected to have this guide memorized before you begin taking tickets. You are expected to use it while you work. Experienced team members use documentation constantly — consulting the guide while working is not a sign that you are unprepared; it is a sign that you are working correctly.
How This Guide Is Structured
| Section | What You Will Learn | Est. Time |
|---|---|---|
| 01 — Orientation | Guide structure, learning objectives, how to use this document | 10 min |
| 02 — Core Concepts | The language, mental models, and operating principles of the team | 25 min |
| 03 — System Access | Logging in, navigating, and understanding every tool you will use | 35 min |
| 04 — Your First Ticket | Full walkthrough of receiving, classifying, resolving, and closing one ticket | 40 min |
| 05 — Daily Workflow | Shift start, queue management, prioritization, and shift end | 30 min |
| 06 — Communication Standards | How to write to customers and teammates — tone, templates, and exceptions | 30 min |
| 07 — Quality Standards | What good work looks like, how it is measured, and how to self-assess | 25 min |
| 08 — Completion | Certification requirements, who to contact with questions, next steps | 10 min |
Core Concepts — The Language of the Team
Before you can work effectively in the system, you need to understand the mental models and vocabulary the team uses. This is not a glossary — it is an explanation of how the team thinks about its work. Learning this vocabulary quickly will allow you to understand team communications, ask better questions, and make better decisions in ambiguous situations.
The Priority System in Detail
Priority is the single most important classification you will apply to a ticket. It controls how fast you must respond, whether your team lead is notified, and how far the SLA clock runs before a breach. Mis-classifying priority — in either direction — has real consequences for customers and the team.
| Priority | Label | Response SLA | Resolution SLA | Lead Notify? | Typical Trigger |
|---|---|---|---|---|---|
| P1 | Critical | 15 minutes | 2 hours | Required | Complete service outage; data loss; security concern; all users affected |
| P2 | High | 1 hour | 8 hours | If risk of breach | Core feature broken for one account; workaround unavailable; significant revenue impact |
| P3 | Standard | 4 hours | 2 business days | No | Feature degradation with available workaround; UI issue; non-critical integration failure |
| P4 | Low | 1 business day | 5 business days | No | Cosmetic issue; documentation request; how-to question; enhancement suggestion |
If a customer submits a ticket marked P1 and you believe it should be P3, you may not simply reclassify it downward. You must document your reasoning and obtain Team Lead approval before downgrading any ticket that arrived as P1 or P2. Unauthorized downgrading to avoid SLA pressure is a quality failure.
System Access — Every Tool You Will Use
You will work across three primary systems during your daily operations. This section walks you through logging into each one, navigating to the areas you will use most, and understanding what each system is responsible for. Complete all access setup steps in order — some systems depend on credentials established in earlier steps.
Your IT provisioning request must be marked Complete in the onboarding portal before any system access will work. If you receive access denied errors during these steps, contact IT via the onboarding portal before continuing. Do not attempt workarounds.
System 1 — The Operations Dashboard (Primary)
Dashboard Layout — What You Are Looking At
AUTH-003) will return the exact Standard Fix steps. Do not try to recall Standard Fix steps from memory — always verify against the playbook.System 2 — The Knowledge Base
The Knowledge Base is a separate system from the Operations Dashboard, accessible at the internal URL in your welcome email. It contains the full Tier 1 Resolution Playbook, all reference documents, approved customer communication templates, and the Exception Register. You will use it constantly via the dashboard Quick-Search, but you must also know how to navigate it directly.
System 3 — The Internal Communication Platform
Team communication happens on the internal messaging platform. You will use it to receive shift briefings from your team lead, coordinate peer escalations, and stay informed of any active incidents or queue-wide alerts. It is not a substitute for ticket documentation — anything operationally relevant must also be in the ticket record.
| Channel | Purpose | Expected Response Time |
|---|---|---|
| #ops-tier1-[shift] | Your primary shift channel. Shift briefings, queue alerts, and peer coordination posted here by your Team Lead. | Monitor continuously during shift |
| #ops-incidents | Active incident communications. If a P1 incident is declared, all updates post here. Read-only for Tier 1 during incidents. | Monitor continuously during shift |
| #ops-all-hands | Cross-team announcements, policy changes, and shift-affecting information from Operations Management. | Check at shift start and mid-shift |
| Direct message to Team Lead | Questions, exceptions, and situations requiring lead awareness that are not yet ticket-level. Always reference the ticket number if applicable. | Leads target < 10 minutes during shift hours |
| Direct message to Tier 2 agent | Verbal context handoff during escalation. Not a substitute for completing the written escalation in the ticket system. | Used for active escalations only |
Your First Ticket — A Complete Walkthrough
This section walks you through every step of handling one complete ticket — from the moment it arrives in your queue to the moment you close it. You will work a practice ticket in the training environment before handling live tickets. Your Team Lead will confirm when to switch from the training environment to the live queue.
The training environment URL is different from the live queue URL. They look nearly identical. Your training environment banner reads "TRAINING — Not Live" in amber across the top of the screen. If you do not see this banner, you are in the live queue. Confirm with your Team Lead before proceeding.
AUTH, PERF, INTG). The search will return the applicable playbook section. Read the full Standard Fix list for the category before applying any fix — you need to understand the full sequence before starting.Complete the practice ticket in the training environment, then request a review from your Team Lead before switching to the live queue. Your lead will review the ticket record you created and give you specific feedback on your documentation, timing, and classification. This review is required before live queue access is granted.
Daily Workflow — Shift Start to Shift End
Operations work has a rhythm. The same set of actions happens every shift start, every shift end, and at regular intervals throughout the day. This section makes that rhythm explicit so that you can build it into your habits rather than reconstructing it from memory under the pressure of an active queue.
Shift Start (First 10 Minutes)
During the Shift — Queue Management Principles
Beyond the step-by-step procedures, there are a set of operational principles that govern how you manage your queue throughout the shift. These are not steps — they are standing rules that apply continuously.
| Principle | What It Means in Practice |
|---|---|
| SLA urgency governs queue order | Always work the ticket closest to SLA breach first, regardless of when it arrived, who submitted it, or how complex it appears. Do not work in arrival order unless all SLA times are identical. |
| One active ticket at a time | Complete or formally pause (with a status update note) one ticket before opening the next. Context-switching between multiple open tickets is the leading cause of missed steps and incorrect resolutions. |
| Document while you work, not after | Add internal notes to the ticket as you complete each step — not as a batch at the end. Notes written after the fact are reconstructed from memory and miss details. Notes written in real time are accurate. |
| Never hold a ticket you cannot resolve | If you have been working a ticket for 20 minutes without a clear path to resolution, escalate. Holding an unresolvable ticket is not persistence — it is a SLA risk that harms the customer. |
| Patterns require immediate flagging | If you receive three tickets with identical symptoms within one hour, stop treating them as individual issues. Flag the pattern in the #ops-tier1 channel and notify your Team Lead before working the third ticket. This is an incident indicator. |
Shift End (Final 20 Minutes)
Shift end is the highest-risk moment for operations continuity. More tickets are lost, miscommunicated, or allowed to breach during shift transitions than at any other time. The following steps are required — not optional — for all agents, every shift.
- Stop accepting new tickets from the unassigned queue 20 minutes before shift end
- Update the status and internal notes on every open ticket to reflect current state
- For each open ticket, identify and document the next required action and who owns it
- Complete the Shift Handoff Record entry for every open ticket in the system
- Verbally brief the incoming agent on any ticket that has context not fully captured in writing
- Confirm the incoming agent has acknowledged the Handoff Record before logging out
- Log any patterns, anomalies, or concerns in the shift notes field of the Handoff Record
- Post shift-end status to the #ops-tier1-[shift] channel: queue count, any open P1/P2 items
Communication Standards — How We Write to Customers
Every communication you send to a customer is the team's voice — not just yours. The standards in this section define how that voice should sound, what it should contain, and what it should never include. These standards exist because customer communications are permanent records, are subject to legal and compliance review, and directly affect the customer's experience of the resolution — even when the technical fix was perfect.
Tone Principles
| Principle | In Practice | Example |
|---|---|---|
| Clear over clever | Use plain language. Short sentences. One idea per sentence. A customer in the middle of a problem is not in the right state to parse complex syntax. | Do "Your access has been restored." Don't "The authentication state has been rectified." |
| Precise without jargon | Be specific about what happened and what was done. Vague reassurances ("everything should be fine now") are not communications — they are noise. But precision does not require technical language. | Do "We reset your session token. You can now log in using your existing password." Don't "We invalidated the stale JWT." |
| Ownership without over-apology | Acknowledge the impact the customer experienced. Do not serially apologize — one acknowledgment is appropriate, repeated apologies erode confidence. Focus quickly on resolution. | Do "I understand this disrupted your workflow this morning. Here is what we did to fix it." Don't "I'm so sorry, I'm really sorry this happened, we apologize..." |
| Commitments are exact | If you commit to a follow-up, name a specific time. "Soon" and "shortly" are not commitments — they are false reassurances that customers correctly read as non-answers. | Do "I will follow up by 3:00 PM ET today." Don't "We'll get back to you soon." |
Common Mistakes and Corrections
You must never ask a customer for their password, full payment card number, full Social Security or national ID number, or any security question answer — in any channel, under any circumstance, including when the customer volunteers the information. If a customer sends any of these in a ticket, do not acknowledge the specific data in your reply. Add an internal note flagging the communication and notify your Team Lead immediately.
Quality Standards — What Good Work Looks Like
Quality in operations is not a soft standard — it is a measurable set of properties that each piece of work either has or does not have. This section describes those properties, how they are measured, and how to self-assess your own work before it is reviewed.
The Five Quality Dimensions
| Dimension | What It Measures | How It Is Assessed |
|---|---|---|
| Accuracy | Was the issue correctly classified? Was the right Standard Fix applied? Was the resolution verified? | QA review of ticket record; recurrence rate (same issue returning within 5 business days) |
| Timeliness | Was the response SLA met? Was the resolution SLA met? Was the Handoff Record completed on time? | SLA compliance report (automated); Handoff Record timestamp audit |
| Documentation | Are the internal notes complete, sequential, and accurate? Is the resolution code correct? Are all required fields populated? | QA spot-check; required-field audit (automated) |
| Communication | Do customer-facing messages meet tone, precision, and template compliance standards? | QA review of customer communications; CSAT survey results |
| Procedure Compliance | Were all steps followed in documented order? Were exceptions logged when deviations occurred? | Ticket audit trail; Exception Register review |
Self-Assessment Before Closing Any Ticket
Before closing a ticket, run through this self-assessment. These are the same questions QA will ask when reviewing the ticket. Catching a gap before closing is a self-correction; having it caught in review is a quality note. Both are recoverable, but the former reflects a higher level of operational discipline.
- Is the category code correctly assigned and does it match the customer's described symptom?
- Is the priority level correctly assigned based on the business impact criteria?
- Did I send the acknowledgment response within the SLA window for the assigned priority?
- Did I apply Standard Fixes in the documented order, without skipping or reordering?
- Did I add an internal note before applying each fix documenting what I was about to do?
- Did I perform the independent verification step — not relying on customer confirmation alone?
- Does my customer communication use plain language, avoid jargon, and follow the tone standards?
- Is the resolution code correct and does it accurately reflect which fix resolved the issue?
- Are all required fields in the ticket populated (category, priority, resolution code, all note fields)?
- If I deviated from the documented procedure at any point, did I log it in the Exception Register?
Speed and thoroughness are not opposites in operations work. A ticket documented completely and closed correctly the first time takes far less total time than one that is closed quickly, recurs, and must be worked again from the beginning.
Operations Quality Framework · Core PrincipleYou Have Reached the End — What Comes Next
Completing this guide is the foundation of your onboarding, not the entirety of it. The next steps transition you from reading about the work to doing it — under observation initially, then independently. Each stage has a clear completion criterion.
| Stage | Activity | Completion Criterion | Owner |
|---|---|---|---|
| Stage 1 | Training guide review (this document) | All sections read; knowledge checks attempted | Self-directed |
| Stage 2 | Practice ticket in training environment | Ticket completed and reviewed by Team Lead; feedback addressed | Team Lead reviews |
| Stage 3 | Shadowed live tickets (first 5 tickets) | Team Lead reviews first 5 live tickets and confirms quality | Team Lead approves |
| Stage 4 | Independent operations with daily check-in | One full week without quality notes requiring correction | Team Lead monitors |
| Stage 5 | Full independent certification | Team Lead submits certification form; access to full procedure library unlocked | Team Lead certifies |
During your shift: Direct message your Team Lead in the communication platform. Reference the ticket number if applicable.
About procedures: Search the Knowledge Base first; if the answer is not there, message your Team Lead and flag the gap in the Knowledge Base search results.
About your training progress: Your Team Lead schedules a check-in at the end of your first, second, and fourth weeks. Bring specific questions, not just general updates.
The detail in this guide exists because the work requires it — not because it is expected to be overwhelming. Every experienced member of this team learned the same procedures, used the same guide while working, and asked the same questions. The learning curve is real and the team is familiar with it. Ask questions early. Consult the guide constantly. Document your work thoroughly. The rest follows.