Trial Demo
OwnerRez
Staff Reference » Helpdesk » Tier 3 Helpdesk
Updated today

T3 Engineer Support Guide

🔧 T3 Engineer Support Guide

Quick Navigation

Your Role as T3

T3 Scope: Dev research requiring technical investigation, changelog history, system process interactions, database/log checking, code reading, debugging, and partner integration testing.

What makes a ticket T3-level:

  • Requires reading changelog history (technical level)
  • Needs investigation of system process interactions
  • Requires checking database/logs
  • Code reading or stepping through a debugger
  • Testing partner integrations

Time Guidelines:

  • Research limit: 20 minutes without progress → escalate to T4
  • Total Ticket Limit: 60 minutes, even with progress → escalate to T4

  • Based on our time guidelines, a T3 engineer could theoretically handle up to ~20 tickets per day.
    In practice, T3 work also includes investigation, documentation, communication, partner testing, bug reporting, and Dev Phone-a-Friend support.
    Because of this, our healthy target during a T3 on-call week is typically around 20–30 resolved tickets per week, averaging 4–6 per day depending on complexity.
    This range balances responsiveness with thoughtful debugging, clear communication, and sustainable workload.

    Manage your time accordingly.

Daily Routine

Every Morning Checklist:

  • Check tickets in your queue
  • Check Dev Phone a Friend forum for new posts
  • After scanning both queues, prioritize the oldest first if possible, but also scan for easily answered ones that you can solve faster

Ticket Assignment & Tracking

When You Start Working a Ticket:

  • Assign it to yourself (creates tracking data point in Zoho)
  • Work through your investigation

When Providing Resolution:

  • Send your reply
  • Unassign yourself (marks ticket as resolved by you)

If Requesting More Info or Providing Update:

  • Keep yourself assigned
  • Allows tracking of your replies between engagement and resolution

End of Your T3 Week:

  • Filter for tickets assigned to you
  • Bulk reassign to "Engineering" queue
  • Shows clear handoff point

Ticket Handling Process

Step-by-Step Workflow:

  1. Read the escalation from T2
    • Look for ESCALATED QUESTION 1, 2, etc. headers
    • Review debugging details and where T2 got stuck

  2. Start your research
    • Check changelog history
    • Review database/logs
    • Debug code if necessary
    • Test partner integrations if relevant

  3. Monitor your time
    ⚠️ CRITICAL: If you've spent 20 minutes without making progress, STOP and escalate to T4 with your findings. Do not get stuck in research mode.

  4. Resolution path, choose one:
    • If you can answer: Respond directly to the user and unassign yourself when resolved
    • If you find a bug: Follow bug handling process below
    • If you're stuck: Escalate to T4
    • When escalating to T4: Add yourself as a watcher, if you feel there is more you can learn from the resolution

Handling Unrelated Questions on Same Ticket:

💡 Tip: If user asks an unrelated question:
  1. Use the Split Ticket button
  2. Reset new ticket to Team:Helpdesk with no agent
  3. Add internal note: "Split, unrelated question"
  4. Update ticket title to reflect new issue

When & How to Escalate to T4

When to Escalate:

  • You've researched for 20 minutes without progress
  • Even with progress, you have spent more than an hour of total time on an issue
  • You found a bug and need verification (after creating GH and DPAF entry)
  • Issue requires deeper system knowledge than you have
  • Database changes are needed
  • You're uncertain if a bug requires a hotfix

How to Escalate:

  1. Write clear escalation comment with headers:
    • ESCALATED QUESTION 1: [Your question]
    • ESCALATED QUESTION 2: [If applicable]

  2. Include your findings:
    • What you investigated
    • What you found
    • Where you got stuck
    • Relevant logs, database queries, code snippets

  3. Change escalation level to T4

  4. Add yourself as a watcher to learn from T4's resolution
Do not feel bad about escalating! The 20-minute rule exists to protect your time and get clients faster answers. T4 has deeper knowledge and can often shortcut the research.

Transition Comments & Communication

When Escalating to T4:

Write two comments:

  1. Internal escalation to T4 (as described above with ESCALATED QUESTION headers)
  2. User-facing comment that includes:
    • Notification that ticket was escalated to on-call engineer for deeper research
    • May take a few days for resolution
    • Summary of what you found so far and why deeper investigation is needed

Example user-facing comment:
"I've investigated this issue and found [summary of findings]. This requires deeper technical analysis, so I've escalated your ticket to our on-call engineer for further research. This may take a few additional days, but we will keep you updated on progress. Thank you for your patience!"

Missed SLA Status Updates:

At end of day, review your queue. If a ticket has been waiting more than 1 business day since the question arrived AND you will not resolve it that day:

  • Send a status update to the user
  • Reassure them you are still working the issue
  • Prevents users from going 3+ days without communication

Example status update:
"I wanted to provide you with a quick update, I am still actively investigating this issue. [Brief description of current progress]. I will continue working on this and will have more information for you soon. Thanks for your patience!"

Bug Discovery & Handling

Bug Handling Checklist:

  • Create a GitHub (GH) issue
  • Use the "DAPF" label in GH to cross-post the bug to the DPAF Forum if the bug is one that impacts end-users or support
  • If fix is straightforward: Create commit and PR
  • Escalate to T4 for verification
⚠️ IMPORTANT: When you create a bug, escalate to T4. T4 decides if it is an on-call hotfix or goes into normal bug flow.

Creating High-Quality DPAF / Known Issue Entries

This section explains how to write clear, consistent DPAF / Known Issue entries. Your goal is to help Support, Sales, Engineering, and Rezzy quickly understand what happened, who is affected, and whether they need to act.

