Welcome back to The Customer Continuum. Issue #36.
A few years ago I brought a handful of our most active community members into a room with the new head of our support team. I set it up for two reasons. One was to build a little trust between these customers and a leader who was new to them, and between that leader and me. The other was to get at a harder question, which was how we bring these two groups together to solve something that hadn’t really been anyone’s job.
These are customers who go out of their way for us. They answer other people’s questions in our community, they jump into Reddit threads and other forums, and a lot of what they sort out never becomes a support ticket at all, because they’ve handled it for someone before it ever reaches us. What came out in that room was that the people doing the most for us weren’t always getting that same care back. They’d help everyone else and then wait longer than they should have on their own issues.
None of that was in a report. It took putting the right people in one room to even see it, and because the new support leader was sitting there with the customer, we could start solving it together immediately.
That afternoon stuck with me. What we needed to see lived in how those customers were spending their time for us, and in what they weren’t getting back, and it only surfaced because we brought the right people together to look. A dashboard or a survey would never have shown us any of it. That’s the idea behind what I built this week, something that reads the signal customers are already giving off and puts it in front of the person who can act on it.
Last week I built a one-time read of customer signal, an agent that looks across the places customers actually talk and hands you back the themes. This week I make it run every week, so it starts to show me what’s changing from one week to the next.
Voice of Customer, or VoC, is just the practice of capturing what your customers are telling you and turning it into something the business acts on. For most teams that’s meant surveys. You send the survey, you wait, and you read the numbers and share the report to your executive team. Often times, the data is already stale.
A single read tells you how your customers feel this week. Run it every week and you start to see movement and patterns: which themes are climbing, which ones just showed up, which ones went quiet. One read tells you where a theme sits today, and the change from one week to the next tells you where it’s heading.
That matters more than it sounds, because the signal that costs you the most money rarely arrives all at once. A theme shows up faintly one week, a little louder the next, and by the time it’s loud enough for a single read to flag it, the account it’s attached to has often already made up its mind. A standing pulse catches it while it’s still building. And catching it is only half the job, because a theme with nobody’s name on it is just an observation. So the pulse does two things every week: it names what’s changed, and it points each theme at the person who can actually act on it.
What I built
I didn’t build anything new this week, and that’s the point. Last week’s issue put two files in the kit, the multi-source signal agent that reads across calls, tickets, community, and usage, and the routing layer that assigns an owner to each theme. This week I wired them into a cadence. Same agent, same rules, run on a weekly schedule with one job added: compare this week’s themes to last week’s and report what moved.
The report comes back in three buckets. New themes, ones that weren’t there last week. Escalating themes, ones getting louder. And themes that went quiet. That third bucket, the quiet one, needed a rule of its own that the one-time read never did.
A theme going quiet doesn’t mean the problem is solved. When a problem stops showing up in the signal, it might mean you fixed it, or it might mean the customer stopped bothering to tell you because they’ve already decided to leave. From the outside those two look identical, and the diff can’t tell them apart. So the pulse is never allowed to close a theme on its own. It reports the quiet as a status to go confirm, and it hands it to someone to check.
The two rules from last week carry over unchanged, because they matter more in a weekly cadence than they did in a one-time read. The first is that the agent never invents a theme it can’t cite. If the evidence is one loud comment, it says so and marks it as something to watch rather than dressing it up as a trend. The second is the absence rule, the one I care about most. The agent can report that there’s no signal about something, but it’s never allowed to read silence as satisfaction, because a quiet account isn’t a happy one. Run those rules once and they keep you honest for a week. Run them every week and they’re the only thing that keeps a standing pulse from quietly turning into false comfort.
The honest run
So I ran it, the way I run everything in this newsletter, cold and then torn apart by a second agent whose only job is to find where the first one was wrong. I built two weeks of signal in a fictional set of accounts, deliberately messy the way real signal is, and treated the first week as the baseline, the “last week” the pulse compares against. Then I fed it a second week and asked for the diff, without telling it what I thought it would find.
It caught exactly what I’d hoped a pulse would. In week one, onboarding was a middling theme. It was in the data, a couple of accounts grumbling that ramp-up took too long, but it didn’t stand out, and a single read that week rated it moderate and moved on. In week two it climbed hard. A customer froze an expansion because the last rollout had taken a full quarter to get productive. A second account paused adding seats for the same reason. An account churned and named a slow start as the reason they stopped seeing value. Onboarding tickets jumped by about a third. Put week two next to week one and the shape is obvious, a revenue problem building in real time, and the diff pushed it to the top of the pulse. A single snapshot taken the same week would have shown it sitting about where it had been.
It also flagged something completely new, and it read it correctly, which honestly surprised me. A handful of customers asked for a feature the product already has, a way to schedule reports. One of them wrote their own script to do a thing that ships in the app today. A community post asking for it drew a top reply pointing out it already exists. The agent didn’t file that as a missing feature. It called it what it was, a gap in what customers know rather than a gap in what we’ve built, which is a completely different fix with a different owner.
And then the theme that had been the loudest the week before went quiet. Last week, the strongest signal in the set by a distance was customers struggling to prove the product’s value to their own finance leaders. This week, nothing. No new calls, no new posts, the big community thread from the week before just sitting there with no new replies. This is where that rule provided the most value. The agent refused to call it resolved. It reported the theme as gone quiet and unconfirmed, and it went looking for what was underneath the silence, which turned out to be two things worth worrying about. One of those finance-buyer accounts had gone dark after we sent them a value summary. Another had a senior person skip their last check-in, with a renewal about two months out. That silence is exactly what the absence rule exists to distrust, because it looks identical to a problem that got solved.
So far that’s the run going right. It also fumbled, in two ways.
The first is routing. It got the onboarding theme dead right and then handed it to the wrong mix of people. It assigned it to customer success and sales, which makes sense for the churn and the frozen expansions, and it left product off entirely, even though the one concrete, fixable thing in the whole onboarding story was a setup checklist that had gone out of date, which is product’s to fix. The theme needed three owners and got two. What makes it worse is that the agent knew. In its own self-check it admitted it had probably under-assigned product, and then it shipped the routing anyway. Handing the theme to two teams that can’t touch the actual fix means the root cause just sits there while everyone agrees it’s important.
The second fumble is quieter. When that ROI theme went silent, the agent correctly refused to call it resolved, but it still ranked it near the bottom. Its logic was mechanical: fewer mentions this week means weaker signal, and weaker signal sorts low. So the single most dangerous account in the whole pulse, a strong customer who went dark two months before a renewal, ended up filed under a label that reads like “minor, keep an eye on it,” sitting right next to a genuinely minor item. A reader skimming the pulse would go straight to the onboarding theme at the top, the one they already knew about, and walk right past the account most likely to churn, sitting near the bottom under a low-priority label.
That last one is the failure I didn’t expect. The diff got good at spotting what’s moving, but the way it ranked and labeled things didn’t keep up. A theme can now be quiet and dangerous at the same time, and the labels I carried over from a one-time read just don’t have a word for that. If I’d nailed everything, I’d distrust the run. What held the whole way through was the absence rule. Every week it flagged that the survey feed still wasn’t wired instead of treating the silence as good news, and it refused to read a quiet customer as a happy one. That’s the discipline that makes a weekly pulse safe to run, instead of something that just sounds a little more sure of itself each week while it’s really still guessing.
What this means for your team
You don’t need to build any of this to use what it’s telling you. The move underneath it works with a notebook.
Take the two or three themes you’d say are live with your customers right now and write them down. Next week, write them down again. The gap between the two lists is the entire point. A theme that was quiet and is now everywhere is escalating, and it’s telling you something a single glance this week can’t. A theme that’s brand new is worth a second look before it gets loud. And a theme that was loud and went silent is the one to handle most carefully, because you can’t tell from the quiet alone whether you fixed it or lost them, and treating it as fixed is how a save turns into a surprise.
Then give each one an owner, a real person who can act, not a function in the abstract. And hold the two rules while you do it. If a theme rests on one loud voice, mark it to watch instead of calling it a trend. And if an account goes quiet, don’t assume that’s good news.
What’s next
Next week I’m taking the pulse off my desk and putting it on a real schedule, wiring it to run on its own and drop each week’s diff where the owners will actually see it, instead of depending on me to remember.
This week’s free starter: the week-over-week diff
The free starter is the diff on its own, pulled out of the full pulse so you can run it by hand. You give it two lists, the themes you saw last week and the themes you’re seeing this week, and it hands back what’s new, what’s escalating, and what went quiet, with the “quiet is not resolved” rule built in so it can’t quietly close a theme on you.
You’ll see it right away. Put last week’s list next to this week’s, and a theme you’d have sworn was steady shows up climbing. A single read can’t show you that.
Drop it in a fresh Claude Project, paste your two lists, and read what it says moved.
For paid subscribers
The free starter diffs two lists you typed. Your kit runs the whole thing on your own signal, every week, without you steering it.
The honest part, and the whole pitch this week: you already own the pieces. Last week’s issue put two files in your Copilot, the multi-source signal agent that reads across your calls, tickets, community, and usage, and the routing layer that assigns each theme an owner. I didn’t ship you new files this week. I’m handing you the task briefs to stand up what you already have as a running weekly pulse, so by Friday it’s a habit instead of a thing you did once.
The promise is concrete. By the end of this week you have a weekly VoC pulse running on your actual signal, every theme routed to an owner, and a week-over-week diff in your hand that tells you what’s climbing and what’s gone quiet. You run it once to set the baseline, and after that it’s a standing rhythm on the signal you already generate every week.
This week’s build, task briefs written so you don’t have to design it:
→ Stand up the multi-source agent on your own four feeds and run it once to set this week’s baseline:
→ Turn on the routing plus weekly cadence, and schedule next week’s diff against this week’s baseline:
Next week, putting the pulse on a real schedule so it runs without you.
— Kevin
P.S. If reading this made you think of one account that’s gone quiet on you lately, don’t file that quiet as good news. Forward this to one customer marketer who’s about to close a theme they should be confirming, and then go check on that account. That’s how this grows.