rubierosa.levi@concentrix.com — Coaching Report

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

At a Glance

Scorecard

Scores reflect the average across 7 calls reviewed. Overall scores ranged from 1.1 to 3.0.

This Week's Coverage

Models Supported

Product model data not available for this week.

Problem Categories

ACCESS calls performed below expectations (avg overall 1.47). This category requires focused attention next week, particularly around accurate device-specific guidance and effective troubleshooting paths.

What Went Well

No transcript highlights available for this week.

Growth Opportunities

1. Strengthen accuracy in ACCESS category calls

The ACCESS category showed the lowest performance this week (avg overall 1.47). Focus on gathering complete device information early, verifying LED states, and confirming basic connectivity before diving into advanced troubleshooting.

Next step: Before suggesting resets or advanced steps, always confirm:

• Device model and serial number
• LED status and WAN connectivity
• Basic internet access via wired connection

2. Improve protocol compliance in escalation-prone calls

Two escalations this week both originated from ACCESS calls with protocol deviations. Ensure clear documentation, concise next steps, and appropriate handoff when escalation is necessary.

Next step: When escalation is required:

• Document exact symptoms and steps already taken
• Provide concise “next step” instructions to L2
• Confirm customer understands the handoff process

Next Week's Focus

1. Start every ACCESS call with a device checklist – model, serial, LED status, WAN link, and basic connectivity test. This prevents premature troubleshooting and builds a solid diagnostic foundation.
2. Limit resets to last-resort actions – verify configuration and connectivity first, and always explain why a reset is being suggested.
3. Standardize escalation documentation – use a consistent template (symptoms → steps → next action) to ensure L2 receives actionable context.
4. Practice concise handoffs – keep escalation notes under 4 bullet points for clarity and speed.

Technical Accuracy

Improvement

Incorrect bridge mode configuration attempted on MX2000 - bridge mode is unsupported for Velop MX series (KB states it's for EA/MR/WHW series only)

Improvement

Wrong wiring topology - instructed to connect MX2000 WAN port to Asus LAN port creating double-NAT instead of proper bridge configuration

Improvement

Provided incorrect default router password (admin) for MBE7000; correct default is same as Wi-Fi password with username root

Improvement

Instructed customer to access http://[REDACTED_PHONE] instead of https://[REDACTED_PHONE] for OpenWRT-based MBE7000

Improvement

Provided wrong admin URLs ([REDACTED_PHONE], myrouter.local) for SPNMX42 - KB states http://myrouter.info is required

Improvement

Provided wrong reset procedure (20-second press, pink light) for SPNMX42 - KB states 10-second press is required

Improvement

Fabricated technical explanation claiming error 2123 is caused by 'merchant file' with 'invalid syntax' - not a real Linksys system component

Improvement

Directed customer to linksysmartwifi.com for local router login - incorrect, should be myrouter.local or [REDACTED_PHONE]

Improvement

Failed to acknowledge customer's explicit statement that child node was not connecting to parent - incorrectly validated setup as 'good'

Improvement

Instructed 1-minute hard reset instead of KB-standard 10-15 seconds for SPNM62CF

Improvement

Instructed 3-second Pair button press instead of KB-standard 1 second for SPNM62CF node pairing

Coaching Moments

Escalation Lessons: What L2 Did

#TE00130835 — Resolved by Level 2

What L1 saw: Customer couldn’t log into Linksys app using default password printed on SPNM42 router. L1 attempted multiple incorrect URLs and reset procedures without success over 48 minutes.

Why it escalated: L1 provided factually wrong technical guidance (incorrect URLs, reset steps, and CMD instructions) and failed to resolve after extensive troubleshooting.

Related call chain: This was the initial and only contact for this case – L1 handled the entire interaction before escalating.

What L2 did: L2 performed a callback, verified router model, and guided the customer through the correct reset procedure (10-second press) and admin URL (http://myrouter.info). L2 also confirmed warranty status and offered replacement if needed.

Current state: Resolved – customer successfully logged in after L2 guidance.

L1 learning points:

1. Always verify model-specific admin URLs before instructing login (SPNM42 requires http://myrouter.info).
2. Use the correct reset duration (10 seconds for SPNM42) and confirm LED behavior.
3. Collect serial number early to enable warranty checks during troubleshooting.

#TE00130994 — Resolved by Level 2

What L1 saw: MX6200 user reported error 2123 in Linksys app with zero devices shown. L1 insisted on node restart despite customer refusal and offered no alternative path, failing to act on request to review app logs.

Why it escalated: L1 provided a fabricated technical explanation for error 2123 and directed the customer to an incorrect URL (linksysmartwifi.com), stalling troubleshooting.

Related call chain: This was a follow-up after an earlier unresolved call handled by another agent. The customer had already contacted support once without resolution.

What L2 did: L2 reviewed the case, requested sysinfo logs via email, and scheduled follow-up callbacks. After receiving logs, L2 identified the issue as related to a known firmware bug (QUALITY-815) and provided a firmware update path.

Current state: Resolved – customer updated firmware and regained app functionality.

L1 learning points:

1. Never fabricate error explanations – refer to KB or escalate when uncertain.
2. Always collect device logs when customers request developer review.
3. For MX series app issues, consider firmware bugs and have a clear update path ready.

Coach Appendix

Key trend: Accuracy and protocol scores are consistently low, especially in ACCESS category calls. The two escalations this week both originated from ACCESS issues involving incorrect technical guidance. Focus next week on strengthening device-specific knowledge and protocol compliance for ACCESS cases.

Pattern to watch: Multiple calls involved providing incorrect default credentials, URLs, or reset procedures for specific models. This suggests a need for more model-specific scripting and KB reference checks before guidance.

This Week's Calls