Help Scout
1 Comment

Help Scout Mascot: Final

We're so excited to show you guys the final Help Scout mascot today. After lots and lots of tweaks, he is finally finished. He doesn't have a name yet, though. Any suggestions?

Now that the mascot is finished, next we'll be choosing a font for the "Help Scout" part of the logo.

HelpScout mascot

To see what went in to creating the mascot, check out our other posts:

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.

Help Scout
1 Comment

Naming a web app: One word or two?

You may have noticed in our last couple of posts about Help Scout, the name has been two words instead of one (HelpScout). When building a web app, this is something that requires more thought than you may initially think. The domain, of course, has no spaces, leading many to leave out spaces when talking about your app. Is there a right way and wrong way or is it just a personal preference?

In our opinion it doesn't really matter either way. It's all about how you present the name in the logo. As long as it's clear, consistent and easy for people to understand/pronounce the first time, it's a keeper. We've technically gone both ways in the past. Feed My Inbox has always been three separate words for us. However, Linkpatch was always one. In both cases it came down to how we presented the logo.

If you decide to combine a couple of words for your app name and keep it as one word, the logo must visually define each word so that the logo reads more clearly and is understood more quickly. FreshBooks does it through capitalization and changing the color. Salesforce does it by changing the color and the type. Both are very effective:

Salesforce and FreshBooks Logos

The main reason we chose two words for Help Scout, each capitalized, is because we've already got plenty of visual stuff going on with the mascot. The type will be pretty simple and straightforward. So in order for people to immediately make the distinction with our service in reading the name for the first time, we think the space adds more clarity.

There isn't a one-size-fits-all answer to this question, but it's definitely something that must be considered during the logo creation process. The last thing you want to do is create any confusion.

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.

Help Scout
2 Comments

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:

HelpScout mascot

HelpScout mascot

HelpScout mascot

HelpScout mascot

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.

Help Scout
3 Comments

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.

Dashboard v2

Tickets View v2

Individual Ticket v2

Individual Ticket Reply v2

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.

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.

Help Scout
5 Comments

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.

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.

Help Scout
2 Comments

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

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.

Help Scout
Make a Comment

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.

Tickets View v1

Individual Ticket View v1

Login Dashboard v2

Tickets View v2

Tickets View v2.5

Individual Ticket View v2

Ticket Reply v2

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!

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.

Help Scout
1 Comment

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

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.

Help Scout
2 Comments

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