albertdominic.roa@concentrix.com — Coaching Report

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

At a Glance

Scorecard

Scores reflect 9 calls reviewed, ranging from 1.0 to 4.2 overall.

This Week's Coverage

Models Supported

Key pattern: Lower scores on MR2000 and MX2000 calls suggest a need for deeper familiarity with these models’ setup and troubleshooting flows.

Problem Categories

Connectivity and Setup both show room for improvement (averages below 2.5). Focus here means deeper protocol adherence and clearer troubleshooting paths before escalation.

What Went Well

1. Effective email delivery confirmation

You confirmed an email was delivered after a second resend attempt, ensuring the customer received critical information.

> “You data, you should receive it any minute now. Yes, I actually got it correctly.”

#RR00098345

1. Persistence in troubleshooting mesh nodes

You guided a customer through the 5‑press pairing method for WHW03 nodes, which successfully restored connectivity for two child nodes.

> “Let me just create a record for this. May I ask the model number and serial number of your parent node? What’s the color of the light of the Parent Node mode?”

#LTS00131508

Growth Opportunities

1. Avoid fabricated technical guidance

In one call you provided an invalid IP address (192.PeriodSources) that does not exist in any Linksys KB. Customers should always be directed to myrouter.local or the ISP‑provided gateway IP.

> “Attempted to access router UI via invalid IP addresses (192.PeriodSources, [REDACTED_PHONE], …).”

#LTS00090234

Next step: Double‑check every IP or URL against the official KB before sharing it with a customer. When in doubt, default to myrouter.local.

1. Troubleshoot before escalating

Several calls were escalated after minimal or no troubleshooting (e.g., red‑light mesh node, email‑change request). This delays resolution and can frustrate customers.

> “Escalated to Level 2 with promise of callback in 2–3 hours; no technical steps provided.”

#TE00130897

Next step: Run at least two basic troubleshooting steps (reset, power cycle, LED check) before escalating. Document what you tried and why escalation is needed.

Next Week's Focus

• Verify every IP/URL against the KB before telling a customer to use it. Keep a quick reference list handy.
• Run a minimum of two troubleshooting steps (reset + power cycle) for any hardware fault before escalating. Note the results in the case notes.
• Confirm identity before modifying account details (e.g., email changes). Use security questions or ticket numbers.
• Close the loop on callbacks: always confirm a timeframe, contact method, and case number with the customer.

Technical Accuracy

Strength

• Correct 5‑press pairing for WHW03

You applied the KB‑approved 5‑press method to recover mesh nodes, aligning with recovery guidance for Velop devices.

#LTS00131508

Improvements

• Invalid IP address guidance

You suggested 192.PeriodSources, which is not a valid Linksys gateway IP and contradicts KB instructions. Valid options are myrouter.local or the ISP‑provided gateway IP.

#LTS00090234

• Falsely claimed email change completion

You told a customer the email change was already done without verifying in the system or confirming with the customer, violating security protocol.

#TE00122564

• No troubleshooting for red‑light mesh node

You escalated a red‑light mesh node issue without attempting basic steps (reset, LED interpretation, re-pairing), contrary to KB guidance.

#TE00059604

Coaching Moments

Strength

• Guided successful mesh node recovery

> “Let me just create a record for this. May I ask the model number and serial number of your parent node? What’s the color of the light of the Parent Node mode?”

#LTS00131508

Improvements

• Premature escalation without triage

> “Escalated to Level 2 with promise of callback in 2–3 hours; no technical steps provided.”

#TE00130897

• Missing required device details before escalation

> “Missing required product identification (model/serial) — critical protocol failure.”

#TE00059604

Escalation Lessons: What L2 Did

#TE00122564 — Resolved by Level 2

• What L1 saw: Customer wanted to change the email on their Linksys account but was locked out after a failed login.
• Why it escalated: L1 falsely claimed the email change was already completed without verification, violating security protocol and leaving the customer unable to log in.
• What L2 did: L2 requested the current and new email addresses, verified the account, and updated the email correctly. They also reset the password and confirmed the change with the customer.
• Current state: Resolved — email updated, password reset, and customer confirmed successful login.
• L1 learning points:

1. Verify account changes in the system before telling a customer they’re done.

2. Confirm identity (e.g., using the ticket number, secret question) before modifying sensitive account details.

3. Provide clear next steps (e.g., “Your password has been reset; here’s your new temporary password.”)

#TE00130897 — Resolved by Level 2

• What L1 saw: Customer couldn’t access the Linksys app after enabling bridge mode; solid purple LED; modem cuts out; requested factory reset.
• Why it escalated: L1 failed to verify the router model, provided no troubleshooting steps, and placed the customer on hold without explanation.
• What L2 did: L2 guided the customer through a factory reset (hold reset button for 20 seconds), power-cycled the modem, and accessed the router via myrouter.local. They confirmed the router rebooted and the LED returned to solid blue.
• Current state: Resolved — router restored to factory settings, internet connectivity confirmed.
• L1 learning points:

1. Always verify the exact model and serial number before proceeding with any advanced troubleshooting.

2. Run at least one basic troubleshooting step (reset, power cycle) before escalating.

3. Explain each step clearly and confirm success before moving on (e.g., “After the reset, does the LED turn solid blue?”)

#TE00059604 — Resolved by Level 2

• What L1 saw: MX4200 mesh node showed solid red LED after power outage; customer couldn’t add it to the network.
• Why it escalated: L1 collected no device details, didn’t attempt any troubleshooting, and escalated after a brief hold.
• What L2 did: L2 instructed the customer to perform a 30‑second reset on the red node, reposition it within 3 meters of the parent, and re-pair using the 5‑press method. They also checked the parent node’s firmware and updated it if needed.
• Current state: Resolved — node regained connectivity after reset and re-pairing.
• L1 learning points:

1. Collect model, serial, and firmware version at the start of any mesh issue call.

2. Follow the KB troubleshooting flow for red‑light nodes: reset, reposition, re-pair.

3. Document each step and the customer’s response before escalating.

Coach Appendix

• Top trend: Frequent escalations after minimal or no troubleshooting, especially for mesh and setup issues. Focus next week on running at least two basic steps (reset + power cycle) and confirming device details before handing off.
• Key pattern: Technical inaccuracies (invalid IPs, unverified account changes) are driving escalations. Reinforce verification against KB and security protocols in daily huddles.
• Evidence highlighted: All quotes and notes above are drawn directly from call transcripts, coaching moments, and escalation details provided in the payload. No new or invented content was introduced.