KB 308810 - MBUZZ – Incident Handling & Escalation Procedure

KB 308810 - MBUZZ – Incident Handling & Escalation Procedure

MBUZZ – Incident Handling & Escalation Procedure

1. Purpose

This document defines the standard incident handling process for MBUZZ Support, ensuring:

  • Timely first response within SLA

  • Clear ownership and accountability

  • Structured troubleshooting and documentation

  • Proper guidance and escalation flow (L1 → L2 → L3 →  Vendor Engineering)

  • High customer satisfaction and communication quality

2. Scope

This procedure applies to:

  • All MBUZZ Support Engineers (L1 / L2 / L3)

  • All incident severities (Sev1–Sev5)

  • All customer types (Standard, Premium, Managed Care, Strategic Accounts)

3. Incident Lifecycle Overview

  1. Incident Creation

  2. Initial Response

  3. Troubleshooting & Data Collection

  4. Guidance / Escalation (if required)

  5. Resolution or Workaround

  6. Customer Confirmation

  7. Closure & Documentation

4. Initial Incident Handling

4.1 SLA Commitment

  • Sev 1 – Immediate engagement (≤ 1 hour escalation if required)

  • Sev 2 – Escalation if unresolved within 5 working days

  • Sev 3+ – Guidance-based resolution

The initial response must:

  • Acknowledge the issue

  • Confirm ownership

  • Clarify severity

  • Set next steps

4.2 Initial Response Approaches

A. Response-Time Driven (Urgent / Critical Issues)

Use when:

  • Customer expresses urgency

  • Project/revenue impact

  • More info required

Process:

  1. Call customer within 5–15 minutes.

  2. Define problem clearly.

  3. Send formal initial response email (via ticketing system).

  4. Document findings in case.

B. Response-Completeness Driven (Quick Resolution Possible)

Use when:

  • Known issue

  • KB solution exists

  • No urgency expressed

Process:

  1. Perform quick research.

  2. Provide complete solution within 1 hour.

  3. Optionally follow up via call.

  4. Document clearly.

5. Troubleshooting Standards

Before requesting guidance or escalation, the following must be completed:

Required Documentation

  • Clear problem statement

  • Environment details (version, deployment type, OS, topology)

  • Severity & business impact

  • Steps to reproduce

  • Logs / support files

  • Screenshots / packet captures (if applicable)

  • Actions already taken

  • Customer temperament/priority

All information must be summarized in the Troubleshooting Notes section.

6. Severity Definitions

SeverityDefinitionEscalation Rule
Sev 1Production Down / Critical Revenue ImpactEscalate within 1 hour
Sev 2Major Feature ImpactEscalate within 5 days if unresolved
Sev 3Partial ImpactGuidance only
Sev 4Minor IssueGuidance only
Sev 5EnhancementRoute to Product/Enhancement Queue

7. Guidance Process (L1 → L2 / L2 → L3)

7.1 When to Request Guidance

  • SLA nearing breach

  • Reproducible defect suspected

  • Sales or Customer escalation request

  • Additional expertise required

  • Patch validation required

7.2 Guidance Request Requirements

Before requesting guidance:

  • Summary with customer priority

  • Detailed steps taken

  • Resources searched (KB, internal docs)

  • Logs attached or referenced

  • Accurate product & severity classification

7.3 Email Subject Format

Guidance – Incident# – Short Issue Description

Example:

Guidance – INC12345 – Packet Loss After Upgrade

7.4 System Field Updates

When requesting guidance:

  • Set status to Research

  • Toggle Guidance Requested fields

  • Add date of request

  • Ensure complete data is attached

When providing guidance:

  • Update Guidance Provided field

  • Set case to Pending Tech

  • Document next steps clearly

8. Escalation to Engineering (L3 Only)

8.1 When to Escalate

  • Sev1 or Sev2 requiring engineering expertise

  • Confirmed product defect

  • Reproducible issue

  • Management approval

  • Managed Care or Red Flag cases

8.2 Mandatory Escalation Requirements

Failure to provide complete data may result in removal from escalation queue.

Required:

  • Full troubleshooting summary

  • Reproduction steps

  • Logs & tech support

  • Performance metrics (if applicable)

  • Bug/Jira reference (if defect confirmed)

  • Clear Escalation Notes (date + initials format)

  • Current status and next steps at top

8.3 Escalation Workflow (Sev 1)

  1. Notify Engineering Management via email.

  2. Follow up with phone call.

  3. Document:

    • Date to Engineering

    • Assigned Engineer

    • Esc Status = Pending ENG

  4. Establish WebEx if required.

  5. Continue daily follow-ups.

8.4 Escalation Workflow (Sev 2)

  1. Email Engineering contact.

  2. Document full problem restatement.

  3. Update Escalation fields.

  4. Continue structured follow-up.

8.5 Pending Patch Management

  • Only use Pending Patch when release date is committed.

  • Bug/Jira must be linked.

  • Update release date field.

  • Keep Esc Notes current.

9. Inter-Team Communication Standards

L3 Guidance Expectations

  • Accept guidance requests same day.

  • Update Guidance Provided field immediately.

  • Remain guidance owner until case closes or escalates.

  • Attend escalation meetings if case is listed.

  • If unavailable, update case prior to meeting.

10. Customer Communication Standards

During Incident:

  • Acknowledge quickly

  • Provide frequent updates (Sev1 – daily or more)

  • Set clear next steps

  • Avoid defensive language

  • Apologize for inconvenience when appropriate

If Customer Requests Escalation

  • Document request

  • Confirm expectation

  • Follow formal escalation process

  • Update severity if workaround exists

11. Survey & Dissatisfaction Handling

If a negative survey is received:

  1. Manager reviews case.

  2. Call customer.

  3. Document feedback.

  4. Define corrective action.

  5. Send follow-up email.

  6. Close feedback case.

12. Off-Hours & Holiday Escalation

For critical Sev1 issues:

  • Contact After-Hours Management

  • Notify escalation POC

  • Document all attempts

  • Ensure handoff notes are complete

13. Quality Control Checklist (Before Closure)

  • Problem clearly documented

  • Resolution documented

  • Workaround explained

  • Logs attached

  • Knowledge Article created (if applicable)

  • Customer confirmation received

  • Case summary updated

14. Reporting & Metrics

MBUZZ Support tracks:

  • First Response SLA

  • Escalation Aging

  • Guidance Response Time (≤ 24 hrs)

  • Reopen Rate

  • Customer Satisfaction (CSAT)

  • Engineering Escalation Quality

15. Key Principles

  • One issue per incident (unless related)

  • Accurate severity classification

  • Data-driven escalation

  • Clear documentation

  • Proactive communication

  • Ownership mindset

16. Conclusion

This Incident Handling Procedure ensures that MBUZZ Support delivers:

  • Structured and consistent case management

  • High-quality escalations

  • Clear inter-team collaboration

  • Strong customer experience