Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Why your company should have a single email address (asmartbear.com)
127 points by revorad on July 4, 2011 | hide | past | favorite | 40 comments


The problems the post describes are not really about email. They're actually about the difficulty of setting up a proper CRM system.

All incoming and outgoing email should be stored in a way that anyone can easily see the conversation history (and people should be checking it before they respond). As I see it, that's the problem the post is actually describing. Having one email address is a method of trying to achieve this but IMHO it's not how it should be done.

The problem with CRM systems as I see them is that most of them require users to click away from the email to read the full conversation history. Even worse than that, employees usually have to manually add a conversation to the CRM to begin with.

A better solution might be to automatically save incoming email to the company CRM and also append outgoing messages to the appropriate contact. That way, no-one has to remember to add records. The next step would be to expose that information directly in the email client so employees don't have to go hunting for info (if they can even be bothered).

I don't think most customers actually care where their reply comes from (e.g info@, sales@, bob@...) as long as they get a response and their issue is resolved.

Edit: I agree with the post that customers should not have to figure out which address to use from the website. Just give them one


Having a single e-mail address as a contact point is a great start, but you need more to solve the problem of fragmented communication, since customers inevitably end up having conversations directly with individuals in the company (and often prefer to, since they then know they're dealing with a real person).

> A better solution might be to automatically save incoming email to the company CRM and also append outgoing messages to the appropriate contact. That way, no-one has to remember to add records. The next step would be to expose that information directly in the email client so employees don't have to go hunting for info (if they can even be bothered).

We've been working on http://noosbox.com/ to solve exactly this problem. It integrates directly into GMail (on Google Apps) or outlook to allow you to save conversations against a specific contact.


Isn't that what Zendesk and the CRM mentioned in the article do? I haven't tried them, but that's the impression I get, because it looks like people send emails from within Zendesk when replying to my support enquiries in various companies.


I haven't tried them either but from my first impressions there's still a wall between the conversations people are having via the support system and those that people remember to add to the CRM. e.g. the sales guy trying to up-sell someone to v2.0 may have no idea that the customer already has two open support tickets from the 2.0 beta program.

The problem here is that these are fragmented systems, each trying to solve specific needs for the company (tracking sales/prospects, tracking support queries) rather than looking at the customer's perspective.


My previous company 24SevenOffice (http://24sevenoffice.com) automatically links email sent and received to/from a contact in the CRM.


How? Does it require Outlook?


No. It has an email module as well. Which can use any IMAP or POP3 server. It is a complete web-based business suite (I don't like to call it ERP as it is not meant for enterprises), but it has CRM, accounting, invoicing, project management, email, file/document management ++


This is a really good point. I feel a lot of the time, I end up having to think which email I should email someone at. When a contact page has 8 emails on it with contact@, info@, support@, sales@, etc, it gets really confusing. I usually just end up emailing sales@, since I remember when I was working at Admiral, new customers got better treatment and response times than existing customers.


Agreed. It's why we only have one friendly public-facing email address at our company - hi@


That's a really inviting email, I love it! Feels much more welcoming than info@ etc.


I don't buy it. If a pre-sales technical enquiry comes into multiple addresses, including 'support@...', 'sales@...' etc. and the sales & support teams do not talk to each other or share business intelligence, then there has been a failure of internal process, or a lack of proper systems, rather than it being the case that the email address design and structure is broken.

It's not hard for a Sales team to circulate a regularly- updated list of current prospects and their pipeline stage, or to have this as an Intranet page etc.


It's also not hard to have a single public-facing email address. In fact, that sounds a lot easier for the Sales team than remembering to circulate and regularly update that list.

I agree that the issue is one of internal process and lack of proper systems, and I don't see why you exclude email address design and structure from those categories.


Well, we have an Intranet page that's updated dynamically from our CRM system - no need for anyone to remember to update or circulate anything.


I agree that it is a breakdown of internal processes. However, I think a single email might tend to facilitate the development more robust internal processes by simplifying the input stream and unifying triage of communications.

Of course one email could become a bottleneck if triage falls behind, but mapping information flow does become easier.


I dealt with this recently. Emailed info@company.com and got a response from sales@company.com. Some time later, I emailed the same company at sales@company.com and got a response from sale2@company.com.

WTF?


I'm not entirely convinced by the arguments here. I think I'm more inclined to think this is a good idea because it does remind me of companies that partition their websites into shards for "personal", "small business", and "large business", because their sales force is divided into these categories. This is absolutely infuriating to navigate. I know what I want to buy: let me look at what you have to offer and let me buy it without having to care about how you structure your sales force.


I think this is a real YMMV subject - using a single email address can be a little dangerous if your startup has a chance of "going big" (and don't they all??). Even 50 extra messages a day can be overwhelming and you may find yourself skipping over important messages as you struggle to move them off your plate quickly. Even worse if it all lands in your primary inbox folder, distracting you from focused work (this is especially important if you're "two guys/gals in a garage" where productivity & focus really, really matters).

I actually set up multiple email addresses for support in this way on purpose, based on platform. I find I'm far more efficient if platform 1 goes into folder 1 and platform 2 goes into folder 2. No need to make giant cognitive leaps in jumping from one message to another, and you can sit down and respond to everything all at once, not interrupting your flow...you're more productive, less overwhelmed, and contacts get their answers faster (and their emails don't get buried in your overwhelmed primary inbox).

If you are a consumer Internet startup and have a single downtime, you will completely understand where I'm coming from here...


I don't know, if that's too big of a load just use a CRM with email integration and have people pick new emails according to their position, or have an assistant/secretary route the emails to the appropriate address.

That sounds much more reasonable, not to mention that you won't use your email address as the single contact, rather you will set up a different one that will act as a dispatch.


I actually find Groups within Google Apps mail to be pretty easy to set up and effective for our needs--setting up private groups is a really cheap & easy way to sort mail for free. I have groups like:

- productA-support (which is really just "support@")

- productb-support

- info/hosting/privacy/twitter/etc (not all aliases are publicized, but tend to match what people would make up when attempting to send email to us)

The support aliases forward to me and to a dedicated support account. I always use the "Send As" feature so that nothing has my name on it unless you're nosy & look at the headers.

The info and other aliases go to both myself and to my partner. We both want to catch biz dev inquiries and any special snowflake requests, but I handle all support to ensure morale stays high.

If we add staff, we can add them to the groups pretty easily. Though at some point thereafter, we'd likely need some solution for determining what's been handled. It's a little hokey, maybe, but cost-to-benefit works well right now.


Ah, good idea, I forgot about that function. However, I would be a bit worried about who handled what, since (as you already mentioned) there's no good way to say "I've got this one".


Concerning the questions / concerns raised here and within the comments of the original post, I posted a quick follow-up at http://vermorel.com/journal/2011/7/4/why-your-company-should...


A long time ago when I was setting up my first business website, I listed email aliases for a bunch of fake departments: sales@, support@, press@, jobs@, etc. At the time I saw this as what bigger businesses did, so to legitimize my new business, I followed along.

A decade later, I'm now just using hello@ for everything even though my business has grown a lot since then.

It's much easier to funnel all incoming emails through a single point of contact than juggle a bunch of aliases.

Our replies come from the same hello@ address even though the actual person replying varies. Each email has a code to group threads together.

Only when email goes personal does it get pushed to a specific person's mail account. The vast majority of our emails are centralized. It's great.


9:30 Club in Washington DC uses "human@930.com" as their single address. I haven't seen that anywhere else. What a great idea.


The OP also recommends against using "hellish" webforms, and I wholeheartedly agree... one "oops" with my browser and the message I was writing is gone.

But I see them all over the place, and they take some work to implement whereas posting your e-mail address doesn't. Is there some argument to be made in favor of these which escapes me?


Good question. Perhaps web forms are thought of as a kind of CAPTCHA, the idea being that any ol' bot can send e-mail, but it takes a human -- or a bot specifically written for the site by a human -- to fill out a form.

Note: I'm not endorsing this thought; I'm just trying to get inside the heads of the people who make these awful things.

EDIT: Another possibility is that they want a way to easily tell how to route a communication from a customer. And web forms can contain those menus that tell the reason for the communication. (Tragically, those menus rarely work for me; my reason is not usually not on the list.)


If a web dev is going to start rolling their own CRM (maybe without realizing that's what they're doing), there's less perceived friction if they just start bashing out one more web form (with fields that make the user do some of the routing and prioritization work) than if they must first do enough homework to wire something into the org's email server, where prototype-grade code could really screw you over. I think this is a problem Zed Shaw set out to solve with a new framework, though he didn't display the "100.0% of messages must be delivered" attitude that would make me comfortable tinkering with it.


If I ever have a company, I will have one email address -

thebuckstopshere@mycompany.com

I will then use a service like Amazon Mechanical Turk like to distribute the emails to proper internal addresses.


Using MT to sort email sounds like a terrible idea. You don't know what kind of sensitive data users send along with their support e-mails, you don't want to risk one of the mechanical turkers exploiting that.


Just use bayesian filtering, grouping email into topics rather than ham/spam.


This has nothing to do with how many public email addresses are exposed and honestly... solving it in this way shows a lack of understanding of the problem. The problem is maintaining effective communication across sectors of your business. A conversation between an external user and your company should be transparent... but not from an email address standpoint. As long as you can log into your CRM software and see the history of my conversation... who cares what email address it came in on.

Having one email address just changes the problem. Now instead of having no context for the conversation you have a jumbled email chain that you're having to centrally monitor, distribute, pass around to other people... if anything it seems vastly inferior than having a new email to billing@company.com causing that customers email history and a notification from being sent to the billing support supervisor.


I think this post makes complete sense, and not sure why there is a fuss about the ellipses of all things.

However, I do think that the one email address is a better solution IF there is routing logic on the company end that gets the right emails to the right people and allows individual employees to have individual email conversations with customers from their single work account. I'm not imagining a shared company Gmail account -- I'm imagining a conversation between Victoria and Victor all intermediated through contact@example.com.


Seriously, learn how to punctuate. Ellipsis are not used this way and your placement of them makes no sense whatsoever.


I definitely find value in proper grammar and am much more likely to read a comment that's well written; however, in this case, I don't see the problem. The ellipsis feels to me like a translation of a conversational pause or transition to a written medium. After all, HN is much more like a conversation than an essay.

The parent's comment seemed well written overall and I wasn't personally put off by their use of ellipses.


You're right, but please be a little nicer about it.


Have you not seen how much improper grammar and spelling is on this site? Who cares? Don't be such a jerk.


We use correct grammar, spelling and punctuation here for the same reason we refrain from making silly jokes and calling each other names. It's part of the culture that we're trying to maintain, and it has value.

The grandparent could have simply downvoted the distractingly punctuated comment (as a few people have downvoted your namecalling), but he chose to help the user out instead by pointing out what he'd done wrong.


I'm using them as I would conversationally. Commas might be more appropriate but saying their placement doesn't make sense is silly. They're obvious pauses if I were saying g this aloud.


Yes... But... That's what a comma is for... You see... It can become quite ridiculous if you use them in place of commas... If you use them like that... How can you say an ellipsis is any different than a period at the end of a sentence...?


Funny, cute and just as irrelevant as the other comment. Not to mention that the places you placed ellipsis are not all appropriate places for commas. I would understand if it even slightly impacted the readability or understandability of my post. This is the trite shit I hope to avoid here, if I wanted grammar-nazi and punny sarcastic threads about it, well, you know where I'd go.

Jesus guys, I was on the mobile site and ellipses are faster when I'm already feeling limited by my thumb's tapping ability to have to go hunt for the comma. I didn't realize it was such an issue that it spawned 6 comments about my style and zero comments about the content of my post or the article.

I mean, do I explicitly need to write: "I'm so sorry, I know I should have used commas but I didn't and it wasn't easy for me to proof-read on my device"? Good lord, even the original post is being crucified without response.


Don't listen to them. They don't have girlfriends.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: