vennemir.calvin@concentrix.com — Coaching Report

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

At a Glance

Scorecard

Score range this week: 1.1 (lowest overall) to 4.0 (highest overall) across 34 calls reviewed.

This Week's Coverage

Models Supported

Models with avg score below 2.5:

• MX5300 (1.30): Both MX5300 calls ended without a confirmed fix or clear next step. This suggests a familiarity gap with the MX5300's setup and troubleshooting flow — specifically around node pairing, LED state interpretation, and the correct factory reset sequence for this device.
• RE7000 (1.60): RE7000 calls show a pattern of vague closures with no confirmed resolution. The RE7000 extender has a specific WPS/manual setup path and LED behavior that differs from mesh nodes — reviewing the RE7000 quick-start guide and admin page access steps would be a strong investment.
• MR8300 (2.10): Three MR8300 calls averaged 2.10, with two ending in abandoned or vague closures and one incorrectly closed. The MR8300 is a common dual-band/tri-band router with a well-documented admin interface — building confidence with its configuration and password reset flow would directly improve outcomes here.
• EA7300 (2.20): Two EA7300 calls both scored below 2.5, with one involving an incorrect URL being provided to the customer. The EA7300 setup flow via the Linksys app or linksyssmartwifi.com is worth a focused review.

Problem Categories

Focus area notes:

• CONNECTIVITY (16 calls, avg 2.30): This is the highest-volume category and the one with the most room to grow. The pattern across low-scoring connectivity calls is a missing or incomplete modem isolation step — confirming that the modem has internet before troubleshooting the router is the single most reliable way to narrow the problem quickly and give the customer a clear next action.

• SETUP (10 calls, avg 2.20): Setup calls are scoring below average, and several ended without a confirmed working state. The key habit to build here is a "close the loop" step at the end of every setup call: confirm the device shows the expected LED state, confirm the customer can reach a test website, and confirm they know what to do if it drops again. That three-part check takes under a minute and turns a vague close into a confirmed resolution.

• CONFIGURATION (1 call, avg 1.20): The single configuration call this week was closed incorrectly with instructions to use a non-existent "Lynx app." For configuration calls, always verify the correct app name (Linksys app) and the correct admin access path (192.168.1.1 or myrouter.local) before advising the customer.

What Went Well

No transcript highlights are available for this week — coaching_moments_json was empty across all reviewed calls. The strengths below are drawn from scorecard and outcome data.

1. Perfect documentation discipline — 34 for 34.

Every single call this week was documented in HappyFox. That's a 100% documentation rate across 34 calls, including multi-call cases, outbound callbacks, and escalations. This is exactly the kind of operational reliability that makes the whole team function better — supervisors can trust the case history, L2 has context when they pick up an escalation, and customers don't have to repeat themselves. Keep this up.

2. Strong accuracy on best calls — and real resolutions to show for it.

Three calls this week stood out with overall scores of 3.3–3.9 and accuracy scores of 4–5: #LTS00077800, #LTS00094375, and #GI00131206. On #LTS00077800 (MX6200, overall 3.9), the admin password was changed successfully and the fix was confirmed — a clean, complete resolution. On #LTS00094375 (MBE7000, overall 3.3), nodes were re-paired and Wi-Fi was restored with a clear post-call instruction to wait 10 minutes before relocating. These calls show what you're capable of when the troubleshooting path is clear — the accuracy is there.

3. Correct escalation judgment on the MX8500 account access case.

On #TE00092429 (MX8500, overall 3.1), the agent correctly identified that an expired verification link for a Linksys account was beyond L1 scope, escalated to L2 with a clear handoff note, set customer expectations for a 24–48 hour callback, and asked the customer to send a screenshot for L2 context. That's the escalation protocol working exactly as intended — and L2 claimed the ticket within about two hours.

Growth Opportunities

1. Protocol Adherence: Always leave the customer with a confirmed next step

The most consistent pattern in lower-scoring calls this week is calls that end without a clear resolution or a concrete next action for the customer. Several calls across CONNECTIVITY and SETUP categories were marked abandoned_or_vague — meaning the customer hung up without knowing what to do next. This isn't about the troubleshooting itself; it's about the close.

What good looks like: Before ending any call where the issue isn't fully resolved, state one specific next step out loud and confirm the customer heard it. For example: *"What I'd like you to try is swapping the cable between your modem and router, then testing with a second device. If that doesn't work, call us back and reference this case number."* That's it — one action, one condition, one reference. The customer leaves with a path forward, and the case is documented as pending rather than abandoned.

Calls to review for contrast: #LTS00101153 (overall 1.1, no next step confirmed) vs. #LTS00131018 (overall 3.0, customer given a specific factory-reset sequence and log-sending instruction). The difference in outcome is almost entirely in how the call was closed.

2. Accuracy in Troubleshooting: Anchor every call with a modem isolation step

Several low-accuracy calls this week involved connectivity issues where the troubleshooting jumped to router-side steps without first confirming whether the modem had a working internet connection. When the modem itself is the problem, no amount of router troubleshooting will fix it — and the customer ends up frustrated after a long call that didn't need to happen.

