vennemir.calvin@concentrix.com — Coaching Report

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

At a Glance

Scorecard

Score range this week: 1.1 – 4.0 across 40 calls reviewed. The spread here is meaningful — there are genuine bright spots in this week's data alongside calls that pulled the average down. Both ends of that range are worth studying.

This Week's Coverage

Models Supported

Models to watch:

• WHW03 (1.85) — Four calls, all below 2.0. The pattern across these calls suggests difficulty navigating multi-node Velop troubleshooting, particularly around confirming a fix before closing. This is worth targeted review.
• RE7000 (1.60) — Two calls, both ending without a confirmed resolution or clear next step. RE7000 extender setup and placement logic may be an area to revisit in the knowledge base.
• MR8300 (1.97) — Three calls with inconsistent outcomes, including one incorrectly closed. Familiarity with the MR8300's admin interface and password reset flow appears to be a gap.
• EA7300 (2.15) — Both calls fell short on accuracy, including one where an incorrect URL was provided. Worth double-checking the setup flow for this model.

Strong model performance:

• MX6200 (3.33) — Three calls, all resolved or likely resolved. This is your best model this week — the confidence and accuracy you showed here is the standard to carry into other product lines.
• MBE7000 (3.15) — Two solid calls, including one confirmed fix. Good work on this platform.

Problem Categories

Focus area — CONFIGURATION (1.20):

Only one call this week, but it scored at the bottom of the range and was incorrectly closed with the customer directed to a non-existent "Lynx app." Configuration calls require precise app and interface knowledge — when in doubt, confirm the correct app name (Linksys app, not "Lynx") and verify the customer has a working path before ending the call. One call isn't a trend, but it's worth flagging as a knowledge check.

SETUP (2.04) — worth watching:

Twelve setup calls with an average just above 2.0 is a signal. Several of these ended without a confirmed outcome — customer left to self-troubleshoot, no KB article shared, or reset instructions given without verifying the result. The opportunity here is straightforward: before closing any setup call, confirm the customer can see the expected LED state or successfully log in.

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 call outcomes and scorecard data.

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

