zhiliang.chen@concentrix.com — Coaching Report

Week of 2026-05-25 – 2026-05-31

At a Glance

Scorecard

Scores reflect 1 call reviewed. Overall score range: 1.10 (lowest) – 1.10 (highest).

This Week's Coverage

Models Supported

Model-specific note:

The single MBE7000 call scored well below expectations (1.1 overall). This suggests a need for deeper familiarity with MBE7000 troubleshooting flows, especially for performance and connectivity issues.

Problem Categories

Category focus notes:

• CONNECTIVITY calls are flagged for deeper review. The low average score (1.1) highlights gaps in protocol adherence and technical accuracy for this category.

What Went Well

There were no explicit strengths highlighted in the data for this week. The single call required significant improvement across multiple dimensions. Next week’s focus will be on building foundational strengths in technical accuracy, protocol adherence, and clear communication.

Growth Opportunities

1. Technical Accuracy and Protocol Adherence

Improvement

Agent provided factually incorrect technical explanations — for example, stating that Wi‑Fi is “half‑duplex” and that its “actual output is 1200 Mbps.” Wi‑Fi is full‑duplex, and this mischaracterization undermines customer confidence and complicates troubleshooting. Additionally, the agent referenced a non‑existent “connector” that could be “reduced” to improve speed — a term with no basis in Linksys KB articles.

What good looks like:

• Verify the exact router model and firmware before discussing performance characteristics.
• Use KB articles (e.g., universal_speed_performance.md, universal_speed_diagnosis.md) to guide explanations of Wi‑Fi technical behavior.
• Avoid inventing terms or concepts not documented in Linksys knowledge base resources.

2. Operational Closure and Escalation

Improvement

The agent promised an undefined “upgrade” but took no concrete steps to escalate, schedule follow‑up, or document a clear next action. The call closed with an abandoned_or_vague status, leaving the customer without a path forward.

What good looks like:

• When a case exceeds your scope, initiate escalation using the standard process: document the issue in HappyFox, assign to Level 2 with clear notes, and confirm the next steps with the customer (e.g., callback time, email follow‑up).
• Always set a concrete expectation for the customer — for example, “I’m escalating this to our advanced support team and will follow up with you by email within 24 hours.”
• Update the ticket status to escalated_correctly and include a summary of escalation reasoning and customer communications.

Next Week's Focus

• Start every performance‑issue call with model/firmware verification — this prevents mis‑directed troubleshooting and ensures you reference the correct KB articles.
• Practice the escalation script — rehearse the exact phrasing for handing off to Level 2, including timeline and contact method, so you can deliver it confidently and consistently.
• Review universal_speed_diagnosis.md and universal_speed_performance.md before handling any speed‑related cases — focus on the required baseline tests (wired speed test, firmware check, node placement).
• Add a brief “next‑step” note to every ticket you open, even if you’re escalating, to ensure continuity for the next agent or L2 engineer.

Technical Accuracy

Improvement

Note: Agent failed to identify or verify the customer's router model/family — a critical first step for any performance troubleshooting (contradicts KB universal_speed_diagnosis.md Step 1‑2).

Improvement

Note: Agent did not follow standard protocol for speed‑performance issues — no WAN speed verification, wired baseline test, reset, firmware check, or node placement guidance was performed (contradicts KB universal_speed_performance.md, universal_speed_diagnosis.md).

Improvement

Transcript Quote: [01:37] CHANNEL_RIGHT: Actually, it's like this: because Wi‑Fi wireless is half-duplex two-way communication, so its actual output is 1200 Mbps.

Note: Agent provided a factually incorrect technical explanation — Wi‑Fi is full‑duplex, not half‑duplex, and does not inherently halve advertised speed (contradicted by KB universal_speed_performance.md, universal_vpn_overhead.md).

Improvement

Note: Agent referenced a non‑existent “connector” that could be “reduced” to improve speed — a term with no support in any Linksys KB article.

Improvement

Note: Agent offered a vague “upgrade” without defining what it meant, how it would be initiated, or when follow‑up would occur — this violates KB guidance on escalation and follow‑up procedures.

Coaching Moments

Improvement

Transcript Quote: [01:37] CHANNEL_LEFT: I don't know what he's saying. He said from the main unit to the sub-unit, the sub-unit only has 500. But the main unit also only has 500. They said it's normal.

Note: The customer expressed confusion about the agent’s incorrect technical explanation. This moment underscores the impact of inaccurate information — it not only fails to resolve the issue but also leaves the customer doubting their own understanding. Next time, pause and verify any technical claim against the KB before sharing it with the customer.

Escalation Lessons: What L2 Did

#TE00129512 — Pending with Level 2

What L1 saw:

• Customer reported fluctuating Wi‑Fi speeds (60‑300 Mbps) on an MBE7000 router advertised for 500+ Mbps.
• Customer’s home is small (600 sq ft), and the issue persisted despite the router being high‑end.
• L1 attempted no baseline troubleshooting (no wired test, no firmware check, no node placement review) and offered only an undefined “upgrade.”

Why it escalated:

• The case was escalated due to unresolved performance issues and lack of a clear L1 resolution path. The escalation trigger was the agent’s failure to perform any diagnostic steps or provide a concrete next action.

Related call chain:

• This was the third contact for ticket #TE00129512. The first call (handled by another agent) closed as “resolved” after sending a firmware‑update email, but the customer returned days later with ongoing issues. The current agent (zhiliang.chen) closed the call as “abandoned_or_vague” after promising an undefined “upgrade,” prompting escalation.

What L2 did:

• L2 reviewed the case and requested detailed network topology and sysinfo logs.
• L2 clarified that iPhones cannot display link speed, suggesting additional client devices for testing.
• L2 asked the customer to delete preferred networks and connect only to the 6GHz SSID for isolation.
• L2 also requested that the customer separate the three frequency bands (2.4GHz, 5GHz, 6GHz) with distinct SSID names to identify band-specific performance.

Current state:

• The case remains pending with Level 2. L2 is awaiting the customer’s response with the requested diagnostic information (topology, sysinfo logs, and test results).

L1 learning points:

1. Always start performance troubleshooting with the model/firmware verification — this ensures you reference the correct KB articles and avoids mis‑directed advice.
2. Perform baseline tests before discussing speed — a wired speed test establishes the WAN connection quality, and a firmware check ensures the router is up to date.
3. When escalation is necessary, use the standard process: document the issue in HappyFox, assign to Level 2 with clear notes (e.g., “Customer reports fluctuating speeds; no baseline tests performed; requires topology and sysinfo logs”), and set a concrete expectation for the customer (e.g., “I’m escalating this and will follow up by email within 24 hours”).
4. Avoid vague promises — “upgrade” is not a defined support action. Use precise language: “I’ll escalate this to our advanced support team for further diagnosis.”

Coach Appendix

Highest-signal weekly trend: The single call this week highlights a critical gap in technical accuracy and escalation procedure for performance‑issue cases. The agent’s reliance on incorrect explanations and vague promises led to an unresolved case and an escalation. Focus for next week should be on grounding every performance‑troubleshooting step in the relevant KB articles, verifying model/firmware up front, and using the defined escalation script when handing off to Level 2.

This Week's Calls