Communication Forces Clarity
Let’s dive into how the process of trying to write to customers can force clarity. Like what you read? Let me know.
This feels great:
“Ben explained the situation with the bug that I reported a while ago. Although the bug is not getting fixed at this time, I understand clearly why and know that the FullStory team will work towards the ultimate goal of fixing this bug.”
and
“Provided detailed and descriptive response to the bug we had identified. Outlined company objectives and priorities and provided appreciative feedback.”
After last week’s episode about fighting dark patterns, it was refreshing to be on the receiving end of positive customer feedback, validating our work with engineering to provide more detailed communication about bugs that are hard to fix. Several readers wanted to know more so I thought this would be a topic worth exploring in depth.
Why is this problem interesting? I mean, in one sense, we’re talking about the arcana of writing emails about bugs in software products. This can’t possibly captivate readers, draw them in, and have them begging for the next paragraph (as is to be determined). Yet here we are.
I think it’s because the pattern goes something like this: you get an email in the inbox about a known issue with your product. It’s not known to the customer (yet), but it’s known to you. You groan. Behind your groaning is a knowledge that when you escalate this bug to engineering, they’re going to confirm it’s a known issue, and they’re also going to confirm that they can’t tackle the underlying problem right now because it requires a ton of effort, and there are other priorities. You might have a meeting with engineering to provide a summary of customer pain about this issue, and maybe the engineering team will groan a little bit, too, but still, they can’t fix the problem right now. Other priorities.
Most of us stop here. We groan a lot and maybe send off a half-hearted email to the customer that we’re fairly certain won’t be satisfactory, or worse, we keep them in the dark and reply with “we haven’t forgotten about you!” when they check back in. Really the underlying problem just makes us groan a lot. Lots of groaning and little clarity.
If you want to get past the groaning and get towards clarity, how do you do it?
Photo by Aaron Burden on Unsplash
Start writing
I’m going to humbly suggest that you start writing. Start writing what you want to be true. You’re not going to say you’re going to fix the bug (remember, it’s not a priority right now), but you want to ratchet forward the level of clarity you’re able to deliver. You want to be seen (and you want your company to be seen) as reasonable, and that’s a worthy goal, because a customer, being human, wants to be seen as the kind of person who does business with reasonable companies. They don’t make business decisions based on the price of the baseball tickets a sales rep bought them (haha, how are business decisions even made anymore?) No! They do business with reasonable companies who have reasonable people working for them. So if we can’t solve their immediate problem, we might as well be reasonable.
Writing is hard. The process forces clarity as you have to choose between saying something ambiguous or doing the hard work to get clarity.
Take the bug that ultimately led to the survey responses I shared earlier. The symptom reported by customers was, in short, “the time of the event in the event stream doesn’t match the time the event happened.” So for example, a user clicked a button at 12:05 PM and the event in the app instead says it took place at 12:11 PM. That’s just pretty obviously wrong? What’s support going to say to that?
My first pass might include copy like this:
Under certain situations, the event in the event stream can have a timestamp that doesn’t match the actual time the event happened. This can happen when the user has multiple tabs open on the site. We’re exploring adding better support for multi-tab sessions in a future version of the product.
Blech. This isn’t great, for a few reasons. Imagine you’re the customer who reported a bug you thought was pretty straightforward. “Under certain situations”? What situations cause the time to be completely wrong? Multiple tabs? How is that even related? “Adding better support”? This problem is so obviously wrong—why can’t you just fix it?
That just doesn’t feel reasonable. I wouldn’t want to receive that email. It needs work.
But starting with our first draft skeleton, I’ll work with an engineer to deeply understand 1) why the problem exists and 2) why it’s hard to fix. I’ll take detailed notes regarding both of those points and then use those notes to inform the email copy, which I’ll ask the engineer to proof read for technical accuracy. This produces copy we can have at the ready if other reports from customers come in.
So I might start with “under certain situations” and ask questions until I clearly understand what those situations are. How do multiple tabs come in and how does that result in timestamps being incorrect? And tell me about the work involved—why is it a lot of effort? It’s just a series of questions until you get to a finished set of words you’d be confident sending to a customer.
Here’s what we went with:
After discussing this issue with engineering, we have a clearer picture of what’s going on and what it would take to fix this issue.
The long and short of it is that FullStory doesn’t have great support for end user sessions when multiple tabs are involved. This goes back to the very earliest design of FullStory, which really only imagined single tab recording and playback, and we’ve never managed to circle back and add true multi-tab support.
Because we never truly implemented multi-tab support, our customers have run into several instances where our attempt to get multiple tabs to play back in a single session appears rather clunky.
Here’s what’s happening: When the event stream is created on the right hand side, it is “linearized” (meaning, timestamps happen in order). However, with a multi-tab session, the events in the playback window get ordered according to how they played back in their tab, not necessarily the chronological order of events. If we had had multi-tab in mind, we likely would have taken a different approach.
To address this issue will require a considerable amount of engineering effort. To start, we’d need to modify the design of the playback interface to accommodate multiple tabs. Part of what’s stalled our efforts in the past is that we’ve seen sessions with a great number of tabs and we’re not quite sure yet how we’d want to handle that scenario. Assuming we get the design ironed out, we’d also need to be able to more reliably track “tabs” within recording (again, FullStory assumes a single “tab” right now and intuits tabs based on page timestamps and navigation). Lastly, because adding true multi-tab support will likely introduce multiple playback frames, we need to be extra careful around performance concerns. To the latter point, we’re currently focused this cycle on a host of performance improvements with playback which will lay the foundation for future work in multi-tab.
All of this is to say, while the underlying bug you reported is relatively straightforward, its long term fix is going to take considerable effort. While we don’t have a timeline to share, we wanted you to be in the loop with the effort involved and what it will take to eventually get this bug fixed. We’re going to go ahead and close out this long-running support ticket, but we’ll reach out when we eventually ship support for multi-tab sessions.
Did you read that whole thing? Bless you. Hopefully it was clear.
Etc.
Things I’ve read:
Eye to eye with a whale. Neat story about sperm whales.
‘Crush This Lady.’ Inside eBay’s Bizarre Campaign Against a Blog Critic. This one is nuts. How on earth someone aligned someone else’s incentives to do these things.
How to Lose a Billion Dollars Without Really Trying. There are so many quotes, “Weinig and Aiken — a confident pair of former Goldman Sachs guys, which may be redundant”. Just read it.