Your top three calls this week (#LTS00077800, #GI00131206, #LTS00094375) all scored 3.2 or higher, and all ended with confirmed or likely-confirmed fixes. On #LTS00077800 you scored a 3.9 overall — the highest call of the week — with a confirmed admin password change and a clean close. That's exactly what a resolved call looks like: you identified the issue, walked the customer through the fix, confirmed it worked, and gave them a clear takeaway. That call is a template.

2. Consistent documentation — 34 cases documented across 34 ticketed calls.

Every call that had a ticket got documented. That's a 100% documentation rate on ticketed calls, and it matters. Good case notes protect the customer if they call back, give L2 a clean handoff when escalation is needed, and demonstrate professional ownership of every interaction. This is a real strength and it showed up in both escalations this week — the L2 team had what they needed to pick up the cases.

3. Correct escalation judgment on #TE00092429.

The MX8500 account verification case was a genuinely tricky situation — an expired verification link is a backend issue that L1 cannot resolve unilaterally. You recognized that, escalated correctly, set the right customer expectation (screenshot via email, 24–48 hour callback), and L2 claimed the ticket within about two hours. That's the escalation process working exactly as intended, and your read of the situation was right.

Growth Opportunities

No pre-extracted improvement quotes are available from coaching_moments_json this week. The two growth areas below are drawn directly from call outcome patterns in the data.

1. End every call with a confirmed outcome — not just a suggested next step.

The single most consistent pattern across lower-scoring calls this week is calls that ended without confirmation. Customers were told to "try a factory reset," "contact the ISP," or "search online" — but there was no check that the customer understood the step, had what they needed to do it, or knew what to expect. On calls like #LTS00101153 (overall 1.1) and #LTS00131065 (overall 1.2, incorrectly closed), the call ended before the customer had a real path forward.

What good looks like here: before you close any call, ask yourself — "If this customer hangs up right now, do they know exactly what to do next, and do they have what they need to do it?" If the answer is no, you're not done yet. A confirmed close sounds like: *"So just to recap — you're going to power-cycle the modem, wait 30 seconds, then reconnect. If the light is still red after that, call us back and reference this case number. Does that make sense?"* That's the standard. It takes 30 seconds and it's the difference between a 1.1 and a 3.0.

2. Provide accurate product and app references — verify before you advise.

Two calls this week involved incorrect information that left customers worse off than when they called: #LTS00130705 (customer given an incorrect URL and told to search for setup instructions) and #LTS00131263 (customer told to use a "Lynx app" — which does not exist — for MR8300 configuration). These aren't small errors; a customer acting on wrong information may factory-reset a working device or spend time chasing a product that doesn't exist.

What good looks like here: when you're not certain of a URL, app name, or model-specific instruction, pause and look it up before giving it to the customer. It's always better to say *"Let me pull that up to make sure I give you the right link"* than to give a wrong one confidently. The Linksys app (not "Lynx"), linksys.com/support, and myrouter.local are the three references you'll use most — make sure those are locked in. Your accuracy scores on your best calls (4s and 5s) show you know this material — the goal is to bring that same precision to every call, not just the ones that go smoothly.

Technical Accuracy

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

Note: While two calls in the data involved incorrect references (a wrong URL on #LTS00130705 and an incorrect app name on #LTS00131263), no transcript quotes were available in coaching_moments_json to cite here. These are addressed in Growth Opportunities above.

Coaching Moments

No transcript-level coaching moments were available in coaching_moments_json for any call this week. All coaching guidance has been incorporated into the What Went Well and Growth Opportunities sections above based on call outcome data.

Escalation Lessons: What L2 Did

#TE00122939 — Pending with Level 2

What L1 saw:

Return caller on a WHW01 (Velop) mesh system with child nodes disconnected. Customer was out of warranty (OOW) and had paid for the Paid Connect service. The ISP (Comcast) had recently upgraded the modem, and the customer had a Netgear Nighthawk configured in the network. L1 walked through extensive troubleshooting: confirmed ISP restored internet, ran an Ethernet cable from modem to router, ran a speed test (working), tested websites (working), then attempted 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; a case number was provided.

Why it escalated:

The escalation note states "Escalate for exceeding threshold — Approved by Clark." This suggests the call had exceeded a maximum handle time or troubleshooting duration threshold rather than a specific technical dead-end. The trigger was procedural (time/threshold), not necessarily a technical failure.

What L2 did:

The L2 resolution steps show only the escalation handoff itself — the ticket was moved from Resolved to Escalated status. No L2 technical work has been documented yet. The case is sitting in the escalation queue pending L2 pickup.

Current state:

Pending with Level 2. No L2 agent has claimed or worked the case as of the data snapshot. Status is "Escalated."

L1 learning points:

1. Document the full topology before escalating. The notes reference a Nighthawk Netgear in the network alongside the WHW01 — this is a double-NAT or bridge-mode scenario that significantly affects Velop mesh behavior. Capturing the modem model, whether the Nighthawk is in router or AP mode, and the full network topology (modem → Nighthawk → WHW01?) gives L2 a much faster start.

2. Confirm the wireless result before closing the Ethernet test. The notes show the Ethernet test was working, but the outcome of removing the cable (the actual wireless test) is not documented. Always confirm the wireless result explicitly and document it — "wireless confirmed working" or "wireless still failing after Ethernet removed" — before moving to next steps.

3. On Paid Connect cases, note the transaction ID and confirm the service scope. The original case notes mention a PayPal transaction reference but note "No option to input the transaction ID." Documenting the Paid Connect transaction ID and confirming what the service covers (and its limits) helps L2 understand what commitments have already been made to the customer.

#TE00092429 — Pending with Level 2

What L1 saw:

Return caller on an MX8500 (Velop AX) mesh system with an account access issue (ACCESS category). The customer had created a Linksys account but could not verify it — the verification email link had expired after 48 hours. The customer was concerned about a potential account lockout that would prevent use of the Linksys app. L1 confirmed the issue, informed the customer to send a screenshot of the error, and escalated to L2 after consulting with L2 supervisor Leonisa Bless, who confirmed escalation was the correct path.

Why it escalated:

Expired verification links are a backend account management issue that L1 cannot resolve — there is no L1 tool to manually verify or re-send a working verification link. The escalation trigger was clear and correct: L1 exhausted available options and confirmed with L2 supervision before escalating.

What L2 did:

L2 claimed the ticket from the TE queue approximately two hours after escalation (17:29 on May 27). L2 documented the customer's details (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 addresses and need account verification on their Gmail. L2 appears to be preparing to contact the customer directly to resolve the verification issue, likely through a manual account verification or re-send process on the backend.

Current state:

Pending with Level 2 / Callback. L2 has claimed the case and is working it. Status is "Callback."

L1 learning points:

1. Collect both email addresses when an account verification issue is reported. The customer in this case has two email addresses, and the verification was sent to one but may need to go to the other. Capturing all associated email addresses at L1 and documenting them in the ticket gives L2 the information they need to attempt re-verification without an additional customer contact.

2. Set a specific screenshot expectation. The customer was asked to send a screenshot of the error — good instinct. Make this concrete: tell the customer exactly what to capture (the error message text, the URL in the browser, and the email subject line of the expired link). The more specific the screenshot request, the faster L2 can diagnose.

3. Note the ISP and any recent network changes. This customer recently changed internet services (Brightspeed) and was in the process of re-setting up the mesh network. ISP changes can affect app connectivity and account sync behavior. Documenting "customer recently changed ISP from X to Brightspeed" gives L2 useful context for diagnosing whether the issue is purely account-side or has a network component.

This Week's Calls