11 Ways Your Startup Can Deliver Support That Will Increase Sales

By Jason Baptiste on October 29, 2010

support for startupsSupport is often an after thought for many startups in terms of the impact it has on your time, sanity, and development resources. It's usually a tedious chore that is a second class citizen. Or...Maybe it's not. Maybe your startup worships at the altar of Zappos. If you do, odds are the influx of support hits you from out of nowhere like a sucker punch. Here's what I've learned about preparing for support, how it decreases churn, and increases sales.

Pre Sales Support Will Bring Up Patterns Of Lost Sales

Everyone seems to think that their funnel and their website copy is absolutely awesome. In reality, it comes down to not knowing what you don't know. There are usage patterns that will cause confusion amongst potential purchasers of your product, that you could have never imagined. By implementing a strong pre-sales support system, you will start to gain pattern recognition into what is causing you to lose sales. The best way to catch these issues is to implement live chat systems like Olark, a phone system like Grasshopper, or a simple pre-sales FAQ.

Example: With PadPressed, many potential customers wanted to see a working demo on their iPad. We thought we had this clearly stated on the Demo page. As it turns out, we didn't. After five requests in a day, we realized that we needed to heavily emphasize the working demo portion in the copy. We modified buttons on the homepage and we highlighted the links to the live demos on the Demo page. It worked. There have been more clicks and more requests about this.

Build As If You Have To Support It

I'm stealing this quote from Kevin Hale of Wufoo, but it's truly one of the most important product focused quotes I've heard over the past year. Whenever you want to add a feature, especially the nifty ones that may be confusing or buggy, think about the impact that will have on support. Also think about a feature's implementation and how it plays into cross platform compatibility. For every feature you plan on adding, expect more of the following:
  • Extra support ticket requests ie- Each feature will bring about way more support tickets that require more time, which is something you're already strapped on.
  • More pre-launch documentation ie- You will have to spend more time on Q&A, writing documentation, doing tutorial videos, etc.
  • More complexity in your sales and/or fundraising pitch ie- Your cool new features have nothing to do with your simple problem/solution statement.

Triage Critical Requests Post Launch and Freeze New Dev

After every launch of PadPressed, there are usually one to two specific problems that are major issues. For our most recent launch, the timthumb library was being wonky with Wordpress MU + external images. Instead of adding some of the new things we had planned, we had to focus solely on releasing a major update for this issue. The adrenaline from a successful launch will lure you into wanting to do more "cool stuff" for customers. In reality, if you don't double down on getting past the critical bugs, they won't be customers for long.

The Knowledge Of The Customer Community Will Save You

If there's a way to create a customer support forum, I strongly suggest it. It could be something like GetSatisfaction or it could be a private forum. Most problems that customers would normally open up a ticket with you for, will have been solved in the past and publicly available in the forums. I suggest that all tickets are made public and viewable by users. Another benefit of having a great community is the fact, that other customers will help out new customers and give suggestions. The math adds up over time. Here's some math:
  1. Assume each support request takes an average of 15 minutes to deal with.
  2. You have a total of 400 support requests per month.
  3. 50% of those support requests could be solved by having past knowledge public. (200 total)
  4. That's a total of 50 hours a month, which adds up to a lot of saved time, energy, and frustration.

Support Is A Reason To Charge

Support is a reason to charge, especially when dealing with a freemium model. As geeks, we may be able to do everything ourselves, but in the real world, most normals love to have their hand held or have someone on call to help them. You could charge for premium support or you can even bake it into your price. Apple's genius bar and training programs seem free to customers, but they're actually a good reason why Apple products command such a premium. Look at Zappos as well. They spend good money on providing a first class support experience and it's why they're able to do so well. Once again, THEY SELL SHOES. The support experience has allowed them to command a dominate spot in the market and differentiate themselves by selling shoes. Apple and Zappos' models are indirect ways to charge for support. Many open source and freemium companies charge directly for support and make big bucks doing it. Some may say that this model doesn't scale, but I say baloney. We're a connected and distributed world where there is an infinite amount of labor on demand to help with support.

