rubierosa.levi@concentrix.com — Coaching Report

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

At a Glance

Work Mix Lens

• Frontline-heavy week: 5 LTS queue calls vs 2 TE-owned calls.
• Coach as a frontline agent: emphasize safe troubleshooting branches, closure hygiene, and clear customer-facing next steps.

Scorecard

Where Time Goes

Product Families

Key Observations

• SPN is the slowest family at 42m 42s; outlier: 1.5x weekly median handle time.
• MBE is one of the slowest families at 37m 30s.

Problem Categories

Week-over-Week Movement

• Accuracy moved down 0.55 vs. last week.
• Protocol moved up 0.21 vs. last week.
• Communication moved up 0.43 vs. last week.
• Average handle time moved up by 12m 42s.
• Family swing: SPN handle time moved up by 22m 01s vs. last week.
• Family swing: MX handle time moved up by 8m 40s vs. last week.

What Went Well

1. Clear communication under pressure

> "Yes, sir, that's good. Is, like, for example, um, the child node upstairs will connect to the child node downstairs, cuz, uh, that's in between, sir."

#LTS00130683

Consistently maintained polite, patient tone even when addressing complex mesh topology questions.

1. Effective ticket documentation

All 7 calls resulted in documented HappyFox cases with complete model/serial collection where applicable, ensuring continuity for follow-up.

Growth Opportunities

1. Technical accuracy in model-specific guidance

> "Provided wrong admin URL ([REDACTED_PHONE] - KB states [REDACTED_PHONE] or http://myrouter.info for SPNM)"

#TE00130835

Next step: Before instructing login access, verify model-specific admin URLs in KB (e.g., SPNM42 uses http://myrouter.info, MX6200 uses https://[REDACTED_PHONE]).

1. Protocol adherence for hardware issues

> "Did not collect product model, serial number, or warranty information — a fundamental protocol failure for hardware troubleshooting."

#LTS00130683

Next step: Always collect model, serial, and warranty status within the first 2 minutes of hardware-related calls to enable accurate support pathing.

Next Week's Focus

1. Model-specific verification: Cross-check KB for admin URLs, reset procedures, and pairing commands before guiding customers – especially for SPN/MX series.
2. Early information gathering: Script model/serial/warranty collection for all hardware and access issues in the first 3 minutes of the call.
3. Escalation readiness: When hitting technical limits (e.g., error 2123), document exact symptoms, collect sysinfo/logs, and hand off with clear L2-ready notes.
4. Closure hygiene: For unresolved cases, set explicit follow-up expectations (e.g., "I’ll email the KB article by EOD; please reply with results") and update HappyFox status accordingly.

Technical Accuracy

Improvement

"Agent provided incorrect admin URL for SPNM42 router, leading to unresolved access issue."

#TE00130835

Used [REDACTED_PHONE] instead of model-specific http://myrouter.info – caused 48-minute call without resolution.

Improvement

"Agent provided incorrect wiring topology for MX2000 setup, leading to unresolved connectivity issue."

#LTS00130689

Instructed MX2000 WAN → Asus LAN (creates double-NAT) instead of WAN → modem/ONT per KB universal_isp_compatibility.md.

Improvement

"Agent provided false technical explanation for error 2123, reflecting severe misunderstanding."

#TE00130994

Claimed error was due to “merchant file with invalid syntax” – no such component or error cause exists in Linksys systems.

Coaching Moments

No additional coaching moments were extracted after the technical review.

Escalation Lessons: What L2 Did

#TE00130835 — Resolved by Level 2

• What L1 saw: Customer couldn’t log into Linksys app admin despite correct password; SPNM42 router with solid blue LED but app showed “incorrect password”.
• Why it escalated: L1 provided invalid admin URLs (myrouter.local, [REDACTED_PHONE]) and incorrect reset procedure (20s press vs KB 10s).
• What L2 did:

- Verified correct admin URL (http://myrouter.info)

- Guided through proper 10s reset with pink light confirmation

- Confirmed warranty status and offered replacement if unresolved

• Current state: Resolved after callback and password reset confirmation.
• L1 learning points:

1. Always use model-specific admin URLs – SPNM42 ≠ MX6200.

2. Reset duration must match KB (10s for SPNM, not 20s).

3. Confirm LED states match expected behavior before declaring “invalid password”.

#TE00130994 — Resolved by Level 2

• What L1 saw: MX6200 showing error 2123 in app, zero devices online despite solid blue node LEDs.
• Why it escalated: L1 insisted on node restart without logging app behavior or addressing customer’s request for log review.
• What L2 did:

- Requested sysinfo logs via email

- Explained error 2123 often indicates cloud service discontinuity (Linksys Smart WiFi sunset)

- Guided through manual log collection and analysis

• Current state: Resolved after logs confirmed cloud service issue; customer retained local access.
• L1 learning points:

1. For error 2123, collect app logs before suggesting resets.

2. Acknowledge customer requests for developer review – offer log collection paths.

3. MX6200 may require local UI access (myrouter.local) if cloud services are discontinued.

Coach Appendix

Highest-signal trend: Persistent technical inaccuracies in model-specific guidance (URLs, resets, error explanations) caused extended handle times and unresolved issues. Prioritize KB verification for SPN/MX series before customer interaction. Protocol gaps in early information gathering (model/serial/warranty) also contributed to escalation volume. Focus next week on structured model-specific checklists and escalation documentation standards.

This Week's Calls