If you have a comment or are interested in sponsoring, hit reply.
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.