Escalate With Discretion

As a startup with strapped development resources, escalating issues to the development team requires a certain graceful balance. Certain critical issues and larger customers require you to bring issues to the attention of the core dev team. The problem is, attending to these issues can slow down new development and an already large onslaught of bug fixes. This is also another area where you can charge for a more advanced level of support.

They Will Calm Down

Odds are you will get the fanatical pissed off customer that thinks they are entitled to everything to going perfect or ELSE. Chill out and breathe. They've been burned by the pain that is poor service in the past and they want to make sure your little unknown company pays attention. Respond fast, help them out, and just hold their hand. They will likely calm down and become your best friend at the end of the day.

Be Directly Wired Into Support As A Co-Founder

Even if you're lucky enough to have the funding/profits that you don't run support yourself, you should be directly piped into what is happening with pre and post sales support. I have every customer inquiry for pre-sales sent to my phone instantly and all support threads pushed via email automatically. Some I don't respond to as the rest of the team takes care of that, but I know every issue that is going on.  A culture where support is important needs to come from the top down.  If the co-founder of a company doesn't care, then why should anyone else?  Set an example.

Email is a Sandtrap

Users and customers will undoubtedly email you asking for support. It's not that you should avoid helping the customers or that supporting them through email is beneath you. It's actually the worst way possible to deliver support. Conversations get lost in the shuffle and require cc'ing and sending emails to other team members. Keep email for pre-sales support only as that is a much easier way to deal with customers. Here's the trick to deal with email support requests:

  1. Take the issue they stated.
  2. Create a forum thread with that issue and copy/paste their email exactly 
  3. Respond to their email with a nice note, thank them for being a customer, and give them a link to the issue you opened. Make sure you let them know the following: a) We opened a support thread so we can serve you more rapidly and b) You get the benefit of having an entire community that may be able to help you.

Bad Support Won't Sink You, But Great Support Will Make You Rise

Listen we all complain until the cows come home about Comcast and AT&T, but at the end of the day, we still have our iPhones and Cable. I don't advocate bad support, but somehow companies get away with it. Maybe in a world of transparency due to social media that won't be the case in 20 years, but it sadly is right now. That's not the way to think about it. Look at it the opposite way: Having great support WILL make you rise above the pack. People will remember it and people will talk about it to others. That great experience will let you rise above the rest.

Don't Skimp On Awesome Tools

As a startup and/or developer you don't skimp on your equipment and you shouldn't skimp on the software you use either.  $50 a month might seem a lot for a piece of software, when you're running on ramen. Guess what?  It's a long term investment that pays off in the end.  If the lifetime value of your customer is close to $100 and you lose 2 customers a month because your support is a mess due to stringing together email, you actually lost a net of $150 per month.  Don't be pennywise and pound foolish.  Here are some of the good tools I've come across.

  • SupportBreeze- SupportBreeze is by my good friend Mark Bao. It's a great, simple, and elegant support ticketing system. It's simplicity and workflows make it a fan favorite
  • Wufoo- Wufoo is great for simple contact forms that can then be integrated into other systems such as MailChimp, SalesForce, and more. They can also be sent directly to your cell phone.
  • SnapEngage- SnapEngage is a module that allows customers to ask for help and get live support.
  • Olark- Olark is similar to snapengage as it also allows you to receive pre-sales support requests from customer currently browsing your site.
  • Vanilla Forums- Vanilla forums is an open source piece of software that also has a hosted counterpart.
  •  ZenDesk- ZenDesk is a support desk and support ticket item
  • TenderApp is a knowledgebase and customer support application. 
  • GetSatisfaction- GetSatisfaction provides user powered support forums with employee interaction. 
  • UserVoice- UserVoice allows users to leave feedback on a site with bugs and new ideas. 
  • Assistly- Assistly is customer support made easier and more affordable. I love this product and would invest myself. The workflow and social media integration is very smart. What are other ways startups can use support to increase sales and decrease churn?  Leave your victories, horror stories, tips, hints, and tricks in the comments.


