We're building an app for email customer service. It's an email client for teams that provide support or service to customers through a single email address.
As of today we now have over 120,000 people using Feed My Inbox. With that comes a fair amount of customer service inquiries, maybe 15-20 legit emails per day. Since each of us does a bit of customer service, it often gets confusing. Sometimes the same customer gets a response from two of us. Sometimes an email goes unanswered for far too long because it wasn't delegated properly or was marked as read by mistake. When we do respond, there is no way to take ownership of the conversation and see it through to make sure the issue is handled.
What we need is email ticketing. Surely there's a web app for that, right? The answer is yes, but they all go by this weird name of "Help Desk". Not only do web apps in this space have ticketing, but they are bundled with forums, "public tickets", knowledge bases, wikis, faqs and customer-facing portals. We don't want that stuff; we just want a way to communicate via email with our customers.
Email: a lot of people have the same problem as we do, but they find a way to deal with it using traditional email. They might share a Gmail account or find another way to make it work by rotating shifts or whatever. Our service will have to provide significant value over email in order to succeed.
Help Desks: Zendesk, Tender and Kayako are the three biggest help desk competitors in my opinion. They are each successful in their own right, but none of them fit our needs. I tried to learn about and configure ZenDesk on two separate occasions, spending about six hours each time, then giving up in a fit. It would take weeks to get it where we want it. Tender is really nice, but is clearly focused on customer-facing stuff we'd prefer not to use. Kayako is self-hosted and looks like Windows XP. I just can't do it.
How to Win
Narrow the Feature Set
We're going to focus on one thing and (hopefully) execute it really well, which is email for teams. By focusing on one specific niche of customer service, we can do it better than everyone else. We can also keep the service more generic, which means maximizing our potential customer base.
There are lots of great community-oriented tools out there, so we're not going to focus on that at all. We use and love services like Get Satisfaction, so we don't intend to compete there. We'd much rather integrate with these services through an API than build them from scratch.
Flatten the Learning Curve
Help desks are hard to figure out and very time-consuming to configure properly. It's too much. We think a lot more customers would stick around if they could be up and running in five minutes or less. This means no customer-facing tools, nothing to install and nothing to setup other than an email forwarder.
We also think we can flatten the learning curve by allowing people to use the app just how they would email. So in the long term, giving customers the ability to communicate with the application through email, without having to login every time can really save time.
So that's the B Combinator app. We know it's not sexy, but we're scratching our own itch and we think lots of other people have the same one. Now if we could only find a name for it ...
This post is part of our B Combinator series. We're building a new web app with our own time and money, blogging about every detail from concept to launch along the way. Read our first post in the series to learn more about the project, or visit the B Combinator category page to see all of the articles up to this point.