Purpose of DPAF/KIT Entries: To provide clear and immediate visibility into known issues so all teams can understand what happened, what was fixed, and whether it affects their clients. A good entry saves time for Support, Sales, Engineering, and even Rezzy.

Why a Summary Matters

A DPAF entry without a summary forces everyone to click into GitHub, read the issue, interpret the fix, and decide whether it is relevant. That can turn a ten second glance into a multi minute task.

A short summary in the DPAF entry helps because it:

  • Gives instant context in the notification email
  • Improves search results when T1/T2 look up known issues
  • Increases transparency for non technical teams and Rezzie
  • Reduces total company time spent interpreting each change
  • Reinforces clear communication across teams
  • Helps Rezzy index and read the data.  Rezzy does not follow links

Even one sentence can save dozens of minutes across the company.

What Every DPAF Entry Must Include

DPAF Post Requirements

  • Clear title that matches the GitHub issue
  • Short summary copied from the GH description or rewritten to be clear and user friendly
  • One or two sentences explaining:
    • What the issue was
    • What behavior users may have seen
    • What the fix changes, if applicable

The Summary, Your Most Important Contribution

Your summary does not need to be long. It only needs to answer two things:

  1. What was broken?
  2. What is fixed or changing?

Most of the time, this can be copied directly from the GitHub Summary, with a tiny bit of editing for clarity.

Good vs. Bad Examples

❌ Minimal / Unhelpful ✅ Clear / Helpful

“Clicking the delete button does nothing.”

Fixed PM Statement Delete Button
Resolved an issue where the Delete button on PM Statements did not work. The button now correctly opens the confirmation modal so statements can be deleted as expected.

“Airbnb rate invert issue.”

Airbnb Channel Bridge Nightly Rate Adjustment
Corrected an issue where Channel Bridge would invert nightly rate adjustments under specific conditions. Imports now match Airbnb pricing accurately.

How to Write a Great DPAF Summary (3 Easy Steps)

  1. Copy the GH description.
    In almost every case, the GH Summary already says what needs to be said.
  2. Add one user friendly sentence.
    Translate dev wording into something Support and clients can understand.
    Example: “This caused guests to see blank room names on hosted sites.”

Standard Format Template

You can paste this template directly into new DPAF posts.

Summary:  
[One sentence copied from GitHub or rewritten clearly.]

Details:  
[Optional second sentence explaining impact or expected behavior.]

Example Using the Template

Summary:  
Fixed the Delete button on PM Statements that was not working. The button now correctly opens the confirmation modal.

Details:  
Users were unable to delete PM statements, which caused confusion during monthly reconciliation.

T3 is the bridge between Support and Engineering. Clear communication here helps everyone.

Quick Self Check

Before you post, ask yourself:

  • Would a T2 agent understand the issue just by reading the summary?
  • Would a Sales rep know how to explain this change to a client?
  • Would I be able to find this later using common search terms?

If yes, your DPAF entry is in good shape.

Non-Ticket Responsibilities

1. Dev Phone a Friend Forum

Monitor and respond to:

  • Questions: Answer directly
  • Bug reports:
    1. Determine if it is actually a bug
    2. If yes: Create GH issue
    3. Loop in T4 by setting topic status to Sysops Review to determine if hotfix-worthy

2. GVR Price Accuracy Issues

Your responsibilities:

Situation Action
New GVR price issue Debug and create GH if needed
Known issue (existing GH) Note on GH as additional example
Any new issue found • Let T2 know (Dev Phone a Friend forum)
• Update Known Issue Thread in DPAF
Bad issue requiring delisting Let T2 know to delist the account

Cross-Week Ticket Management

End of Your T3 Week:

  • Unfinished tickets
    • Leave open
    • Add internal note with your research/findings
    • Bulk reassign tickets assigned to you back to "Engineering" queue
    • Next week's T3 will pick up where you left off

Your SLA Targets (T3-Eng1)

Metric Green Target Yellow Warning Red Alert
Response Time Less than 1 business day Less than 2 business days More than 2 business days
Status Updates Update if >1 day and will not finish that day Update by EOD of day 2 Never go 3+ days silent

Time counted from when ticket first appears in T3 queue

Common Scenarios & Quick Answers

Scenario What You Do
"This ticket is taking me 25 minutes to research" If making progress, continue. If stuck, escalate to T4 with findings.
"I found what might be a bug" Create GH + Known Issue entry in forum → Escalate to T4 for verification
"T2 missed checking the docs" Do not escalate back, answer user yourself, but tag "Missed Doc Review" and add internal note
"User asked different question on same ticket" Split ticket → Reset to Team:Helpdesk → Add note explaining split
"I can fix this bug easily" Create commit and PR, but still escalate to T4 for review/verification
"It is Friday EOD and I am not done" Leave open with internal note of findings, bulk reassign your tickets to Engineering queue for next T3
"A ticket has been waiting 2 days" Send status update to user before EOD to prevent 3+ days of silence

Key Reminders

✅ Do:
  • Check tickets in the T3 Queue daily
  • Assign tickets to yourself when you start working on them
  • Escalate after 20 minutes if stuck
  • Add yourself as a watcher when escalating to T4 (learning opportunity)
  • Create GH + Known Issue entries for bugs before escalating
  • Monitor Dev Phone a Friend forum
  • Send status updates for tickets waiting more than 2 days
  • Follow tickets strategically: Follow any ticket where you got stuck, escalated to T4, or did not know the answer, this is your learning opportunity.