Help Scout Mascot: Round 2

After sketching out some good ideas on paper in round one, we finally took to Illustrator and Photoshop to create the Help Scout mascot. We've spent several hours working on him so far and I'm really excited about our progress. The face still needs more time, as do some minor shadows and such, but it's pretty close. Take a look at how he evolved:

Wireframes: Version 2

After spending some time away from the first version of wireframes for Help Scout, I came back and couldn't believe how complex I had made our little app. What's with the bar graph on the dashboard and the messy ticket screens?

Round two was all about simplifying, stripping away anything that wasn't a "must-have". I started with a blank slate, thinking through every bit functionality in these pages again. Here's a summary of the major changes that took place from round 1 to round 2:

1- Took the "customers" section out completely. We can build that out later if we ever need it. For now, customer information will only show up when you are viewing a ticket from them. We also took "Mailboxes" out of the navigation and link to mailboxes in the left sidebar.

2- We switched out "Settings" and "Help" from the two navigation areas in the header, thinking settings is much more important. Settings is where you edit mailbox information and configure a bunch of other options, so it belongs on the main navigation.

3- The tickets layout is far too complicated. We simplified it a great deal by moving all the ticket actions off of this screen. If you need to assign a ticket or change the status, just click on the ticket. Provided the screens load very quickly, it's a worthwhile trade-off considering all the free space we gain.

4- We ditched the idea to stack the tickets view and an individual ticket, a la Apple Mail (screenshot). It may work well for a desktop client, but I hate the scrollbars and there's still too much going on.

5- The "header" of each ticket was also a mess in the first round. It's been re-worked, with functionality being placed more intuitively throughout the page rather than bunched up on the top.

We're much closer after this round, but still need another go to finalize anything. The next set of wireframes is the final round before we open Photoshop and start having some fun.

HelpScout Mascot: Sketches Round 1

In the last post I mentioned that the new name HelpScout was ripe with branding possibilities. We think it needs a mascot, so we've spent a lot of time working on it while we finalize more serious stuff like the wireframes. Here is the first round of (very) rough sketches ...

We Picked a Name!

This isn't a Lebron James press conference, so we're not going to waste any time keeping the world waiting (and we know the world is waiting for this ... ha); we'll just tell you what we chose as the name. The new name for our customer service app is HelpScout.

Why we chose HelpScout

The Branding Possibilities are Awesome

We were immediately excited about branding this name. It's the perfect name for us to create a mascot of some sort. For all that MailChimp (logo here) has done for monkeys, we could have the same sort of impact from a branding perspective with HelpScout. We think this is a HUGE plus.

We Like the Connotation

While none of us have ever been boy scouts, we like what they stand for: teamwork, honor, helping others and hard work. There's enough here for us to market the app to customers without having to explain the name every time.

It Works for SEO Reasons