What good looks like: Within the first few minutes of any connectivity call, ask the customer to connect a device directly to the modem via Ethernet and run a speed test or open a website. If that works, the problem is the router or the router's configuration. If it doesn't, the problem is the modem or ISP — and the next step is to call the ISP, not to reset the router. This one diagnostic step takes about 90 seconds and immediately narrows the problem space in half.

Calls to review: #LTS00101153 (overall 1.1, accuracy 1 — no modem isolation evident), #LTS00130705 (overall 1.3, accuracy 1 — incorrect URL provided, modem baseline not established). Compare with #TE00122939 (accuracy 4) where the agent did confirm modem connectivity with the customer before escalating — that's the right sequence.

Technical Accuracy

No technical accuracy issues flagged this week — solid performance on product and process references.

Note: While technical_coaching_moments returned empty from the pipeline, the call outcome data does surface two specific technical accuracy concerns worth flagging manually: (1) #LTS00130705 — an incorrect URL was provided to the customer for EA7300 setup; (2) #LTS00131263 — the customer was directed to use a "Lynx app" which does not exist; the correct app is the Linksys app. These are worth reviewing in the Growth Opportunities section above and in the call recordings directly.

Escalation Lessons: What L2 Did

#TE00122939 — Pending with Level 2

What L1 saw:

The customer (return caller, WHW01 mesh system, Comcast ISP) reported child nodes disconnecting. The customer was out of warranty but had purchased Paid Connect support. L1 documented that the customer had already contacted Comcast and confirmed internet was restored at the modem level, ran a speed test successfully via Ethernet from modem to router, and confirmed websites were loading. L1 then instructed the customer to remove the Ethernet cable to test wireless — the notes are truncated at that point. The call outcome was to have the customer verify modem connectivity and contact the ISP if needed, with a case number provided.

Why it escalated:

The escalation note states "Escalate for exceeding threshold — Approved by Clark." This is a time/attempt threshold escalation rather than a technical dead-end escalation. The case had been open since March 2026 (originally created 2026-03-24) and had gone through at least one prior resolution attempt. The combination of a long-running case, a Paid Connect customer, and an unresolved node disconnection issue triggered the threshold rule.

What L2 did:

The L2 resolution steps in the available snapshot show only the escalation handoff actions (status changed from Resolved → Escalated, assigned to L2 queue). No L2 technical resolution work is recorded yet — the case remains pending with Level 2 as of the data snapshot.

Current state:

Pending with Level 2. No L2 technical action has been recorded yet. The case is in the escalation queue.

L1 learning points:

1. Document the full wireless test result before escalating. The notes are truncated at the point where the Ethernet cable was removed to test wireless. If the wireless test result (pass or fail, which nodes reconnected, LED states after cable removal) had been captured, L2 would have a clearer starting point. Always complete and document the final diagnostic step before handing off.

2. For WHW01 child node disconnections, capture LED state for each node individually. The WHW01 uses LED color to communicate node status (solid blue = connected, solid red = disconnected, pulsing = pairing). Recording the LED state of each child node at the start and end of the call gives L2 a precise picture of what changed during the session.

3. On long-running cases (open 60+ days), flag the history early. This case was originally created in March. When a return caller references a case that old, note the prior resolution attempt and what changed since then — this context is critical for L2 to avoid repeating steps that already failed.

#TE00092429 — Pending with Level 2

What L1 saw:

The customer (MX8500, Brightspeed ISP) was a return caller who had created a Linksys account but could not verify it — the verification link had expired after 48 hours. The customer was concerned about a potential account lockout that would prevent access to the Linksys Smart Wi-Fi (LSWF) app. L1 confirmed the account creation, identified the expired verification link as the blocker, informed the customer to send a screenshot of the error, and escalated to L2 after consulting with L2 agent Leonisa Bless who confirmed escalation was appropriate.

Why it escalated:

Account verification link expiry and potential account lockout are backend/account-management issues that L1 cannot resolve without access to the Linksys account system. L1 correctly identified the boundary and escalated. The escalation trigger was explicit: L1 confirmed with L2 before escalating, which is the right process.

What L2 did:

L2 claimed the ticket from the TE queue approximately 2 hours and 20 minutes after escalation (claimed at 17:29 on 2026-05-27). L2 recorded the customer's details (name, email, phone, model MX8500, serial 43f10m37b04648, ISP Brightspeed) and moved the status to Callback. The customer also sent an email directly confirming the issue — they have two email accounts and need the verification resolved for their Linksys account. As of the data snapshot, L2 has not yet posted a technical resolution; the case is in Callback status, meaning L2 is preparing to contact the customer.

Current state:

Pending with Level 2, status Callback. L2 has claimed the case and is expected to contact the customer to resolve the account verification issue directly.

L1 learning points:

1. For account verification issues, collect both email addresses the customer uses before escalating. In this case, the customer mentioned two email accounts in their follow-up email. Capturing both at the time of the call gives L2 everything they need to locate and verify the account without an additional contact cycle.

2. Confirm the customer's serial number and ISP at the time of escalation. L2's first action was to record the serial number (43f10m37b04648) and ISP (Brightspeed). Having this in the L1 handoff note saves L2 time and reduces the chance the customer has to repeat information.

3. When escalating account/app access issues, set a specific expectation window. L1 correctly told the customer to expect a callback within 24–48 hours. This is the right approach — always give the customer a time window and confirm they have the case number so they can reference it if the callback doesn't arrive.

This Week's Calls