Early-Stage Customer Support

Apr 2015

The most difficult time to support customers is when everything (your startup, product and team) is new.<...>

This is mostly down to three reasons:

  1. The To-Do list is way bigger than the actual amount of human hours, focus and energy that is at your disposal. (And many startups de-prioritise customer support as a result.)
  2. The product is immature, which means it doesn't account for any / all edge cases, documentation might not be available or the UI / UX just doesn't make sense in some places.
  3. Users expected the product to have certain features, which means many support requests are actually just feature requests.

What this means is that early-stage customer support is challenging and almost always non-obvious.

At Receiptful we proactively focus on giving our customers the best possible experience and we've spent a lot of time on our customer support. I believe we've built a customer-centric company, where the consideration is always on doing what's best for customers and not what's the quickest or easiest win for us.

In my mind this is what sets startups apart and this is how you initiate a long-term, loyal (and ultimately profitable) relationship with one's customers.

The reality is however that I've said "No! :(", "I'm very sorry about that!" or "Unfortunately Receiptful can't do that yet." more often than I would've liked. Whilst I understand our reality which has multiple limiting considerations (small team, self-funded, need to have a narrow focus), it's hard to communicate that to customers in a way that creates a good customer experience.

With that in mind, here's three ways in which we've created a better support experience for our customers regardless of any limitations or challenges:

1. Contextual Transparency

The very first consideration should be that if your customers aren't other SaaS / tech companies, then they have no context as to the challenges you are facing. This means that it is important to transparently educate them about that context, which essentially puts the ball in their court, where they can decide whether they want to stick with you or churn.

I see this most in the kind of interactions where a customer has asked whether Receiptful works with another, third-party application they're using. The answer to this is generally "Unfortunately we don't offer support for X at the moment, but we hope to do so in future.".

The reality is however that support for third-party applications is the least of our priorities, as the combinations are endless: Customer A wants to use Receiptful + X + Y, whereas Customer B wants to use Receiptful + X + Z. You ultimately get into the infinite possibility of fuck-ups, as you essentially try forcing X + Y + Z to all be compatible.

In this sense, the better response would look something like this:

Hi John,

I think that integrating X with Receiptful would be very valuable indeed and it's something that we unfortunately don't support right now. It is however on roadmap and we hope to support this ASAP.

The reality is however that we have a very small team and our to do list is already very demanding. The challenge we have with integrations like this, is that the possibilities are ultimately endless (with our other customers requesting support for other apps for example) and as a result, it's difficult for us to prioritise this amongst our other to do's.


This is honest. It might not be pretty and it won't be what the customer would like to hear, but they will respect that explanation and might even have empathy with the situation.

I think the caveat to this is also that in many of these situations whatever the customer is requesting is generally closer to being a nice-to-have than a have-to-have. So by being transparent and giving the user context, you're increasing the likelihood that they'll stick around for the features / value that you already offer.

2. Narrow Focus, Liquid Order

The only way to make progress with your startup and product is to have a very narrow focus on your roadmap. This requires always keeping the bigger picture in mind, prioritising the tasks that gets you there quicker and being very disciplined in applying this approach.

This requires saying "No." to the vast majority of feature requests even if that means that you'll lose some customers early-on. That is an unfortunate truth of an early-stage product.

Where I've however broken this focus is when both of these conditions have been prevalent:

  1. The request is an easy task that was already on our roadmap. This means it mostly just requires a reshuffle of the order of the tasks and it doesn't end up being a big distraction to the team.
  2. The change does not only benefit the customer that made the request, but many other customers too.

In my mind this means that this is an easy win that we can exact for a customer, which creates a fantastic experience for them.

3. Understand The End-Goal

This has been something that I never thought of implementing at WooThemes (or I wasn't conscious of it), but have found immensely valuable with Receiptful.

Every interaction with a customer is a customer development opportunity, where you learn about their needs / wants and how you're meeting (or not meeting) them with your product right now. The challenge with innovative new products though are that the customers tells you that they specifically need X and you can't give them that exact thing.

But you could still probably give them the same benefit. I'm reminded of this Henry Ford quote:

"If I had asked people what they wanted, they would have said faster horses."

So whenever a Receiptful customer asks me whether a certain product feature can do X or Y, I'd always respond with something like this:

Hi Sally,

Unfortunately Receiptful can't do that at the moment.

Can you perhaps explain what you were hoping to achieve though (in the event that Receiptful did support that feature)? If you let me know, I can possibly recommend a workaround or alternative solution. :)


I could've just stopped with the "Unfortunately..." sentence, but by asking the customer to explain the potential benefit they're pursuing, you turn this into a learning event, which has had two benefits:

  1. Sometimes this actually just provides me with clarity about what the user was really asking or what they really wanted, which means I can actually explain how they can achieve that.
  2. If that's not the case, I've learnt how we can possibly evolve the product in future.

Either way you have engaged your customer, listened to them and communicated that you care about their wants and needs.

Historically the "the customer is always right" mantra was adopted as the definitive mindset to apply to any customer interaction. Unfortunately I don't think that this is always optimal, as the needs of both customer and company need to be balanced (if one is to achieve mutual, long-term benefit).

I do however believe in a customer-centric approach, where the aim is to delight all customers and / or create the best-possible customer experience for everyone.

The interactions I've described above probably adds 10% to 20% on top of the time I'm already spending interacting with customers, but the benefit is much, much greater than that.

You also don't have to believe me blindly; take a look at how often our customers mention the support they received (in addition to the product being good). :)

You've successfully subscribed to Adii Pienaar
Great! Next, complete checkout for full access to Adii Pienaar
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.