gerlie.miguello@concentrix.com — Coaching Report

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

At a Glance

Scorecard

Scores reflect a week with 34 calls reviewed. Overall scores ranged from 1.0 to 4.4.

This Week's Coverage

Models Supported

Key Pattern: Lower scores on MX2000 calls suggest a need for deeper familiarity with this model’s mesh behavior and troubleshooting paths.

Problem Categories

Drill-Down Insights:

• Connectivity issues (19 calls, avg 2.0) dominate the week. Common themes include WAN link failures, LED misinterpretations, and incomplete backhaul diagnostics. Focus on validating WAN status, LED meaning per model, and systematic backhaul checks.
• Setup calls (6 calls, avg 2.0) show inconsistent model identification and missing case documentation. Reinforce model confirmation and case creation protocols.
• Access issues (5 calls, avg 1.6) highlight password reset and admin UI navigation struggles. Emphasize secure password reset methods and correct local URL usage.

What Went Well

1. Accurate Model Identification

> “Okay, so you are trying to log in. Um, is it like remotely, sir? Since you mentioned that you, uh, can't access the account.”

#LTS00131382

The agent correctly identified the SPNMX55GC model from the serial number and guided the customer to local access, avoiding remote login pitfalls.

1. Effective Troubleshooting Guidance

> “Okay, so this is an SBMX 56 from a broadband. Uh, how about the active number of the H nodes share that you wanted to add?”

#LTS00131398

The agent successfully walked the customer through moving the node closer, resetting it, and using the Linksys app to re-add the node—a valid, KB-aligned path for mesh recovery.

Growth Opportunities

1. Correct Technical Instructions

> “The number of the LinCIS unit please? Yes. If you're on the app, you can see it under Network Administration.”

#LTS00131386

The agent provided inaccurate guidance on disabling the 5 GHz band and resetting the admin password. Next step: Always verify model-specific steps and use KB-approved methods for password resets and band management.

1. Protocol Adherence

> “We don’t update manually on our end.”

#LTS00131400

The agent failed to document a case or verify warranty status before discussing firmware updates. Next step: Create a HappyFox case for every customer interaction and confirm warranty eligibility early in the call.

Next Week's Focus

• Validate WAN and LED States First: Before diving into mesh or app troubleshooting, always confirm the WAN link (modem connectivity) and interpret LEDs according to the specific model’s KB.
• Model-Specific Reset Durations: Memorize and apply correct reset times (e.g., 10 seconds for SPNM/LN series, 15 seconds for MX/Velop) to avoid missteps.
• Case Creation Discipline: Open a HappyFox case for every call, capture serial numbers, and note warranty status—this ensures auditability and continuity.
• Secure Password Reset Paths: Use recovery keys or local admin access instead of assuming default passwords, and never share credentials over the phone.

Technical Accuracy

Improvement

Agent incorrectly assumed Wi‑Fi password was 'ATT' without verification, leading to customer confusion.

#LTS00130874

Improvement

No case was created or referenced during the call, violating protocol and leaving no audit trail.

#TE00130750

Improvement

Agent provided materially incorrect LED interpretation for MR20X, stating purple indicates “ready for setup” (Velop‑specific), but MR series routers use solid blue when ready.

#TE00130750

Improvement

Agent gave incorrect reset duration for SPNM devices (20 seconds instead of the required 10 seconds).

#LTS00130743

Improvement

Agent used incorrect admin URL for MBE-7000 (myrouter.info instead of myrouter.local or phone number), causing customer confusion and delaying troubleshooting.

#LTS00117507

Coaching Moments

Improvement

“Okay, so you are trying to log in. Um, is it like remotely, sir? Since you mentioned that you, uh, can't access the account.”

#LTS00131382

The agent misidentified the product as 'SBMX 56' — a non-existent Linksys model — leading to incorrect troubleshooting guidance. Always confirm the exact model number before proceeding.

Improvement

“The number of the LinCIS unit please? Yes. If you're on the app, you can see it under Network Administration.”

#LTS00131386

The agent provided inaccurate admin password complexity rules (10-digit with special character), which are not standard for any Linksys router and contradict KB guidance.

Improvement

“We don’t update manually on our end.”

#LTS00131400

The agent failed to verify warranty status or eligibility for support, missing a key protocol requirement. Always check warranty before discussing firmware updates.

Escalation Lessons: What L2 Did

#TE00130750 — Resolved by Level 2

