Daniel Reyes

What We Observed

Once or twice daily, Daniel runs what we're calling a "upsell batch" — a session where he processes a list of customers for an upgrade or promotional offer. The keystroke data captured a 22-minute session with 13+ consecutive Ctrl+C / Alt+Tab / Ctrl+V cycles in a single minute-bin. He is copying customer records from a Google Sheet one row at a time, switching to Recurly, entering a promotional code, and repeating.

The Sequence (Captured Live)

The raw keystroke capture from a batch session looks like this — this is not reconstructed, this is what the telemetry recorded:

<Ctrl+C><Alt+Tab><Ctrl+V><Tab>PINE20<Enter>
<Alt+Tab><Ctrl+C><Alt+Tab><Ctrl+V><Tab>PINE20<Enter>
<Alt+Tab><Ctrl+C><Alt+Tab><Ctrl+V><Tab>PINE20<Enter>
... (repeats for 20–40 minutes)

Each cycle: copy customer email from Sheet → switch to Recurly → paste → tab to promo field → type code → submit → switch back. Estimated 45–60 seconds per customer.

Why It Matters

At 20-40 minutes per batch, 1-2 batches per day, this is 30-80 minutes of pure mechanical copy-paste daily. At the lower bound: 2.5 hours per week. At the upper: 6+ hours. The work is not "customer service" — it is data entry. Recurly has a bulk API. This entire workflow is automatable in one day of engineering time.

Implementation Path

API References

• Recurly Bulk Operations API — apply subscription changes in bulk
• Recurly Apply Coupon API — programmatic promo code application
• Google Sheets API — read upsell list directly from the source spreadsheet
• Zendesk Create Ticket API — for sending confirmation messages after batch completion

What We Observed

Every single working day in the 2-week window, Daniel spends time in what appears to be an Etsy Live seller dashboard — a live-stream commerce channel that does not integrate with Zendesk. He reports on it daily as a win or active task, and it generates its own inbox that he manually monitors.

Why It Matters

This is a customer-facing sales channel that Daniel works every single day, and it generates zero metrics in any of your reporting systems. You don't know:

• How many customer messages Daniel handles through this channel
• What response times look like
• What issues customers are raising
• Whether the channel is growing, flat, or shrinking in support volume
• How much of Daniel's day it actually consumes

What This Looks Like in the Data

A sample from Daniel's daily activity log shows the Etsy Live seller hub appearing in the morning block, then again in the afternoon around the time live sessions typically run. The pattern suggests he's monitoring pre-session prep, handling in-session questions, and doing post-session follow-up — a complete support workflow that exists entirely outside of Zendesk.

Implementation Path

What We Observed

Daniel's self-reported ticket counts show significant anomalies on high-volume days. The behavioral data lets us cross-reference: if he reports handling 400+ tickets in 8 hours, that's under 1.2 minutes per ticket — not plausible for genuine customer service interactions that involve reading, reasoning, and writing.

The Context-Switching Evidence

The 4,500 Alt+Tab events in 2 weeks provide a parallel data point. At 450 switches per workday, and assuming each meaningful context switch costs 20-30 seconds of refocus time, the switching overhead alone accounts for 3-4 hours of his 8-hour day. That leaves roughly 4-5 hours of actual deep-focus productive capacity per day — not 8 hours. This is the single biggest hidden cost on any team running multiple disconnected tools.

What the High-Count Days Likely Represent

Two plausible explanations, not mutually exclusive:

• Batch operations inflate ticket counts. When Daniel runs a upsell batch or processes a list, each row may generate a ticket event in Zendesk even if it doesn't represent a real customer interaction. 30 upsell items at 2 batches/day = 60 "tickets" that aren't CS work.
• Viewing equals "handled." If the metric counts tickets opened or touched, not resolved, then scanning through an inbox of 300 tickets shows up as 300 handled even if 250 were read-and-snoozed.

How to Fix the Metric

What We Observed

App-switching is the single most common event type in Daniel's 2-week data. ~4,500 Alt+Tab switches in 11 working days — approximately 450 per workday. The window title data confirms these aren't random: each ticket typically requires 4-6 separate app visits (Zendesk ticket → Recurly subscription → Shopify order → shipping lookup → Google Sheets → back to Zendesk to close).

This Is a System Problem, Not a People Problem

A naive reading of 4,500 Alt+Tab events would suggest chaos or distraction. But the workflow analysis shows these are purposeful. Daniel is not inefficient — he is working around systems that aren't integrated. Each ticket genuinely requires touching multiple systems, and the systems don't talk to each other.

The Monthly Math

Implementation Path

API References

• Zendesk Shopify Integration — order and fulfillment data in ticket sidebar
• Recurly API — subscription lookup by customer email for sidebar widget
• Zendesk Apps Framework — build a custom sidebar app pulling from any API

Daniel spends 30-40 minutes every morning in Google Sheets manually entering ticket counts, resolution times, and upsell conversion numbers. The keystroke data shows a consistent pattern: Zendesk tab → read number → Sheets tab → type number → repeat. On top of that, Windows Calculator appeared 187 times in 11 working days — 17 times per day — for simple arithmetic that spreadsheet formulas handle instantly.

What we captured:

Every one of these calculations can be a formula. And the data entry itself can be automated — Zendesk has a reporting API that can populate the sheet before Daniel even opens it.

Implementation Path

This isn't an efficiency finding — it's a revenue finding. Daniel's Etsy Live sessions appear in the behavioral data every single working day. He spends 1.5-2 hours daily in the Etsy Live seller dashboard — preparing, running, and following up on live selling sessions. His daily activity logs mention it as a highlight nearly every day.

But here's the thing: there are zero metrics being tracked on this channel. No ticket attribution, no revenue attribution, no conversion tracking. We can see from the window titles that he's active in the Etsy seller dashboard, but there's no integration between Etsy and Zendesk — so any customer questions from Etsy Live don't flow into his ticket metrics.

What the data shows:

This is a person generating direct revenue through live commerce and nobody can see it. If his Etsy Live sessions are driving even $500/week in sales (conservative for an active live seller), that's $26K/year from a channel with zero visibility. The actual number could be significantly higher.

What to do:

• Track Etsy Live revenue. Connect Etsy's analytics to your reporting. Know what Daniel is generating.
• Route Etsy customer questions into Zendesk. Right now they're handled separately — which means they don't count in his ticket metrics and he's doing more work than the numbers show.
• Consider giving Daniel MORE Etsy Live time, not less. If the automation in Findings 1-6 frees up 20+ hours/week of his time, the highest-value use of that recovered time might be more live selling — not more tickets. That's a revenue decision, not an efficiency decision.

The bigger point: This audit found 22+ hours/week of recoverable time. Most of that comes from automating the grunt work. But the real ROI isn't in the hours saved — it's in where those hours go next. Daniel is already proving he can drive revenue through live commerce. Free him from the copy-paste and let him do more of what makes money.