Zoho Desk
Zoho Desk — Tickets, Status Discipline & SLAs
Internal training • Focus: 3-hour first response + priority-based resolution + clean evidence for Teamflect
What this lesson covers
Zoho Desk is our central system for handling inbound client requests as tickets. This lesson shows how to: acknowledge correctly, apply the Status Matrix, manage priority-based SLAs, keep notes audit-ready, and protect the numbers that feed into Teamflect performance tracking.
By the end, you can
- Explain what a ticket is and why it matters
- Protect the 3-hour First Response SLA
- Use Status + Priority correctly (Status Matrix discipline)
- Resolve, document, and close tickets cleanly
Use the audio to understand the “why” behind ticket discipline. Then apply the workflow below.
Use these documents to confirm the workflow, statuses, and rules while you practise.
Lesson content
Use the workflow every day. Consistency is what protects SLA performance and clean reporting.
A ticket is a tracked client request. It contains the client message, your replies, internal notes, attachments, status changes, timestamps, and SLA tracking. This is how we prove service delivery, protect continuity, and defend our work.
Where tickets come from
Most tickets are created from inbound emails (and other connected channels). The ticket is the “case file” for that request.
What “good” looks like
Correct status, clear notes, correct public reply, the right attachments, and closure with a documented outcome.
Internal vs public replies
Public replies go to the client. Internal notes are for handover + evidence (never assume the client sees notes).
Your Zoho Desk habits directly affect two outcomes: First Response SLA and Resolution SLA. These outcomes feed into team performance tracking.
These are the practical “numbers” your daily work supports.
- Own the ticket: assign correctly and act quickly.
- Status must match reality: don’t leave tickets “In Progress” if you’re waiting on a client.
- Notes must support handover: write them so anyone can take over instantly.
- Close cleanly: communicate outcome + capture evidence, then close.
Common ways teams accidentally fail First Response SLA (and how to avoid it)
- Reading the ticket but not sending a public reply (“I’ll respond later”).
- Leaving the ticket unassigned or incorrectly assigned so no one owns it.
- Only adding internal notes instead of acknowledging the client.
- Waiting for “all info” before acknowledging — acknowledge first, then request what’s outstanding.
Use this sequence every time to protect SLAs and keep reporting clean.
-
1Own the ticket (assignment + quick triage)Confirm correct assignment and identify: What is the request? What is the priority? What is needed to proceed?
-
2First public response within 3 hoursSend a short acknowledgement. If info is missing, request it in the same response. This protects the First Response SLA.
-
3Status + priority discipline (Status Matrix)Apply the correct status and update it as work progresses. Incorrect status hides blockers and breaks reporting.
-
4Work the ticket (investigate + resolve)Action the request, attach evidence, and add internal notes that allow immediate handover if needed.
-
5Client update + close properlyConfirm the outcome to the client, document the resolution, then close cleanly to protect SLA and keep the queue accurate.
What your first response should include (simple template)
- Acknowledge: “Thank you for your email/request.”
- Confirm understanding: “We understand you need…”
- Next step: “We will do X by Y time / we are investigating.”
- If information is missing: “Please provide A, B, C so we can proceed.”
- Close: “Kind regards, Nkwali Compliance.”
The Status Matrix exists so everyone uses the same language and reporting stays accurate. Status must reflect reality: if you’re waiting on the client, your status must show that.
How to choose the correct status (decision guide)
- New / Open: ticket received; must be acknowledged quickly.
- In Progress: you are actively working on it.
- On Hold / Waiting: blocked by client info, third party, or internal dependency (note must explain what is missing and what was requested).
- Resolved: work completed; outcome communicated (or ready to be communicated).
- Closed: finalised; no further action required.
The biggest reporting mistake to avoid
Resolution SLA is measured by ticket priority. Set priority correctly and manage time through proactive updates.
Use only when urgent and time-sensitive (deadlines, imminent risk, or operational blockage).
Standard client requests needing same-day handling or next-business-day completion.
Non-urgent requests that can be completed within a controlled 2-day window without client impact.
Resolution SLA compliance should remain at 95% or higher. This is a team outcome driven by daily habits.
Notes are not “extra admin”. Notes enable instant handover and protect the business in disputes.
Minimum note standard (what every ticket must show)
- What was requested (in your own words).
- What you did (steps taken).
- What is outstanding (if anything).
- Who is responsible for the next step (you/client/third party).
- Next action + time expectation (so the queue stays controlled).
Public replies vs Internal notes (simple rule)
Quick Knowledge Check (instant feedback)
Choose answers, then click “Check answers”.
- Adding an internal note explaining you will respond later.
- Sending the first public response to the client.
- Changing the ticket status to “In Progress”.
- Leave it “Open” until the client responds.
- Change to Waiting/On Hold and add a note explaining what is outstanding and by when.
- Close the ticket so it’s out of your queue.
- High ≤ 6 hours, Medium ≤ 24 hours, Low ≤ 48 hours.
- High ≤ 48 hours, Medium ≤ 24 hours, Low ≤ 6 hours.
- All priorities must be resolved within 3 hours.
