Support Accounting | Customers, Etc.
Mapping our work to financial statements can be fun (right?)
Oh fun! With a title like that, who wouldn’t want to read this post?
Ahem.
I received an email last week from a support manager asking about “small team metrics”. Paraphrasing, her point is that when you have a small team, it can be hard to trust your data. And if you don’t trust your data, how do effectively communicate to leadership at your company?
This is such a great question. And if you’ve ever worked at a startup, you probably know exactly what she means. We had this problem at Trello, which is why a member of my team wrote this post about tiny data1. You don’t always have the data, but you might have enough to make the right behavioral changes in the systems you have.
Still, let’s try to answer this question in the most seemingly illogical way possible, by looking at the financial statements of a large public company.
Public company comparison
Perhaps we should start by asking ourselves:
“How do other companies do it?”
Why? Why not just offer the best possible customer experience all the time? Because strategy is about the actions you take relative to competitors. It doesn’t happen in a vacuum.
With that in mind, let’s take a look the annual report (10-K) of a public software as a service (SaaS) company to get a sense of what they’re spending on customer support. In reality, it’s not that easy. But let’s dive in anyway to see if we can get a sense of what we’re working with.
Let’s look at Zendesk. Zendesk is no longer a public company, but in their last annual 10-K, which was filed for the year ending December 2021, they recorded $1.3B in revenue with a $274M cost in revenue (go to page 67):
There are a lot of numbers there. How do we know customer support costs are in Cost of revenue and not Sales and marketing or General and administrative? For this particular 10-K, the notes preceding the financial statement are somewhat helpful. Here’s an explanation from page 52 (emphasis mine):
Cost of Revenue. Cost of revenue consists primarily of personnel costs (primarily including salaries, share-based compensation, and benefits) for employees associated with our infrastructure, product support, and professional service organizations, and expenses for hosting capabilities, primarily for third-party managed hosting services located in North America, Europe, Asia and Australia. Cost of revenue also includes third-party license fees, payment processing fees, amortization expense associated with acquired intangible assets, amortization expense associated with capitalized internal-use software, and allocated shared costs. We allocate shared costs such as facilities, information technology, and security costs to all departments based on headcount. As such, allocated shared costs are reflected in cost of revenue and each operating expense category.
That’s a very large bucket in which to include product support. It’s in the same bucket as cloud costs—which is going to be significant—and even professional services, which presumably generates its own revenue2.
How should we interpret this? On the one hand, we could take a simple approach and just look at product support as a cost center. All things being equal, we want cost of revenue to go down.
Except not quite. As long as cost of revenue as a percentage of total revenue is decreasing, we’ll likely be okay with spending more to support our revenue growth. Here’s page 54 of the 10-K:
Okay, this is progress. But are all product support costs really included purely in Cost of revenue? Let’s say that, hypothetically, your engineering and product teams release a new feature that’s really buggy. Customers aren’t happy and they send a lot of emails and chats to customer support. You might have to hire more support people to deal with the incoming volume. But then the company decides to take some developers off of working on new features so they can fix the bugs that are generating so many support requests.
Your engineering and product teams that are working on new features are likely going to be included in the Research and development line item on your 10-K. When the company decides to reallocate resources to fix bugs of a feature they just shipped, are they then going to say that time was spent on Cost of revenue vs Research and development? Probably not3. This support cost is baked into R&D.
Which, isn’t that exactly what you would want? How awful (and expensive!) would it be if each time you shipped a bug, you just expanded your support team rather than fix the underlying issues? That would be insane.
Revenue and brand value
We’re still not done! We’ve been primarily looking at product support through a cost lens. And cost is important. If you lead a customer experience team with a heavy product support component, you must be mindful about cost. But product support is also about revenue.
There’s short term revenue, which might come in the form of recognizing opportunities to identify customer pain that the customer doesn’t know you solve and then selling them the solution. For SaaS companies, the selling part likely isn’t going to sit within product support, but the identifying customer pain part certainly can, at least partially.
Another way product support can impact short term revenue is through customer churn. Negative support interactions can trigger a break in the loyalty loop:
However, a bad experience can trigger the beginning of the evaluation process all over again. As consumers, we hate this. We don’t want to spend the time and energy doing due diligence on every purchase we make, which is why we’re happy to be loyal to brands that give us a reliably positive experience. Having to actively engage our brains on evaluating new brands and products is laborious, so we tend to get frustrated when a brand to which we had been loyal delivers a bad experience and forces us to enter the evaluation loop again.
There are also long term impacts to breaks in the loyalty loop. You might retain a current customer but lose a champion product user who will choose a different solution when they move on to a new company.
On the positive side, there’s a long term revenue upside from building a strong brand. Product support is very much a part of the company’s brand offering. Delivering great support means customers feel heard, the product remains strong, and the company creates trust when it brings new products to market.
Notice how we haven’t even talked about the Sales and marketing line item. You could, hypothetically, invest heavily in sales and marketing and then totally drop the ball when it comes to onboarding your customers and supporting your product. Like pouring water quickly into a leaky bucket, revenue will temporarily increase but will decline over time.
When you look at Zendesk’s 10-K, how can you really tell what’s happening under the hood? Looking at just the 10-K, you can’t. Wouldn’t it be helpful to have the details? Sure it would, but you don’t need the details to understand the broad strokes of how certain decisions can impact the underlying financials.
What’s a small company to do?
If you work for a small company, you don’t have the burden of filing audited public financial reports. Perhaps your company has budget discussions in terms of “headcount” rather than “P&L”4, but the underlying fundamentals are the same.
This is why it’s so important to think in systems. Trying to keep the cost of revenue down is part of a balancing feedback loop. Improving long term brand value is part of a reinforcing feedback loop. How you communicate these systems will change depending in part on the size and maturity of the company, but the underlying systems are likely the same.
When you model out your team and its related work in terms of systems, you better understand the context of various metrics that inform the performance of your team. For small teams, thinking in systems is critical because you often don’t have enough data to justify decision-making based purely on the available data. You have to approach problems from first principles. Modeling out our support systems helps with that.
What do you think? Is looking at a public company’s 10-K helpful? Are you an accountant and want to call me out on my interpretation (please do)? Leave a comment or reply via email and let me know your thoughts.
Although Trello’s team size was small, we had the luxury of having millions of people using our product. So at least when it came to overall product usage, we had plenty of data. But our contact rate was (thankfully) low, so we had a lot of noise in our customer support metrics.
It’s interesting that Zendesk doesn’t break out professional services into its own revenue stream. Salesforce, in its 10-K, has separate line items for “Subscription and Support” and “Professional services and other”.
I’m not exactly sure what would happen here, but I’m assuming that most of these headcount calculations are done with whole numbers. I have a hard time imaging the company would narrowly track an engineer’s time so they can account for it transactionally, but I could be wrong.
If you’re an accountant with deep arcane knowledge about engineering accounting at public SaaS companies, I would love to hear from you about how this would work.
P&L stands for Profit and Loss, which is another way of referring to the income statement. Zendesk called it “Consolidated Statement of Operations” in their 10-K. It’s all the same. Revenue at the top. Profit (or loss) at the bottom.