Inedo has exactly zero tech support reps and there’s no phone number to call for help.

A lot of our users and new employees are surprised by this.  How can an established, B2B software company have no dedicated support team? You mean to say that when something goes wrong, we can’t jump on a phone call together?

We do provide our users with great support. In fact, our support is why so many users buy and renew.

In this article, I’ll explain traditional B2B tech support, my own perspective as Inedo’s founder and CEO, and how I came to an unconventional decision that’s been benefiting both Inedo and our users for many years.

The Traditional B2B Support Model

We’ve all experienced the conventional, multi-tiered tech support model.

Problems start with first-tier support, which generally involves gathering basic details and working through troubleshooting scripts. Complex issues get escalated to specialists, who will ask for more information and may even need to involve the engineering team. This all happens asynchronously, which means any solution involving even a trivial software change can take weeks to resolve.

Everyone accepts this reality, but no one’s happy about it. Customers understand why they don’t interact directly with engineers, but they’re frustrated by delays and by having to repeat themselves at every step.

Engineers are frustrated by losing critical context as issues move across tiers. Support reps are frustrated playing the middleman between teams. And sales teams are frustrated trying to get a clear picture of what’s actually happening across accounts when unresolved issues start to impact renewals.

Fortunately, there’s a solution. It’s called Technical Account Management (TAM), and many B2B software vendors and their customers expect this model.

Technical Account Management: The Solution?

With TAM, a Technical Account Manager is assigned to each customer as their regular, sole point of contact. In weekly meetings, TAMs inquire about new issues from their customers and report progress on issues from previous meetings. Behind the scenes, TAMs work between support, sales, and engineering to prioritize and gather information.

This idea was totally foreign to me in the early days of Inedo, when we could still count our paid users on two hands. One of those customers asked if we could do a weekly Technical Account Management meeting. Not really knowing what it was, I naively agreed.

How bad could it be?  I thought.

But instead of speaking with the actual end users, I met with the “software owner” who just assumed I was a fellow middleman. He would share screenshots of “stack tracks” (he never quite learned the word “stack trace”) and I would try to provide troubleshooting tips and commands to run.

The meetings were slow, inefficient, and ill-suited for our small technical team and technical end-users. It was painful to be able to work directly with our end users and, the entire time, all I could think about was the Bobs coming in and saving me.

To me, it was more obvious than ever that the traditional way of doing things just wasn’t for us.

Support As Everyone’s Job

I realized that Inedo’s offerings, customer base, and the problems they face all differ from the norm. For one thing, we’ve made our software easy to troubleshoot and constantly improve upon it whenever users submit issues. For another, our customers are software engineers themselves, with plenty of technical experience. They don’t need help with performing basic tasks, they need help when our software behaves unexpectedly.

With all that in mind, I decided that support at Inedo should be different, too. 

No hurdles to clear. No middlemen, no chatbots, no one reading from scripts. Instead, our customers communicate directly with top-tier support: Inedo product engineers, including myself. Customers can get in touch with us via our forums (all users) and ticketing system (paid users). But they can’t call us.

Why Can’t We Just Jump On A Chat or Call?

We’ve tried to make “live support” work many times in the past, but support-related phone calls and chats just aren’t productive. The sorts of things that go wrong when using our software can’t be solved with troubleshooting scripts, which means they can’t be solved in real-time. All of this is especially true in an emergency scenario.

To troubleshoot an issue, we need to gather and carefully assess a great deal of information. We need to examine stack traces and source code. We need to consider underlying causes and potential solutions. All of that takes focus and concentration, and happens faster and better without distractions.

A lot of times, the issue is unrelated to our software. For example, a misconfigured SSL certificate will cause all sorts of weird errors when trying to connect to a server — and we are not any better at troubleshooting random Linux HTTPS/SSL problems than ChatGPT.

But that doesn’t mean we totally avoid talking to customers. Quite the opposite in fact.

When Calls Make Sense: Proactive Guidance

Instead of reactive support calls, we do something called “customer success,” which is basically just the trendy word for “onboarding.” As part of this program, we try to get new customers to attend a proactive advice and guidance session with one of our product engineers to review their setup and learn what they’re trying to do with our products.

It’s more challenging than it may seem to get scheduled. Most users have already implemented before purchase, which means we need to persuade them that it’s not going to be a scripted, “customer success” session that walks them through the basics.

We also offer options beyond this initial onboarding.

Professional Services & Our Version of TAM

Our professional services are there to help with everything from advice to auditing to hands-on installation. While other vendors often bundle these with licenses, that didn’t make sense to me because only a relatively small number of users require them.

As far as TAM, I’ve grown to understand why it’s important. Some organizations want visibility into all issues with the products they use. Instead of having engineers directly submit tickets, they use a centralized “platform team” as a go-between. However, those teams rarely have tool/domain experts and thus struggle to “translate” what their end-users need help with.

That’s where our “Dedicated Support & Solutions Architect” offering can fit: periodic meetings with a single point of contact who makes sure everyone’s on the same page, including end-users. While not a product engineer, the Solutions Architect will become familiar with the customer’s installation and team, then proactively work with the customer to solve problems in our products and beyond.

Conclusion: A Success for Us and Customers

We’ve found what works for us through a long process of trial and error, and it definitely works: software and documentation issues are often identified and fixed within the initial query, benefiting all users. From a business standpoint, our existing customers leave glowing feedback and stick with us and prospective customers are convinced to join us.

For years, I was convinced that this approach simply can’t scale and, at some point, we would need to hire a support team. That day hasn’t come, for one reason I hadn’t considered.

The more we support our products, the more we learn how to support our users, whether through an improved UI and documentation, clearer troubleshooting messages, or better diagnostics. And we also learn how not to create problems for ourselves when developing new features.