You should follow me on Twitter @jasonlbaptiste.

Continue Reading

Why PHP Is Fun and Easy But Python Is Marriage Material

By Dharmesh Shah on October 27, 2010

I think a lot about choices and decisions at startups.  That is the life of a software entrerpreneur:  It’s a stready stream of hard work, occasionally punctuated by some really hard decisions.  The decisions that are hardest are not the ones where you have the least amount of information — they are the ones that are hardest to undo or reverse. 

By this defintiion, picking the language/platform to use at a startup is one of the harder decisions.  It’s very hard to change this decision.  Here’s the story of how I made not one but two big language/platform decisions, neither of which really worked out — and which I’m now paying the price for.  The good news is that the company did very well despite these mistakes for two simple reasons:  First, I didn’t make awful choices — just sub-optimal ones.  Second, success in the early days of a startup is much more about getting market validation and traction than anything else.  And, as it turns out, customers really don’t care whether your SaaS application is built in PHP, C#, Ruby or Python.

On with my story…

When I kicked off my startup, HubSpot, over 4 years ago (June, 2006) I wrote a set of articles on the topic of choosing a language/platform — specifically for startups.  At the time, I was trying to pick between C# and Python for my then fledgling startup.  The article was aptly titled, “Python vs. C#: Business and Technology Tradeoffs”.  The article was very widely read, and still continues to drive traffic (likely because it ranks #1 in Google for “Python vs C#”).HubSpot Labs Logo

I made some pretty good arguments in that article, most of which I still stand behind to this day.  We ended up picking C# at the time.  The decision came down to one strong, dominant factor:  I was more productive in C# than I was in anything else, and that mattered — a lot.  Why?  Because it was basically just me.  In the early days of a startup, you’re looking to mitigate unnecessary risk and get to market as fast as humanly possible.  Within reason, my general advice is  “go with what you know”.  By “within reason”, I mean if what you know is a relatively mainstream language (Python, PHP, Ruby, Java, C# etc.).  There are definitely times to learn new things and experiment with new technologies — the early days of your product development is not the best time.  Either you need to know the language/platfrom from soup to nuts yourself — or you need to have immediate access to people you can rely on, that do.  So, I picked C# and .Net — which frankly, if I had to do over, I wouldn’t have picked (more on that later).  But, based on my circumstances at the time, I thought I chose rationally, and I was solving for the company, not my ego or enjoyment.  The good news is that the mistake wasn’t fatal.  [Side note: Patrick, if you’re reading this, I’ll admit, you were right. I should write a follow-up article on this on the topic of trust].

