Purpose of the Document
This document is a standardized guide for Line 1 (L1) support agents, outlining the process for diagnosing and handling customer reports of a white page issue in the PHQ (PhoneHQ) application. The procedure ensures consistency in diagnostic actions, accurate data collection, and efficient escalation to Line 2 (L2) when necessary. It is intended for L1 agents and can be utilized by AI systems. Adhering to this procedure enables quick resolution of tickets, effective knowledge management within the organization, and provides L2 with complete information for technical analysis.
Scope of the Procedure
The procedure addresses the technical issue of a blank, white page appearing, which prevents the customer from accessing or using the PHQ web interface. It covers the entire cycle of handling a ticket at the L1 level: from verification and diagnosis, through data collection, to escalation to L2 via the ClickUp platform when advanced intervention is required.
Purpose of the Diagnostic Phase
The diagnostic phase aims to confirm the issue reported by the customer, collect key data by the L1 agent, and determine whether the problem is system-wide, user-specific, or requires L2 analysis. It includes initial checks aligned with L2 requirements.
Step 1: Verify Reproducibility of the Issue (on Support Account)
Action: Log in to the support test account (e.g., agent@phonehq.com, password: Safe.1234 - verify current login credentials). Replicate the workflow described by the customer that leads to the white page in PHQ.
Justification: This verification helps distinguish between a system error (reproducible on the test account) and a user-specific issue (not reproducible). If the issue occurs on the test account, it may indicate a broader fault requiring urgent escalation. If not, the cause might be the customer’s specific environment, guiding further diagnostics.
Documentation: Record the result as "Yes," "No," or "Sporadically" - mandatory for L2.
Step 2: Check Customer's Login Status
Action: Ask the customer if they were logged in to PHQ at the time of the issue. If administrative tools are available, check the customer’s session status in the system.
Justification: PHQ requires authentication, and session errors may result in a white screen instead of an error message. Early verification can exclude simple session issues before proceeding with further diagnostics.
Documentation: Record the status as "Yes," "No," or "Unknown" - mandatory for L2.
Step 3: Collect Customer's Environment Information
Action: Request technical details from the customer:
Browser: Type and version (e.g., Chrome 125.0.6422.112).
Operating System: Name and version (e.g., Windows 11 Pro 23H2).
Device: Type (e.g., laptop, tablet).
Application Version: For PHQ, this refers to the browser version; note any plugins if mentioned.
Network Type: WiFi or LTE/5G; encourage testing on both if possible.
Justification: Environmental factors often cause front-end errors such as a white screen. This data assists L2 in identifying patterns or eliminating factors like unstable networks.
Documentation: Record environment details; browser and operating system are mandatory, network and device are recommended.
Step 4: Analyze Browser-Side Errors (Developer Console)
Action: If the issue persists or is not reproducible on the test account, instruct the customer to open Developer Tools (F12), navigate to the "Console" tab, and capture a screenshot showing the URL and any errors (red messages). Multiple screenshots may be necessary.
Justification: The console reveals JavaScript errors, network issues, or CORS problems, which are crucial for L2 debugging. A screenshot with the URL confirms the context of the issue.
Documentation: Prepare console screenshots for escalation - mandatory for L2.
Step 5: Determine the Scope of the Issue
Action: Check monitoring tools, recent reports, or consult with the L1 team to ascertain if other customers are reporting similar issues.
Justification: Differentiating between an isolated incident and a widespread problem helps prioritize escalation. Multiple reports may indicate a system failure requiring immediate attention.
Documentation: Record the scope as "Isolated," "Widespread," or "Unknown" - mandatory for L2.
Importance of Complete Data
Accurate data collection at the L1 level is crucial for L2 efficiency. Standardization ensures a consistent set of information, accelerating analysis. Missing data leads to delays and additional queries to L1.
Checklist Table of Required Data for L2 Escalation
The table below summarizes the mandatory and recommended data for escalation:
|
| DataStatusDescription |
Customer Domain | Mandatory | Unique account identifier (e.g., yhgck) |
Customer ID | Mandatory | User's email (e.g., jan.kowalski@abccompany.com) |
Customer Name | Mandatory | Company name |
Exact URL | Mandatory | Address of the problematic page |
Console Screenshot(s) | Mandatory | With errors and URL |
Reproducibility | Mandatory | "Yes," "No," "Sporadically" |
Login Status | Mandatory | "Yes," "No," "Unknown" |
Scope Assessment | Mandatory | "Isolated," "Widespread," "Unknown" |
Customer's Browser | Mandatory | Type and version |
Operating System | Mandatory | Name and version |
Problem Description | Mandatory | Details from the customer |
Confirmation by L1 | Mandatory | How the issue was confirmed |
Steps to Reproduce | Mandatory | Detailed steps or "Not Reproducible" |
Customer's Device | Recommended | Type of device |
Network Type | Recommended | WiFi or LTE/5G |
Note: "Customer Domain" identifies the client’s instance (e.g., tenant ID), and "Customer ID" is the user’s email - both are crucial for L2.
When to Escalate
Escalate after completing diagnostics and data collection if:
The issue is reproducible on the test account but unclear or not fixable by L1.
The issue is not reproducible, but the customer’s console shows front-end errors.
The issue affects multiple users.
L1 diagnostics are inconclusive.
Escalation Platform
Use ClickUp, in the "2nd line" section.
Importance of a Structured Ticket
A complete ticket adhering to L2 standards accelerates engineers’ work and minimizes delays. Dedicated fields and format facilitate analysis and automation.
Procedure for Creating a Ticket in ClickUp
Template: Use the L2 template if available.
Title: Format: [PHQ] White Page - [Brief Description] - Domain: [Customer Domain]
Example: [PHQ] White Page - After Login - Domain: abcde
Assignment: Leave blank or assign as per L2 guidelines.
Dedicated Fields: Fill in, especially "Customer Domain."
Task Description:
Problem: Customer’s description (context, steps, customer actions, Customer ID).
L1 Diagnostic Results: Reproducibility, login status, scope, environment, customer name.
Confirmation by Support: How the issue was confirmed.
Steps to Reproduce: Detailed steps or "Not Reproducible" + customer’s steps.
Time of Occurrence: Date and time of the issue (time zone if known).
Business Impact: Impact on the customer (e.g., "Critical").
Console Analysis: Key errors (full logs in attachment).
Attachments: Console screenshots (with URL), optionally white page screenshot, link to customer’s ticket.
Title: [PHQ] White Page - After Login, Before Dashboard - Domain: xcvbg.com
Assigned: (Blank or as per L2 guidelines)
Customer Domain: xcvbg
Description:
Problem: Customer (jan.kowalski@xcvbg.com) reports a white page after logging into PHQ, blocking the dashboard. The issue started on 15.05.2024, around 10:00 CET. The system previously worked fine, with no changes on the customer’s side.
L1 Diagnostic Results:
Reproducibility: No
Login Status: Yes
Scope: Isolated (one report)
Environment: Chrome 125.0.6422.112, Windows 11 Pro 23H2, Dell laptop, WiFi
Customer Name: XCVBG Sp. z o.o., Plan: Enterprise
Confirmation by Support: Not reproducible on agent@phonehq.com, but the customer provided console screenshots with JavaScript errors (Uncaught TypeError).
Steps to Reproduce:
Go to phonehq.com.
Log in as jan.kowalski@xcvbg.com.
After authentication (redirect to dashboard), a white screen appears. The issue persists in Incognito mode and after clearing cache; same in Firefox 126.0.
Time of Occurrence: 15.05.2024, 10:00 CET
Business Impact: High - user cannot work.
Console Analysis: Errors: Uncaught TypeError: Cannot read properties of undefined (reading 'dashboard') at DashboardView.js:243:19.
Attachments: console_errors_xcvbg.png, white_page_xcvbg.png, [link to customer’s ticket].
Summary of Key Points
The procedure ensures efficient ticket handling through:
Systematic diagnostics (reproducibility, login status, environment, console, scope).
Complete data collection with a checklist table.
Compliance with L2 requirements in ClickUp.
Best Practices
Accuracy: Collect all data before escalation to avoid delays.
Communication: Explain to the customer the need for technical data to build trust.
Improvement: Provide feedback on the procedure to enhance it.
Knowledge Base: Check the history of tickets before escalation.
Final Thought
Adhering to this guide by L1 and AI systems reduces resolution time, increases L2 efficiency, enhances customer satisfaction, and builds a knowledge base. Standardizing data is key to successful technical support.
