The Dumbest Implementation of a Feature – Bcc

Posted on Oct 26, 2010 | 56 comments

I’m working on a larger series on “scaling sales” that will drop this weekend or early next week so I thought I’d go for a more light-hearted topic today.  I’ve always thought about writing a few posts on features in products that drive me nuts.

I have a short list of what I consider the worst UX offenders and Bcc has got to top the list.

Let me be clear up front – I like Bcc.  I just don’t like the way it’s implemented and I think it leads to a lot of “email fails.”

We all use email in our daily lives.  For the most part you send emails to one or many people and you include them all in the “to” field.  Occasionally it seems more appropriate to have a few people in the “to” field and a few other in the “cc” field.  I tend to do this when I want to call out that the message is really intended for the primary recipients (to’s) but I would like to inform other people – maybe executive assistants or other staff who won’t be at a meeting, for example – and I’ll sometimes but them in the “cc” line in stead of “to” line.

cc stands for carbon copy and for those of us old enough to remember the pre-computer world, cc’s were common on memo’s back then and you had to know what all of these short-hand secretarial notations were, such as “encl” (enclosure).  I guess these were the short codes we all used before the text message / IM short-hand codes such as OMG, LOL or WTF? took over.

While “to” and “cc” are mostly treated the same (although newer productivity / filtering tools are starting to see them differently), the feature that really chaps my hide is “Bcc” – the “blind” carbon copy.

Let me explain:

Bcc’s function, as I’m sure you know, is to be able to write to people without other people emailed knowing that the blind copied people are on the distribution list.  Is this evil?  Naw, of course not.  Here’s where I use it:

1. Emailing a list for an event - When I email a large group I almost always use bcc.  The reason is that when you email a large group invariably somebody feels the need to hit “reply all,” which is a feature that should be rate limited, as in you can only use it once / week.  On group lists you often get 7-10 “reply all” responses and all of us sane humans get annoyed.  Or the quasi-sane people write a message to all saying, “please stop replying to all,” which, of course, is both ironic and annoying.  BCC avoids this all.

2. Emailing a list where disclosing other email addresses is not appropriate – There are also times where I’m running a group meeting and it may not be appropriate to share everybody’s email address with the entire group.  When you openly email people you’re giving a piece of private information out that you really don’t have the permission to do so.  For most of us this doesn’t matter.  I freely give out both my email address and my cell phone (which is on my business card) on the basis that most people know when it is appropriate to use these.  But not everybody has that same level of comfort with public information so I try to respect that.

3. Letting somebody know that I’ve completed a favor – I’m often asked for introductions or I’m helping one of GRP’s portfolio companies get intro’s to other investors or whatever.  I often don’t like to oblige the recipient to take the introduction but I do want the company asking the favor to know that I’ve actually completed the request.  Often times I will just send a separate email to the requestor telling them that said favor has been completed.  But if I have 10-12 emails to send out sometimes I will shorthand by just bcc’ing that person.  I will tell them ahead of time, “please don’t respond to the bcc request and please don’t contact the person directly.”

4. Bcc to keep someone out of scheduling followup emails – The case I’ve already written about where you drop the person who did an intro by “moving them to bcc” so they don’t see all back-and-forth emails.  I LOVE bcc for this.

So here’s the rub.

Sometimes people who are blind copied respond to the email.  In the first two cases it’s fine because nobody else is “copied” so it doesn’t matter.  But when people are actually copied and you are the “blind copy” then responding looks really bad.  It is what I call “bad blind copy etiquette.”

So if I wrote to a VC, for example, saying “have you ever met person X? I know he’d like to meet and he has these great skills” and then person X (who is blind copied) “responds to all” and says, “yeah, I’d really love to meet” then I look stupid.  I look really stupid.  The VC (or whoever I sent the intro to) will instantly realize that person X was blind copied because they won’t have noticed them on the original email list.

I only bcc people for harmless reasons and mostly to save me from a second email.  But why on earth would Microsoft and other email providers have allowed a person who is Bcc’d to respond to the email?  It would be such an easy piece of functionality in Outlook to simply disallow a reply in the case of the Bcc.  The person who responds often isn’t aware that they were bcc’d (either not paying close attention or on a mobile device) and would greatly appreciate an error message saying “you can’t respond to this message because you were bcc’d.”

So I’ve resorted to mostly bcc’ing myself and then forwarding emails to people in instances where the bcc may have been a better use of time for all involved.  It’s a royal pain in my arse. And I’m baffled why a product manager for Outlook or other email services haven’t realized this weakness.  I can’t think of a single “use case” where responded to an email where you are bcc’d would make sense.  If anyone knows one, please do tell …

[UPDATE - I totally forgot that I had once seen a company that tried to solve this problem.  It's called Subtextual (but used to be called BCCThis).  I think I'll check out their plug-in]

  • JDelage

    Arguably, there should be a flavor of the bcc where the person on the bcc: field doesn't even see the email addresses of the recipients on the To: field.

  • Ethan Stone

    Outlook, at least, doesn't tell you that you were “bcc” d. You just get the e-mail. I realized this after one catastrophic event in which I was “bcc” d, had no idea I had been “bcc” d and therefore responded in a way that pissed of the person who had “bcc” d me. Since that unfortunate event, I never use “bcc.” If I want to let someone know that I've sent an e-mail but don't want to copy them on the distribution, I send it first to the distribution list and then forward the sent e-mail with an “FYI.”

  • Gretchen

    I am with you on this. Which is why I think I resort to forwarding for use cases 3 and 4. Definitely not ideal, but certainly avoids the embarrassment of having them reply to everyone else. A quick test in Google mail shows that they implemented this feature in the same dumb way as MS.

  • Skeeter Peeter

    Just tested my Mac client. It doesn't do that. If you are BCC'd in the first place, Reply All goes only to the originator.

  • Mike Schinkel

    I love this post, in part because of how user-centric it is (vs. startup issue or VC issues!) Funny though, I thought you were going to give the history of CC yet you only mentioned interim use, not it's origins.

    CC came from copies made using carbon paper which was how my teachers made copies of their notes when I was in elementary school! They, of course, could only make the copies when they originally wrote their notes so, like an email I guess, you only CC from the original email; afterwards it is a forward.

    Here are a few links:

    Hoping you find this interesting (while at the same time it's makes me feel old! :)


  • Alex

    It would seem to me that this would be an easy plug in. When sending the email to the person on the bcc line, just take out the email from the @domain.tld so the person getting the bcc only sees the username of the other email addresses. That way, the user can still reply to the original sender, with a “thank you” in the case of an intro but can't make either you or the person being introduced look foolish.