Building a GTM alert system
Light the GTM Bat Signal - there's something that needs to be fixed. What info do you need to solve it? Read: "Everything Starts Out Looking Like a Toy" #227
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: an ode to LEGO blocks that are instrument panels. These first appeared in LEGO Space sets and have become more common decoration “special” pieces. Compare them over time and you see the design evolution in LEGO panels, as well as good overall design choices. Edition 227 of this newsletter is here - it’s December 2, 2024.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ Building a GTM Alert System
Imagine you’re watching a #wins channel in Slack as your sales team prepares to close deals at the end of a month or a quarter. You know that one of your expected (and committed) deals is supposed to come in, but something goes wrong with the initial payment.
You were expecting something more like this win notification.
What do you do? The first thing you notice about our error message is that we’re missing some critical information. You want to know what went wrong, where to investigate it, and what to do to fix it (if known).
What went wrong
In our simple example, a few things might go wrong. Common errors include failed payment, a stage that didn’t move to the expected “closed won”, or an application account not connected to a CRM account.
Once you enumerate a list of the possible errors, build a simple list of steps to identify the one you’ve found. When you confirm that you’ve found a known type of error, there ought to be a standard operating procedure to resolve it. You also need a general error (probably emitted by the workflow tool) that echoes whatever happened when these cases don’t match.
A good error message, unlike the sample above that commands attention, lets you know what went wrong.
Where to investigate it
Knowing that an error happened is the first step to diagnose the issue.
Where do you look for more information? The answer is contextual and dependent on the kind of error. An account in the wrong stage needs to be fixed in your CRM. A failed payment is fixed in your payment platform. (And if you enabled a payment retry in your CRM, you could fix it in one place.)
There might not be an immediate answer! But knowing where to start looking (thanks to that Standard Procedure) is a great place to start.
What to do to fix it
A great error message informs you:
What happened: “a payment was attempted for [account name] and failed due to insufficient funds.” [Account Link](the url)
Where to investigate it: the payment processor account link
What to do to fix it: a button enabling a retry
If you can’t fix it immediately, log it. And if you find a new kind of issue that’s happened more than a few times, it’s probably time to update your standard procedure.
Need help designing the visual look for your errors? Here’s a helpful guide.
What’s next
If you haven’t already built reports to show the records that need to be fixed, it’s time to do this too. Errors that end up in Slack or another alert channel are ephemeral and easily missed. Adding a report or a dashboard along with a mechanism to know when the condition was resolved helps you know how often a problem occurs, how long it takes to fix, and whether it clusters with other problems.
What’s the takeaway? GTM errors are the canary in the coal mine letting you know if your GTM process is working. To make them more effective, ensure they contain what happened, where to investigate, and ideally a way to fix with a button click or a replay of a workflow.
Links for Reading and Sharing
These are links that caught my 👀
1/ Ask a friend - I’m intrigued by adding people in the middle of failing processes, so HumanLayer is interesting. The basic idea is to give LLMs the option to ask humans for help. One thing that’s not clear is how to signal the LLM that the human is intentionally misleading when answering.
2/ Teaching LLMs system integration - Anthropic’s new Model Context Protocol gives us a map to teach chatbots how to ask for information from structured systems. Think of MCP as a API for APIs; it can make it possible for LLMs to know how to talk to Slack, Postgres, and many other systems without hallucinating how to do it.
3/ Cooling subway tunnels - You might assume subway tunnels are inherently cooler than the surface. But they’re getting warmer, partly because the ambient temperatures are getting warmer too. Cooling them down is harder than it looks.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon