girlyjoy.pocot@concentrix.com — Coaching Report

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

At a Glance

Scorecard

25 calls reviewed this week. Overall scores ranged from 1.3 (lowest) to 4.4 (highest), showing meaningful variation — the high end of that range is where we want to build toward consistently.

This Week's Coverage

Models Supported

Models to watch:

• EA8100 (avg 1.60) — Both EA8100 calls ended without resolution or a clear next step, suggesting some uncertainty around this router's setup and connectivity flow. Reviewing the EA8100 quick-start and factory reset process before the next shift would help.
• EA7300 (avg 1.60) and EA7430 (avg 1.60) — Single-call samples, but both ended with the agent declining further support or leaving the customer to self-resolve. These are standard dual-band routers with well-documented troubleshooting paths — worth a quick review of the connectivity checklist for these models.
• MX5500 (avg 1.50) — The one call on this model ended with the customer being directed toward purchasing incompatible nodes (VLP01). Familiarity with which node families are compatible with the MX5500 ecosystem will prevent this from recurring.
• E1000 (avg 1.30) — The lowest-scoring call this week. The E1000 is an older device; knowing the OOW policy and what limited troubleshooting is still appropriate will help set the right expectations with customers.

Problem Categories

CONNECTIVITY (drill-down): Ten connectivity calls with an average of 2.20 is the week's biggest opportunity area. The pattern across these calls is a tendency to reach for email instructions or paid-support offers before exhausting live troubleshooting steps — power cycle sequences, LED state checks, modem handoff verification, and ISP isolation. The goal is to stay on the call with the customer through at least one full troubleshooting cycle before closing or escalating.

SETUP (drill-down): Setup calls averaged 2.40, which is closer to the middle of the range, but several ended without the agent verifying that the setup actually completed. The best setup calls this week (MR7350, MX2000) shared a common trait: the agent walked the customer to a specific, testable endpoint. That's the model to replicate — confirm the LED state, confirm the SSID is visible, confirm a device connects before closing.

What Went Well

No coaching_moments_json transcript highlights were available for this week's calls. The observations below are drawn from call outcomes and scorecard data.

1. Perfect documentation rate — every call has a ticket.

All 25 calls were documented in HappyFox this week. That's a 100% case documentation rate, which is exactly what the team needs to track patterns, support escalations, and protect customers. This kind of operational discipline is easy to overlook but genuinely matters — it means no customer falls through the cracks because there's no record of their call.

2. Best calls show what's possible — and the ceiling is high.

The week's top call, #LTS00037460, scored 4.4 overall — the highest score in this dataset. The outcome was clean: separate 2.4 GHz and 5 GHz SSIDs created, customer confirmed both networks visible, case closed correctly. That's a textbook resolution. Two other calls — #LTS00098076 and #LTS00131217 — both scored 3.4, with confirmed or likely-fixed outcomes. These calls prove the capability is there. The work this week is about making that standard more consistent.

3. Persistence on complex calls.

The longest call of the week — #LTS00131324 at nearly 55 minutes — ended with all mesh nodes re-added and internet working on the customer's laptop. That kind of patience and follow-through on a multi-node setup is genuinely hard, and it paid off with a confirmed fix. Similarly, #LTS00098076 ran nearly 40 minutes and ended with the 2.4 GHz network restored and a child node paired. Staying with a customer through a complex problem is a real skill — lean into it.

Growth Opportunities

1. Technical Accuracy — Know the product before recommending a path

The accuracy score this week was 2.30 across 25 calls, with 14 calls scoring accuracy at 1. The clearest example of what this looks like in practice: on #LTS00124287, a customer with an MX5500 was advised to purchase VLP01 nodes — a product from a different mesh ecosystem that is not compatible with the MX5500. The customer left the call planning to spend money on hardware that won't work.

No transcript highlights are available for this week, but the call outcomes tell the story: multiple calls ended with the agent offering generic email instructions rather than product-specific guidance, and at least one call included a factually incorrect product recommendation.

What good looks like: Before recommending any hardware purchase or add-on node, confirm the exact model number and verify compatibility in the Linksys support knowledge base. For mesh systems specifically, node compatibility is ecosystem-specific — WHW03 nodes pair with WHW03 parents, Velop AX nodes pair within the AX family, and so on. A quick model lookup before making a recommendation takes 30 seconds and prevents a customer from buying the wrong product.

Concrete next step: For the next two weeks, before recommending any add-on hardware or accessory on a call, verbally confirm the model number with the customer and cross-reference it against the compatibility list in the KB. If you're not certain, it's always better to say "let me verify that for you" than to guess.

2. Protocol Adherence — Close the loop before closing the call

The protocol score this week was 1.70 across 25 calls — the lowest dimension on the scorecard. The pattern is consistent: many calls ended with the agent promising to send an email and leaving the customer to self-resolve, without verifying whether the issue was actually fixed. On #LTS00130862, the agent asked the customer to perform another factory reset after the call with no confirmation scheduled. On #LTS00131238, reset instructions were emailed to an unconfirmed address with no follow-up. On #LTS00130911, generic setup instructions were emailed with no live verification of pairing.

What good looks like: The best calls this week all share one thing — the agent stayed on the line until there was a testable result. On #LTS00037460, the customer confirmed both SSIDs were visible before the call ended. On #LTS00098076, the child node was paired and devices could connect before closure. That's the standard: before ending a call, ask the customer to confirm the specific thing that was supposed to change — LED color, SSID visibility, a device connecting, a browser loading a page.