• What L1 saw: Customer reported Wi‑Fi connectivity issues and a purple LED on an out‑of‑warranty MR20X router. L1 interpreted the purple LED incorrectly (Velop‑specific) and offered only paid support after payment failed.
• Why it escalated: L1 provided no technical troubleshooting, misapplied LED meaning, and failed to create a case or process payment correctly.
• Related call chain: This was a repeat contact; the customer had previously opened #LTS00130720 with the same issue but received no resolution.
• What L2 did: L2 clarified that purple is not a valid state for MR20X (solid blue indicates ready), guided the customer through basic WAN and reset checks, and offered self‑help paths before invoking paid support.
• Current state: Resolved after L2 validated connectivity and provided clear next steps.
• L1 learning points:

1. Interpret LEDs model‑specifically. MR series uses solid blue for ready; purple is Velop‑only.

2. Perform basic WAN and reset checks before offering paid support.

3. Create a HappyFox case for every interaction to maintain auditability.

#TE00130829 — Resolved by Level 2

• What L1 saw: Customer’s WHW03 child node lost connection; node was wired but showed solid red LED and kept reconnecting. L1 failed to confirm model, gave incorrect pairing instructions, and escalated after confusion.
• Why it escalated: L1 mixed 5‑press (Cognitive Mesh) and pair‑button (Velop) instructions without confirming device family, leading to customer frustration.
• Related call chain: This was a new escalation; no prior case existed.
• What L2 did: L2 identified the device as WHW03 (Velop), instructed a 10‑second reset, and guided the customer through WPS pairing. L2 also confirmed WAN connectivity and provided a callback timeframe.
• Current state: Resolved after L2 validated successful pairing and provided self‑help documentation.
• L1 learning points:

1. Confirm device family before giving pairing instructions. WHW03 uses WPS, not 5‑press.

2. Use model‑specific reset durations. WHW03 requires a 10‑second reset.

3. Validate WAN connectivity early to isolate backhaul issues.

#LTS00131009 — Resolved by Level 2

• What L1 saw: Customer couldn’t access the UI on their SPNMX42CF node; page showed a blue loading circle. L1 misidentified the product and referred to Community Fiber without internal troubleshooting.
• Why it escalated: L1 failed to perform basic UI access checks (browser clearance, alternative URLs) and did not create a case.
• Related call chain: This was a new contact; no prior case existed.
• What L2 did: L2 confirmed the node was SPNMX42CF, guided the customer through factory reset and alternative UI access (myrouter.local), and coordinated with Community Fiber for firmware assistance.
• Current state: Resolved after L2 provided clear internal and ISP escalation paths.
• L1 learning points:

1. Always attempt basic UI access troubleshooting (browser clearance, alternative URLs) before escalating.

2. Confirm product model before referring to ISP. SPNMX42CF requires specific internal steps.

3. Document every interaction in HappyFox to ensure continuity and avoid duplicate escalations.

#TE00131428 — Resolved by Level 2

• What L1 saw: Customer couldn’t add a third MX2000 node; it stayed blinking red/purple. L1 gave incorrect LED guidance and reset instructions, then escalated after confusion.
• Why it escalated: L1 provided wrong LED meanings and 15‑second reset duration for MX series nodes, leading to failed pairing attempts.
• Related call chain: This was a follow‑up to #LTS00131231, where L1 had previously attempted setup without resolution.
• What L2 did: L2 clarified MX2000 LED states (solid white = ready, blinking red = pairing), instructed a 10‑second reset, and guided the customer through web‑UI node addition. L2 also provided a detailed setup guide via email.
• Current state: Resolved after L2 validated successful node integration and provided self‑help resources.
• L1 learning points:

1. Use model‑specific LED references. MX2000 uses solid white for ready, not purple.

2. Apply correct reset durations. MX series nodes require a 10‑second reset.

3. Escalate only after exhausting model‑specific self‑help steps and document all actions in HappyFox.

Coach Appendix

• Primary weekly trend: High volume of connectivity and setup issues, particularly on MX2000 and WHW03 models, with recurring themes of incorrect LED interpretation, reset durations, and incomplete case documentation.
• Key coaching focus for next week: Reinforce model‑specific troubleshooting flows (especially for MX and WHW series), ensure every call results in a HappyFox case with serial/warranty capture, and eliminate LED and reset‑duration misconceptions through KB review and quizzing.
• Evidence highlighted: Calls #TE00130750 (LED misinterpretation), #LTS00130743 (incorrect reset duration), and #LTS00131009 (product misidentification) exemplify the most frequent technical and protocol gaps observed this week.

This Week's Calls

| [#TE00