A couple of years later, I was faced with a different decision.  I was working in HubSpot Labs.  HubSpot Labs is a “startup within a startup”.  We don’t have a written charter for HubSpot Labs (because frankly, I’m not exactly sure how to write one of those, or if I did, who would read it).  But, the idea was to build cool free tools (see http://grader.com).  These tools pulled in website visitors, increased visibility of HubSpot, and helped us get some interesting data that we used to benefit our core business.  At the time all this was happening, I was trying to decide between PHP, Python and Ruby.  I knew I wanted a dynamic language, and I had whittled things down to those three choices.  I picked PHP, and Python was my second choice.  Though Ruby/Rails would likely have been fine too, there’s something about it that I just found unnatural.  If I had a dog, the dog would bark at the Ruby code.  Python just feels more “natural” to me.  But that's likely related to my C/C++ background.  But, I digress.  Back to why I chose PHP: Main reasons were: 1) It was easy to get started.  2) It had decent OOP support.  3) There were lots of other people using it.  4) It was lingua franca on the web.  The language served me well.  It was an easy transition from my C++/C# days, and combined with an MVC framework like CodeIgniter, things weren’t too bad.  I actually had fun developing in the language, and after the first few months, I felt that the code I was producing was about as good as some of the code I’m most proud of throughout my professional career. 

I have a love/like relationship with PHP.  Sometimes I have good days, and sometimes I have great days.

During my 2+ years of PHP development, I launched a bunch of web applications.  Cumulatively, they’re getting millions of page views a month now.  Not bad.  No major issues.

So, you might then be wondering, why switch away from PHP and move to Python now?  Don’t I have better things to do with my time?  Did I give in to peer pressure or somehow decide I wanted one more chance at being one of the “cool kids”.  I’ll attempt at answering some of those questions.

Why HubSpot Labs Is Switching From PHP to Python

Here are some of the tradeoffs (PHP wins on some fronts, Python in others), for those faced with the decision now.  Note:  The context here is a startup that is a bit further along (HubSpot was 2 years old and had about 50 employees at the time of this decision).  But, some of the arguments still apply, even if you’re earlier stage.

1. Python is well designed, PHP is not.  Although PHP is a completely workable language — it’s still not an elegant language.  In the short to mid-term, that’s not a particularly big problem.  Any experienced developer that can create great software can likely also write really good software in PHP.  (I’m talking about PHP 5+ here — and ignoring all the ugliness that came before).  But, there are limits.  I’m not particularly bothered by the weird idiosyncracies of PHP (the “needle vs. haystack” problem).  I can get over that pretty quickly.  It’s the other stuff — which is deeper and more nuanced.  As a “classically trained” developer (undergrad CompSci), I appreciate that Python gets a bunch of the language stuff “right”.  It’s about how reflection is implemented.  How functions are first-class objects.  It’s all the little things, which in aggregate, make for better cleaner, more elegant code.  Although it’s perfectly possible to write good code in PHP, it’s much easier to write great code in Python.  It is clear that Python was architected to be a robust, well-designed and well thought-out language.  PHP “just happened”.  Not to knock PHP (I actually love working in PHP) — but Python is just a better language.  [Note:  I still am viscerally troubled by the using whitespace to indicate code structure, instead of just using braces like the rest of the sane world, but it’s a relatively minor gripe].

2. Python has a “clear” web framework winner:  Although conceptually I like having choices (and I believe in openness), practically, I really, really like standards.  All things being equal, I much prefer that all of us are working with the same frameworks and libraries.  Python mostly has that with Django.  It’s close to the de-facto choice for web frameworks in Python.  Maybe not quite as dominant as Rails in Ruby-land — but close.  Contrast that to PHP where we have Symfony, Zend, CodeIgniter, Kohana — and others.  On the one hand, this kind of competition is good.  I’m sure they’re all great frameworks (I use CodeIgniter right now), but the fact that there’s no clear winner means that the market is fragmented.  And, fragmentation is bad.  It’s particularly bad when it comes to web frameworks.  The learning curve these days is not a new language (it takes a proficient programmer just a few days to get her arms around the basics of a new language).  The learning curve is with the framework.  The deeper and richer the framework is, the more there is to learn.  Don’t get me wrong, I love frameworks (dating back all the way to the Object Windows Library that Borland had for TurboPascal).  Frameworks have an upfront cost, but provide a ton of value long-term.  But, if there are a bunch of different frameworks floating around, the odds that any given person is working in the same framework you are lower.  And as such, getting someone new up to speed takes longer.  In Python land, the clear web framework winner is Django.  This means that if I find a great Python developer for the team (more on this later), they’ve likely used Django.  That makes life much easier. 

3. PHP is lingua franca in the world of the web.  One of the the early reasons I picked PHP, which is still true, is that it has become lingua franca on the web.  If someone releases a new API, and provides a “wrapper” for convenience, the first language supported will likely be PHP.  If you’re looking to build WordPress plugins, you’re going to be doing it in PHP.  In fact, many of the biggest open source projects out there, that you might consider leveraging, are based on PHP.  So, knowing PHP is a very, very useful thing.  My advice is that even if you do decide to go with Python — be at least “reasonably fluent” in PHP — it’ll come in handy.

4. Low-End Web Hosting is a non-issue.  Many people make the argument that PHP is a great choice of platform for startups because you can find a $9.99/month hosting provider that supports PHP.  No need for higher-end hosting and you save money.  I think that’s a poor reason.  Yes, it’s nice to know that there are thousands of hosting providers out there that all support PHP, and that you can get hosting really cheap as a result.  But, if you’re picking a language based on spending $10/month vs. $50/month or $100/month — you’re focused on the wrong thing.  Assuming that you stick with your low-cost provider for 18 months (a long time in startup-land), you’ll have maybe saved $900.  That’s just not a lot of money.  My advice:  Recognize that there are things like Amazon EC2 out there now, and over time, it’s going to be just as easy to spin up servers for Python as it is for PHP. 

5. Not all Python fans are fad-focused elitists .  One of the arguments I hear continually online goes something like this:  “PHP is a perfectly fine language, and folks pushing Python are just fad-focused elitists that want to work on the latest cool new thing, instead of just picking what works and focusing on building apps that solve customer problems.”  I’m paraphrasing a bit, but that’s the gist of it.  I can see why people sometimes feel this way.  Lets say you’re something like me:  You’ve learned PHP and used it to build and launch “real world” apps.  For you, the cost of change is high (maybe even prohibitively high).  Really hard to justify the change, because though you might grudgingly admit that Python is better, it’s not better enough to warrant switching.  You’ve got a startup to grow, you can’t be bothered with trying to join the cool kids.  But, I’m to advocate for some empathy here.  Lets say you were on the outside looking in (i.e. you’re a gifted developer looking to join a cool new startup).  Since you’re really good, and demand for great developers always exceeds supply, you essentially get to pick where you want to work.  All things being equal, you’re going to pick the place that is doing Python vs. PHP.  Of course, not all things are equal, and you might actually pick the startup whose business you think has the best chances of success or whose founders you like and respect.  But, often, it’s hard to know that stuff upfront, so you focus on what you do know — that developing in Python’s a better “bet”.  I wouldn’t fault people for solving for their self-interest and preference.  They’re not trying to talk you into switching, they’re just saying that it matters to them.

6. Low Learning are less important than high ceilings.  If you’re in the software development business as a career choice (i.e. you’re going to do it for a long time), then the larger consideration should be what’s going to create the most value for you long-term.  Some languages, like PHP, have very low learning curves — it’s super-easy to get started.  And, that’s awesome.  It’s easy-going, fun, and you feel super-productive (especially if you’re making a big change to something new).  But, once you get past that initial dating period, you need to think about your future.  You want to forge a relationship with a language that will be long-lasting, rich and deep.  A language that brings the best out in you — over the long-term.  Apologies for the strained metaphor here — but it had some resonance for me.  So, back to the title of this article:  PHP Is Fantastically Fun, But Python Is Marriage Material.  Apologies for the strained metaphor, but it resonated with me.  I’ve been programming for a long time, it’s my calling, and with any luck, I expect to do it for a couple of more decades. Since I'm going to get into a long-term relationship with a language, I figured Python's a pretty good bet.

Whew!  That ended up being longer than I expected.  If you made it this far, thanks for reading!  By the way, if you’re a gifted Python developer in the Boston area and looking to join what is quite possibly the best company to work for in Boston (we won an award, so it must be true), would love to connect.  The HubSpot developer interviews are a bit, um, rigorous, but I promise that you’ll meet some people that will have made the time spent worthwhile, even if things don’t work out.  If you’re interested, just drop me an email at {dshah} @ {OnStartups}{daht-com}.  By the way, in case you didn’t know, I’m the founder/CTO at HubSpot, and an all-around nice guy.  Just ask anybody. 

And, if there are any arguments you’d make on either side (PHP or Python), would love to hear them.  Don’t want to start yet another language war, but I’m fascinated by the topic of making hard decisions at startups, and this is one of the hardest. 

Topics: development
Continue Reading

Recommended For You


Let's Connect

And, you can find me on Google+, Twitter, and Linkedin.

Recent Posts

Chat with GrowthBot

It's a bot to help you with your marketing and grow. You can research your competitors, improve your SEO and a lot more. http:/GrowthBot.org