eric.marbella@concentrix.com — Coaching Report

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

At a Glance

Scorecard

Scores reflect a 5-call sample. Overall range: 1.1 – 3.0.

This Week's Coverage

Models Supported

Pattern Note: Lower scores on MX2000 calls suggest a need for deeper familiarity with mesh node troubleshooting and pairing flows specific to this model.

Problem Categories

Connectivity Focus: The low average score (1.43) for connectivity issues points to gaps in accurate diagnosis and resolution steps for WAN, mesh, and firmware-related problems. Pay special attention to LED interpretation, remote-access protocols, and escalation triggers.

General Inquiry Focus: The single general inquiry call scored 1.5, indicating missed opportunities to redirect or resolve customer questions efficiently. Ensure clear next steps or self-help resources are always provided.

What Went Well

1. Accurate LED Interpretation

You correctly interpreted LED states per KB, identifying a reboot loop (flashing blue) and no-internet state (solid red) on MX6200 devices. This insight guided your troubleshooting plan and aligned with documented guidance.

> “Customer reported no internet with MX6200 parent node flashing blue (reboot loop) and child nodes solid red (no internet).”

#PR00005769

1. Empathy and Acknowledgment

You acknowledged customer frustration and apologized for disconnection early in the call, which helped de-escalate tension and showed respect for the customer’s time.

> “I really apologize for the inconveniences that you're having with our Links device...”

#TE00131111

1. Serial Number Collection

You collected and verified the serial number for accurate warranty lookup, a critical step before escalating for replacement.

> “Collected and verified serial number (20J[REDACTED_PHONE]) for accurate warranty lookup ([16:00]).”

#PR00005769

Growth Opportunities

1. Avoid Unauthorized Remote Access Tools

Using third-party tools like Zoho for remote access violates security protocols and can expose both the customer and the company to risk. Good looks like: Using only approved internal remote-access solutions, with clear disclosure and customer consent, and following all security checklists before proceeding.

> “Used unauthorized third-party remote-access software (Zoho) without security approval.”

#TE00131111

1. Provide Correct Technical Guidance and URLs

Giving incorrect URLs (e.g., support.netapps.com, support.nxnlinks.com) or misinterpreting LED indicators undermines trust and wastes time. Good looks like: Quoting exact, validated KB articles, using only official Linksys support domains, and cross-checking LED meanings against the device’s specific KB before instructing the customer.

> “Provided materially incorrect and potentially unsafe support URL (support.nxnlinks.com), which is not a Linksys domain.”

#TE00131428

Next Week's Focus

• Verify model-specific reset procedures before instructing customers—especially for MX devices where reset durations and methods vary. Use the exact KB steps for the model in play.
• Confirm warranty status and collect proof of purchase early in hardware replacement cases, then set clear expectations for next steps (e.g., email request, timeline).
• Practice concise, step-by-step guidance during critical moments (e.g., firmware checks, node pairing) to avoid long silences and keep the customer engaged.
• Always provide a valid self-help resource or callback time before ending calls, even if the issue is escalated—customers need to know what to expect next.

Technical Accuracy

• Improvement

Incorrect reset duration and procedure for MX6200: instructed 20-second hold instead of 15 seconds per KB ([19:00–22:00]).

#PR00005769

• Improvement

Provided invalid support URL: directed customer to support.netapps.com instead of official Linksys domains ([66:00]).

#PR00005769

• Improvement

Directed customer to invalid router web UI address: http://[REDACTED_PHONE]:8080/news/ ([33:00]).

#TE00131111

• Improvement

Provided materially incorrect and potentially unsafe support URL (support.nxnlinks.com), which is not a Linksys domain.

#TE00131428

• Strength

Collected and verified serial number (20J[REDACTED_PHONE]) for accurate warranty lookup ([16:00]).

#PR00005769

Coaching Moments

• Improvement

> “But since your spectrum modem and your spectrum router are still working fine, that's what you mentioned earlier, then it's not really that, ah, like worst scenario of the power outage, okay? Unless if it's really so strong, even your modem should be affected. Okay, but since they are still working fine, so we'll focus on your Linksys.”

Note: While the intent is to focus troubleshooting, the phrasing risks minimizing the customer's experience. Reframe to validate their effort and clearly outline next steps.

#PR00005769

Escalation Lessons: What L2 Did

#TE00131111 — Resolved by Level 2

• What L1 saw: Customer reported no internet on an EA9300 router (WAN orange LED) while direct modem-to-PC connection worked. L1 verified physical cabling, attempted remote access via unauthorized Zoho tool, and misinterpreted the orange WAN LED as a cable issue.
• Why it escalated: L1 reached a threshold due to incorrect technical guidance (unauthorized tool, misinterpretation of LED) and inability to progress with valid troubleshooting.
• What L2 did: L2 closed the case after the customer purchased a third-party router and confirmed internet functionality, noting that further isolation on the EA9300 was no longer needed. L2 also offered future assistance if the customer wished to revisit the issue.
• Current state: Resolved via customer’s decision to use a different router.
• L1 learning points:

1. Validate WAN LED meaning per EA Series KB before attributing issues to cabling.

2. Use only approved remote-access methods; if unavailable, document the limitation and suggest alternative next steps.

3. If the customer moves to a third-party solution, document the closure reason clearly and offer to assist with future isolation if needed.

#TE00131428 — Resolved by Level 2

• What L1 saw: Middle MX2000 node in a three-node mesh was not connecting; app setup failed. L1 provided an invalid support URL (support.nxnlinks.com), performed no troubleshooting, and ended the call with a vague callback promise.
• Why it escalated: L1 failed to execute basic mesh troubleshooting (reset, pairing, signal check) and misdirected the customer to a non-Linksys domain, triggering escalation.
• What L2 did: L2 advised the customer to call back when available, confirmed weekend closure, and documented the need for proper troubleshooting on the next contact. No technical resolution was performed by L2 either.
• Current state: Resolved as “Callback” — essentially pending customer recontact.
• L1 learning points:

1. Always provide valid, official Linksys resources (e.g., KB articles, support portals) — never third-party or unofficial URLs.

2. Execute at least one concrete troubleshooting step for mesh node issues (e.g., factory reset, 5-press pairing, signal strength check) before escalating.

3. Document serial numbers and mesh topology to speed up future resolution and avoid repeat contacts.

Coach Appendix

Highest-signal trend: All unresolved calls stemmed from either incorrect technical guidance (wrong URLs, LED misinterpretation, unauthorized tools) or insufficient troubleshooting execution (no mesh node reset, no WAN verification). Focus next week on model-specific KB verification and committing to at least one actionable step before deferring to escalation or callbacks. Ensure every call ends with a clear next step or self-help resource to improve resolution rate and customer confidence.

This Week's Calls