Service Level Agreements in Zoho

SLA Basics — What it Means & Why It Matters

Internal Training • Cases, Desk tickets, and Teamflect performance tracking

Outcome: you understand SLA terms and how your actions affect results

Lesson Audio

Press play to listen.

What is an SLA?

SLA stands for Service Level Agreement. It is a set of agreed service rules that define how quickly we respond and how quickly we resolve client requests. In our environment, SLA is measured through Cases (CRM), Desk tickets (support), and the data may feed into Teamflect for performance tracking.

SLA answers: “How fast must we respond?”
SLA answers: “How fast must we resolve?”
You control: logging, status, priority, timestamps

Why this lesson matters

  • Clients judge us by response + follow-through
  • Managers use SLA to see bottlenecks
  • Teamflect uses accurate data for fair performance
  • Incorrect statuses and late logging make reports meaningless
Simple idea: SLA only works when our case/ticket data is correct.

Key SLA words you must know

These are basic terms you will see in Cases, Desk, reports, and Teamflect.

First Response

Speed

The time it takes to acknowledge the client after the request is received. Example: “Thanks, we have received your request. We are working on it.”

Resolution

Completion

The time it takes to finish the work and deliver the outcome (submission done, problem solved, client informed).

Breached SLA

Risk

When response or resolution is late compared to the SLA target. This affects reporting, client trust, and performance measurement.

Priority

Urgency

A label that helps decide what must be done first. Priority should be based on urgency + impact + deadline, not emotion.

Status

Truth

The “truth label” of the work: Open, Awaiting Client, Escalated, On Hold, Closed. Wrong status = wrong SLA data.

Timestamps

Evidence

The date/time fields that show when something happened. SLA reporting relies on accurate timestamps (often to the minute).

Remember: SLA is not only about “speed” — it’s about reliable service and trustworthy reporting.

SLA in the context of Cases and Desk tickets

Same concept, different tools: SLA is measured by how you log and work the item.

How SLA works with a Case (CRM)
›

A Case is used to track work that must be completed (filings, updates, onboarding/offboarding, compliance requests, follow-ups). SLA uses your case data to measure response and resolution.

  • Date/Time Logged: when the request was received (must be accurate)
  • Status: must reflect reality (Open vs Awaiting Client, etc.)
  • Owner: who is responsible to drive it forward
  • Closure date/time: when work was truly completed
Common SLA mistake: logging a case late. It makes “Time to Respond” look better or worse than reality — unfair and inaccurate.
How SLA works with a Desk ticket (Support)
›

A Desk ticket is usually used for service/support requests (client queries, system issues, portal problems, general support). The ticket often has an SLA that measures:

  • First Response SLA: how quickly you acknowledge
  • Resolution SLA: how quickly you solve
Simple rule: If the ticket is waiting for the client, update status correctly and note what you requested.
Why “status truth” protects SLA data
›

SLA reports assume that status changes are truthful. For example:

  • Open = we are working / must work next
  • Awaiting Client = we cannot proceed (blocked by client)
  • Escalated = manager intervention is required
  • Closed = fully resolved and documented
Bad habit: using “Awaiting Client” to stop the SLA clock when you are not actually blocked.

How SLA links to Teamflect (performance)

Teamflect performance goals are only fair when the underlying data is accurate.

What Teamflect typically measures from SLA data
›

In simple terms, Teamflect may use metrics like:

  • How many cases/tickets were handled
  • Whether first response was within the target time (example: within 3 hours)
  • Whether resolution was within the target SLA
  • How often items were reopened or left incomplete
Fairness rule: correct “Logged By”, correct timestamps, and truthful statuses protect your performance results.
What you control daily (your SLA checklist)
›
  • Log the Case/ticket same day the request is received
  • Capture accurate date/time (to the minute when required)
  • Use the correct priority (based on urgency/impact/SLA)
  • Keep status truthful (Open vs Awaiting Client, etc.)
  • Write clear internal comments (actions, dates, refs, next steps)
  • Close only when fully resolved and documented
Shortcut that breaks SLA: leaving work “unlogged” in chats, then capturing later.

Simple scenario: how SLA is measured

Read this like a story. You will see how SLA gets calculated.

Scenario: Client requests a CIPC filing

The client emails at 10:00. Our first response SLA target is within 3 hours.

  • 10:00 — Request received. You create a Case with Date/Time Logged = 10:00.
  • 10:25 — You acknowledge the email (first response). SLA response is met.
  • 11:40 — You request missing documents. Status becomes Awaiting Client (you are truly blocked).
  • 14:10 — Client sends documents. Status returns to Open and work continues.
  • 15:30 — Filing completed. You write the Solution + capture reference. Status becomes Closed.
Key point: This only works if timestamps + statuses are truthful and captured at the right time.

Mini Quiz — SLA Basics

Check if you understand the key ideas.

1) SLA stands for:

2) First Response is:

3) Which behaviour damages SLA reporting most?

4) “Awaiting Client” should be used when:

Nkwali Compliance Consultants • Internal Training
SLA Basics • Cases • Desk • Teamflect

Previous Topic
Back to Lesson