What we learned from providing support for our 1$ tool

Hey! We're from Pause - we're a B2B SaaS tool that helps people take time off and organisations to plan work better.

Every day at Pause, we trawl through user queries as a to-do list priority.
Some give us fascinating insights; others leave us staring into space. We debate and question these questions, and the revelations either pave the way towards a better Pause or convince the team of a job well done.

And all the while, we reflect on one oft-repeated advice from other founders—don’t provide customer support for an inexpensive tool—and think to ourselves, “So they’re willingly missing out on all this gold?!”

Here’s the problem

We could sum up all the cookie-cutter advice we’ve received in one simple sentence: if we’re selling a tool as inexpensive as Pause, it needs to be self-serve. We literally cannot afford to spend time on support.
And to that, we have one question: How else do you learn from your customers asynchronously? Hear us out.

Here’s how we approached it

When most people think of support, they imagine having to do things for their customers that their product can’t. Yeah, it would be too expensive—even unaffordable—to offer that kind of support for a tool that only costs a dollar per user.

But what if you look at support from another angle? What if you see it as assistance for your product, not the customer? What if you use support as the product’s training wheels until it’s sophisticated enough to find its own balance?

That’s how we see support at Pause.

We look at support as a research tool

In the initial stages of building, you don’t know what does and doesn’t work and can’t knock on your customers’ door repeatedly, saying, “and one more completely generic question!” So how does using support as a research tool help?

When users reach out to you for support, it arms you with data about how your tool is being used. And that enables you to ask sharper questions that give you a better sense of direction than preliminary user research in a simulated environment can’t.

This is pretty unconventional. Most product teams steer clear of offering support for inexpensive tools, but we see it as a way to conduct better research and improve our product by miles.

We leverage support as an unconventional marketing tool

Imagine you’ve got this Gloriously Amazing Feature (as a matter of fact, we have plenty of those). But you don’t see much traction. So you bite our nails and wonder: why hasn’t my customer discovered this Gloriously Amazing Feature that’s so obvious? Or worse, have they found it but don’t think it’s important? Maybe they don’t quite understand how it might help?
Support is the best way to get answers to all of these conundrums, and then some. Even better, you’re able to walk customers through some of our best features so they can hit the ground running. Finally, you’re able to communicate the value of your product to your customers without hounding them.

Sure, it’s not traditional marketing. When you think of that, what probably comes to mind is “ways to acquire new customers”. Except that’s changing with the whole product-led growth movement. Now, promoting the true value of a product is a priority instead. And it’s a good time to get on that train.

We use support as a retention tool

Customers stay when their problems are solved, else they walk out the door. And support solves that, sure. But having a thin slice, $1/user tool means doing a better job at making it problem-free. So you wouldn’t need support in the first place, right?

Wrong. Dead wrong.

For a lean piece of software like Pause, the job of support is not to resolve customer queries (and there will be a handful of those). It’s to bring those customers back to the tool who dropped off because the gap between their first tour of Pause, and the first time they used it to take time off, was too long.
With the help of Intercom, we gently nudge them back into the fray through emails and encourage them to take a break if they haven’t in a while.

We hope this guide brought value to you. If you have any ideas, questions or follow-ups, please comment or DM us. We're also building a newsletter where we share our journey so do sign up if you want to!

Link: http://eepurl.com/hzDS_H

  1. 2

    Interesting perspective, thanks for sharing! It's not the "common advice" and I totally agree with you, although I'd like to add an additional ingredient to the mix here besides pricing, which is how often a user interacts with your app.

    In your case, seems like it's a low-touch product, which would make it a perfect fit for what you guys are doing. But the more frequent the interactions with your product are, the higher the risk of something failing or a user simply needing hand-holding and making customer support unsustainable.

    I'm thinking about charging around $3/month for my product timeivy.com. But to be honest I'm also a little scared of the customer support side of things. On the other hand, I could go with a higher price to try to justify these needs, although at the expense of fewer customers.

    Would you have any piece of advice to someone like me which might have a product with a higher frequency of usage?

    1. 1

      Thank you!

      This looks great, honestly. My advice would be to look at the journey of a customer with your product from start to end. Where will they get started with it, customise it, etc.

      And think about where issues could pop up, and pro-actively start solving for those in FAQs, documentation etc. We’re using our beta period to listen to customers and not just resolve the most common bugs, but also to solve for a lot of possible support issues that could emerge in the future.

      So we’d be writing a lot of support documents and FAQ guides so that most common queries could be resolved by the users themselves.

      So ideally we wouldn’t be overwhelmed by most customer inquiries and be able to provide the same level of customer support at any scale.

      I'd also take a weekend to brainstorm on possible future bugs or failure modes (what if a browser update kills your extension? What if it doesn't work properly in certain VPNs? -> establish a heirarchy of bugs and beforehand and try to create processes for each. A simple query about something? Send them the respective chapter in the manual, for example.

      Hope this helps. Happy to talk about this with you more on a call if that could help too

      1. 2

        @TeamPause thanks so much. What you mention about proactively solving potential issues is particularly important and something I have yet to do. I also found your "How to make onboarding self-serving" article pretty insightful.

        On a related note, I love your website, from the design to the copy. Great job! :)

        1. 1

          Thanks for your compliments! The designer will be very happy to hear that 😄

Trending on Indie Hackers
Event-based customer knowledge base - what do you think? 38 comments Building a Shopify clone🤪 (it's for a one-time small fee, no recurring fees/commissions🤩). 9 comments We just reached a major milestone: $500k ARR 🔥 6 comments Idea to 350k Users 6 comments Curious to know why aren't devs implementing WebAuthn for their sign-up & login flow 5 comments Hidoki - build in public 3 comments