Concrete next step: Build a closing checklist into every call: (1) What was the problem? (2) What did we try? (3) Did it work — can the customer confirm right now? (4) If not confirmed, what is the specific next step and who is responsible for it? If the customer can't confirm the fix live, set a callback rather than leaving it open-ended. A callback is a better outcome than an email that may never be read.

Technical Accuracy

No technical accuracy issues flagged this week — solid performance on product and process references.

Note: The technical_coaching_moments array was empty in the pre-extracted insights for this week. The accuracy concerns described in Growth Opportunities are drawn from call outcome data and resolution notes rather than flagged transcript moments.

Coaching Moments

No coaching_moments_json entries were present in any call this week. No transcript-level coaching moments are available to reproduce.

Escalation Lessons: What L2 Did

#TE00130787 — Pending with Level 2

Product: WHW03 | Category: SETUP

What L1 saw:

The customer wanted to add a child node to an existing WHW03 (Velop) mesh system. L1 collected the serial number (20J20M32A07923), identified the ISP as AT&T, confirmed the parent node serial, and asked the customer to provide proof of purchase. The customer replied with an Amazon order link. L1 then began the node-pairing process — plugging the child node in near the parent — but the case exceeded the shift threshold before the pairing could be completed or verified.

Why it escalated:

The escalation note explicitly states "excessive threshold" — meaning the call ran past the agent's shift end time before the issue was resolved. The escalation was a time/shift constraint rather than a technical dead end. The L1 troubleshooting was in progress and had not reached a natural stopping point.

What L2 did:

The L2 handoff note tagged the case to specific L2 team members and summarized the completed steps. As of the available snapshot, no L2 agent has claimed the ticket and no resolution steps have been logged. The case is sitting in the escalation queue waiting to be picked up.

Current state: Pending with Level 2. No L2 action taken yet. Customer has a callback scheduled.

L1 learning points:

1. Document the exact pairing state before escalating. The ticket notes mention the child node was plugged in near the parent, but don't record the LED state at that moment (blinking, solid, pulsing). L2 needs to know exactly where in the pairing sequence the call stopped so they don't start from scratch. Next time: note the LED color and behavior of both parent and child node at the moment of handoff.

2. Capture the full topology upfront. The ticket has the child node serial but the parent node serial appears in the notes as a separate line item rather than in the structured fields. For WHW03 mesh setups, collect and document: parent node serial, child node serial(s), ISP, modem model if available, and current app version. This gives L2 everything they need without having to call the customer back for basics.

3. If you're approaching a shift threshold on a setup call, set a callback proactively. Rather than escalating mid-pairing, it's often better to reach a clean pause point — node plugged in and LED stable — document that state, and schedule a callback for the next available slot. This keeps the customer informed and avoids leaving L2 to pick up a call mid-sequence.

#TE00130963 — Pending with Level 2

Product: EA7430 | Category: CONNECTIVITY

What L1 saw:

The customer (EA7430, ISP: Spectrum) reported that internet went offline the previous night. The device was out of warranty. L1 initially closed the ticket as resolved after informing the customer of the OOW status and offering paid support — but the customer called back. On the callback, L1 found the router's LED was solid green, confirmed the SSID was showing as default, connected the customer's iPhone to the default Wi-Fi, and attempted to power cycle the modem — but the customer was concerned about losing the call. L1 scheduled a callback. On the second callback, L1 reset the router, connected the phone to the 5 GHz band, and found that some apps (Amazon, Walmart) were showing "no internet" while others worked. The Roku TV was also affected. After three factory resets and difficulty navigating the Linksys app with the customer, L1 escalated.

Why it escalated:

The issue persisted after multiple factory resets and power cycles. The customer had difficulty navigating the app and phone settings, which limited L1's ability to complete advanced diagnostics. L1 escalated for "Advanced TS" — the specific trigger was the selective app/device connectivity failure that didn't resolve with standard resets.

What L2 did:

L2 has been tagged for "Advanced TS" but has not yet logged any diagnostic steps or resolution actions. The ticket status moved from Resolved → Escalated. The case is waiting in the L2 queue.

Current state: Pending with Level 2. No L2 resolution steps logged yet.

L1 learning points:

1. Selective app/device failures on a working network point to DNS or QoS, not the router hardware. When a customer says "Amazon and Walmart don't work but other things do," that's a strong signal to check DNS settings on the router (is it using ISP-assigned DNS or a custom entry?), check for any parental controls or traffic prioritization rules, and verify whether the affected apps use specific ports that might be blocked by the ISP. A factory reset won't fix a DNS misconfiguration — it just resets it to DHCP-assigned DNS, which may have the same problem. Next time: before the third reset, ask "are there any parental controls or content filters set up on this router?"

2. Confirm modem/ISP handoff before resetting the router. The customer's modem was never successfully power cycled during this call because she was worried about losing the connection. A modem power cycle is often the single most effective step for "router was working, now it's not" connectivity failures — it forces the ISP to re-provision the WAN IP. If the customer can't do it live, schedule a callback for a time when they can, rather than moving straight to router resets.

3. Don't close a ticket as Resolved until the customer confirms the issue is fixed. The ticket was closed as Resolved at 21:25 after the OOW disclosure — but the customer called back because the issue wasn't resolved. Closing a ticket prematurely creates confusion for the customer and for L2. If the customer acknowledges OOW status and still wants to troubleshoot, keep the ticket open and document the continued troubleshooting. Only mark Resolved when the customer confirms the problem is gone.

This Week's Calls