I used to think that responding to customer service requests as soon as possible was an unequivocally good idea.
After all, who doesn’t want to show their customers that they truly care about them? That they would drop everything to help someone in need?
But this dedication to responding quickly comes at a price. A hefty price. And I paid that price.
Today, I will dive into the pros and cons of super-quick customer service responses, what software tooling has to do with it, and how you can approach balancing response speed with good business sense.
Striking a Balance
Because the balance between reacting quickly to customer inquiries and dealing with a myriad of other business issues isn’t something that new founders think about much when they start.
Experience this article as a podcast, a YouTube show, or as a newsletter:
I certainly didn’t. When I co-founded FeedbackPanda and was responsible for the technical questions our users submitted through email and our in-app chat widget, I quickly prided myself on getting my average response time during the day to under thirty seconds.
It became a game. How quickly can I turn the notification into a message to the customer?
I wanted to wow our customers and show them that they were my number one priority.
And it worked. They certainly were surprised, and many times, they told me that nobody had ever responded so quickly to them before. They felt special for being cared for with such urgency.
At least after I assured them that I was real!
Most customers who got a lightning-fast reply thought I was just a bot — because, in their minds, nobody responds this quickly. Often, I would have to prove that I was actually the founder of the business, which was also something people didn’t expect. In a way, my initial speed would cost me several minutes because I had to establish that I was the real deal. Ironic to think that had I waited a few minutes, people wouldn’t have been so skeptical.
It all boils down to expectations. And as much as I did more than people expected, my actions looked fully automated—something a machine would do.
And I’m a huge automation fan — I believe that good documentation and, originating within that, automated processes are central to building a valuable and sellable business. Yet I was doing all of this manually. I would drop whatever I was doing to serve the customer. Immediately.
It was a few months into building the business that I noticed that I had betrayed my actual priorities as a solo technical founder. I was supposed to build the product, stay in my flow state and work on the complex technical implementations of massively valuable features.
Yet here I was, jumping up from my codebase to help a customer figure out that they should log in using Facebook instead of Google.
I deprioritized my high-leverage impact on all customers to prioritize a single customer’s problem, which often turned out to be pretty mundane. I devalued my own time by not prioritizing the things that would improve everyone’s experience.
And, sure, this can (and does) work when you’re starting out, when you’re dealing with a shaky prototype, but you will quickly have to drop this once your customer base grows. Like Spock said in The Wrath of Khan: “The needs of the many outweigh the needs of the few.” For any low-touch software business, this is a core tenant of successful operations.
Which is something I realized once my developer productivity tanked. I kept doing this for way too long, and being constantly interrupted caused all my non-customer-service work to suffer. Coding, product management, marketing: whenever I was working on something that required me to build a mental representation of a complex plan or concept, a single Intercom “ding” sound could destroy hours of work.
It caused my mental health to suffer. I focused on responding to intercom notifications so much that I developed waves of anxiety when I heard the Intercom “ding.” I still have this, more than four years after selling that business. The sound of a chat bubble brings it all back.
So maybe, optimizing for response times is not the best idea.
A Layered Approach
At least not doing it all by yourself. Apart from hiring a customer service rep, there’s a way to have your speedy cake and eat it too. You might as well embrace the bots: your first layer of defense can be tools. In fact, they should be tools.
Because tools are always awake, and they can respond faster than any human agent. And your customers will actually appreciate that because they don’t want to talk to a person. They want their problem solved. And ideally, you don’t even have to be involved.
Most people prefer to solve their own problems instead of having someone tell them how to solve them over chat. It’s a self-confidence builder to “figure things out” with a little help. And if that help is just a video or a few bullet points, ever the better. Immediate self-service trumps delayed hands-on help—almost every time.
Self-service help can be very powerful, particularly when you’re good at guiding people through the use of multimedia. I have found that people love founder-narrated video walkthroughs, even if it’s just a few clicks. A demonstration that’s easy to follow is something most people prefer to being hand-help to success. Try using images, or better, video, as much as possible when you build your self-service knowledge base.
A tip for filling that knowledge base:
- Whenever you solve a problem manually through chat or email for the first time (and expect it to happen again for someone else), document it right after.
- Take the 15 minutes you need to record a Loom or a VidGuide video and integrate it right into your helpdesk.
- Write a few paragraphs to make the solution text-accessible (and indexable), and you’re done.
Done for now and done for the future.
Because AI tools make self-service particularly easy now: they have access to your full documentation and can automatically suggest suitable articles within a second of a customer asking. And if nothing can be found, these tools can always escalate to a real human being, likely you. You might want to wait with that even: ChatGPT-based systems can even hand-hold your customers through multi-step processes while answering their questions. It helps to have a very elaborate knowledge base for that. That’s why it pays off to write the article immediately after a solution. All future occurrences of that problem will be something your customers can solve themselves.
Just one warning, and a big one at that: when you use software tools, don’t act like your bots are people. Be honest and tell people that they’re being helped by a smart documentation tool. The moment you lie to your customers about who they’re talking to, you play with fire. People are smart. And they will never trust you or your business if you tell them the obvious robot is a real boy.
You don’t need them to think your tools are people.
All About Expectations
Consider what your customer needs when they reach out: they have exhausted their capacity to either solve their problem or find a solution that gets them there. They likely googled already, or they clicked through every part of your software they could find, trying out everything. Their problem is critical enough to reach out and warrant risking confrontation with a company representative.
They don’t want to talk to people. What they want is workable advice as soon as possible. The way they get there matters very little to them.
It took me a long time to understand that my customers also wanted something I was actively working against by responding as fast as I could every single time: they want my business to succeed because that helps them succeed. In retrospect, my customers felt more empathy for me than I had for myself back then.
I was scared to leave a bad impression. And so I overcompensated.
The way out is to set realistic expectations around replies. —more for yourself than for your customers. They have a much higher tolerance than you might think. They can wait a few minutes; in fact, they probably got up and grabbed a coffee right after sending that customer service message.
Just optimizing for response speed is reductive and can actively harm your entrepreneurial impact. The exception: if you’re solving a particularly critical problem, you need designated customer-service reps.
But if your product doesn’t need real-time answers, a few hours delay won’t hurt anyone either. This is something you can ask your customers about in a follow-up message once they get done with what they asked you to help them with. “How quickly did you need that answer?”
Don’t jump the gun.
Consider that as a founder, your customer service hat is just one of many. We all want our customers to be king, but a quick reply isn’t the only way to do that. Building products that need fewer customer service interactions is another way. Focusing on building features that save your users so much time that they can read the documentation thoroughly can work, too.
So when that chat bubble dings the next time, consider that what you’re doing right now might be the more important thing to do.
And then, once you’re done, help your customer.