In the last post we mentioned that it would be a nice boost if "help" were in the name. Considering what a competitive field "help desks" are (even though we're the anti-help desk), we instantly helped ourselves by getting a domain with one of the main keywords.

It's Short, Easy to Spell and Easy to Remember

Enough said! It passes these three tests with flying colors.

So far we have two domains, HelpScout.net and HelpScoutApp.com. HelpScout.com is a squatter of some sort. We're hopeful that maybe we can grab the domain at some point, but it's not a big deal either way. We don't have any actual competition with the HelpScout name, so we're moving forward.

Don't Forget to Make Sure You Can Use the Name

Before you register or publicize a name for anything, make sure you can legally use it. All you have to do is a Trademark search on USPTO.gov (in the USA) for the name. Go through any existing trademarks with the same name and triple-check that they are not in the same or a related business. Consult your lawyer for specifics, but if there are any web services with the same name as you, it's better off not to use it.

You don't have to register the trademark officially right off the bat, but you do need to make sure it is available and be the first one to use it publicly. We'll be registering the HelpScout trademark upon launching the site, but since we're actively talking about it on this blog we will have legal rights to it, even prior to registering it.

37signals made this mistake rather recently, with an application they released called Haystack. Due to trademark issues, they had to change the name to Sortfolio and update all the branding. It's worth doing a little homework upfront in order to avoid these kinds of problems.

Naming our Web App

Opinions vary regarding the importance of a name. Since it's something we're going to live with for the long-term future, I think it's very important. Sometimes they come easy, but usually they don't, so be patient and don't decide on anything unless you live with it for a couple of days or more.

I think naming a web app should require a whole different set of rules compared to naming something that exists predominantly offline. Here are the things we consider when creating a name, in order of priority:

1. Make it short and sweet. One or two syllables is ideal.
2. Consider how easy it is to spell. We made this mistake with naming Brightwurks and I would take it back if I could. Don't name an app based on a misspelling. Also, try to cover your bases with any common misspellings of the name you come up with.'
3. Is it SEO friendly? This varies in importance, but for us it's very important. The "help desk" market is very competitive, so ideally it would be great if the name included "help" or "desk" somehow.
4. Get the Dot Com. In my opinion this is becoming less of an issue on the web. As long as someone types in the name of your app in a search engine and you are #1, I'm not against a dot net or variation of the dot com. Don't ditch the perfect name just because of a stupid squatter on the dot com. Chances are you will have an opportunity to get it at some point.
5. Does the name adequately describe the service? I think this could go either way. There are great examples of both, but it's a nice bonus if your name does describe the app in some way.

I've heard people say you should spend anywhere from 20-40 hours naming your app. I disagree. You'll know the right name when you find it. It may be in hour 2 or hour 38. Just exhaust every possibility until you find the one, no matter how long it takes.

Another big thing when creating a name is to know when to start and when to stop. Only work on it when you feel inspired, and stop when you hit a wall. Banging your head against the wall for hours typically doesn't produce results; it's a waste of time. I find that all my best work is done in the first half hour, then I have to move on and come back another time if nothing materializes.

What You Need

• Pen and paper ... don't let one thought or idea go through your head without it being written down. Keep it all.
• Dictionary and Thesaurus
• Domai.nr for quick domain research
• Co-founders- our most productive "namestorming" takes place collectively rather than individually, although we still do both.

Initial Ideas

For this app, the big idea we want to convey is teamwork. This is the best application for people to collaborate on email and work together to communicate with others. If we can find a way to say that in two syllables it would be awesome.

Right off the bat I thought we had a winner in the name "Huddle". In my opinion it was a great visual for what the app does and I was willing to go without the dot com name. However, many of you may already know about Huddle.net, a project management app based in the UK. They have a good thing going and we weren't about to create any confusion or legal battles there.

Several more brainstorming sessions went by, both individually and with our team, without anything really popping. Here's a list of some of the words we had on the board so far:

• Herd
• Flock (taken by the browser)
• Tribe
• Chief
• Army
• Colony
• Swarm
• Tribe
• Pack
• Hive
• Team
• Peep
• Clutch
• Cartload
• Rake
• Band
• Sedge
• Leash
• Kennel
• Pod
• Gang
• Mob
• Cast
• Knot
• Gaggle
• Charm
• Glint
• Group
• Array
• Nest
• Stable
• Troop
• Scout
• Clan
• Lounge
• Zeal
• Unit
• Force
• Clique
• Social
• Convoy
• Fleet
• Crowd
• Mass
• Crew
• Jumble
• Bunch
• Bundle
• Medley
• Cluster
• Marvel
• Enhance
• Shepherd
• General
• Chorus
• Tandem
• Choir
• Harmony
• Harmos
• Sync
• Collaborate/Collab
• Hub
• Pilot / Co-pilot

So we had a big list of words, ideas and terms, but nothing really solid for a name. A couple more weeks went by before we finally came up with the name in a group chat at the office. Stay tuned to the next post for what we chose and why.

More References on Naming an App or Company

• Carsonified: How to Name Your Company
• Guy Kawasaki: The Name Game
• The Name Inspector: 10 tips for naming your company, product or service

What else would you like to see in your inbox?

We'd like your feedback! What other kinds of content other than feeds would you like to receive in your inbox? We have some ideas but would love to hear yours as well. If you have anything to add to our list, please respond on our Get Satisfaction Thread. Thanks!

Wireframes: Version 1

Wireframing is probably my favorite thing to do when I have an idea. There is no faster way to get a bunch of ideas on paper and test them out. All you need is a Sharpie, or these days even an iPad.

The customer service app idea has been simmering off and on for over a year, so I've done tons of wireframes. For us, it's the first step in the process with almost any project or idea. Even before we decide to build anything for sure, we build the basics on paper. If the wireframes lead us to believe we can do something that hasn't been done before, that we can have fun building it and that we could make money, then typically it's a go. I doubt wireframes are enough for most people to call it a "proof of concept", but it's enough for us.

For this project it took 3 really solid iterations of wireframes before I felt like we were ready to open Photoshop. Today I'm going to share version 1.

Wireframing Advice

Do your first version of wireframes, maybe get some feedback, then forget about them. Next time you feel inspired, start with a clean slate and do the wireframes again. What changed? What can you afford to remove? What can be put off until later?

Rinse and repeat, each time trying to strip down the features and layout even further, leaving only the absolute essentials. Two important elements to consider are time and feedback. Let time pass between each iteration so you come back with a fresh perspective and maybe a different take on things. Feedback is also important for obvious reasons. Put your wireframes in front of some people and walk them through the basics. Ask them what could be improved. What seems confusing?

As you can see below, we always start on paper with a Sharpie. The images below are two of many variations I was playing with. From there I move into OmniGraffle. It's easier to get more detailed and move things around there.

A lot of ideas came to fruition with these wireframes, but it's still far too busy and heavy. With version 2 we're going to start with a clean slate and see how it turns out!

B Combinator: What We're Building

Elevator Pitch

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.

The Inspiration

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.

The Competition

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 ...

Announcing B Combinator!

Today we're announcing a new type of ongoing content for the Brightwurks blog ... something we're calling B Combinator.

So what is it? B Combinator is our attempt to build a bootstrapped web app ... publicly. As if it's not hard enough to self-fund a web app, we're also going to blog about the entire process. We're going to share every step of the way, giving people a behind-the-scenes look at what it takes to build and launch version one.

What's with the name?

Of course the name "B Combinator" is a play on the Y Combinator name. Early in 2010 we applied to YC with this idea and were not accepted. I want to be clear that we aren't bitter. It was just an idea without a proof of concept at the time, so it makes sense that we weren't picked. However, we aren't the kind of people to sit idly by and wait for things to fall in our lap. We're finding a way to build it anyways.

Will it be harder? Yes. Will it take longer? Yes. Could we end up looking stupid? Yes. Despite all the challenges could it still be a game-changer? Absolutely!

As for the "B", it could stand for a number of things: Brightwurks, bootstrapped, "plan B" (as Y Combinator was plan A), badass (we hope) ... frankly it doesn't matter. Since the app doesn't have a name yet, B Combinator will have to do until there is something more official.

What are you building?

That's the next post, so stay tuned! We're just out to solve a practical problem we think a lot of businesses (including ours) have. It's not ground-breaking, just something we feel everyone in this market has done wrong.

We built the first version of Feed My Inbox in roughly 24 hours. This app needs more thought and work before we can launch, so we're taking a different approach.

I also want to give a hat tip to Carsonified and the Bare Naked App project they did 4+ years ago. I really enjoyed reading it and B Combinator is very much inspired by what that project was about.

The Objectives

1. Prove that an idea is worthless; execution is everything. Enough said.
2. Inspire readers and people in our business by sharing the entire process publicly
3. Build a larger audience by sharing our process with others
4. Generate feedback, ideas and discussion from readers about how to make the app better; we hope you will participate by reading and commenting.
5. Writing about the process holds us accountable to making consistent progress and launching version 1
6. Build an app that helps companies do business more efficiently and helps us do this full-time. Currently we split time between working on our projects at Brightwurks and doing client work at Project83.

Upcoming Posts

• What we're building
• Selecting a Name
• Wireframes v1

New Twitter Support Launched!

It took longer than we were hoping, but Feed My Inbox deployed all-new Twitter support today. It's now a lot faster, more informative and damn good looking. Here is what the new Twitter emails look like:

The new email supports retweets, shows profile information on the top and also hyperlinks @ replies. Not only that, but we are no longer using the RSS feed to check for updates. This is a custom integration where we get results instantly from Twitter, just like any other Twitter application you may use on your desktop or phone. So in most cases we can get real-time Twitter email notifications to your inbox in a minute or less from the time it was posted.

What it's Great For

• Keeping up with people/companies without having a Twitter account (great for non-techies!)
• Get twitter notifications anywhere you get email: at home, at work or on the go, with only one app!
• "Following" accounts without them knowing you are following them

What's Next

Now that we've got this going, the next step is to apply the same integration to Twitter searches. For now, Twitter search subscriptions will still use the current Feed My Inbox templates and RSS feed integration method. Stay tuned to the blog for when we add this in.