Open e-mail (everyone can see everyone else's received and sent messages)

Question

Problem

As a team, we need to set up our e-mail so that everyone can see everyone else's received and sent messages.

More info

The situation is that there are 4 people who are communicating with customers. In the spirit of Scrum, each person needs to have access to all communication to and from the customer so that when they communicate with the customer next, they have access to all the necessary information.

I have an idea of how to go about implementing this, but I'm not confident that it doesn't have a fatal flaw or two in the details somewhere and that there might be better ways to do this.

My idea is this:

• Everyone to uses an E-mail application such as Microsoft Outlook.
• Each person has their own e-mail address, but registers every other e-mail account with the e-mail application so that when the sync, all e-mails to all four people are synced to the client application
• In order to differentiate e-mails sent directly to them as opposed to e-mails sent to someone else, rules are set up to color-code which are meant for them and which are meant for someone else. The messages could be separated into folders, but I would like for everyone to at least glance at everyone else's messages.
• Instead of syncing the "sent" messages folders, rules would be set up on each application so that every message they sent was BCC'd to the rest of the team. That way sent messages would pop up in their inbox and they can glance at them as well.

Concerns:

• I know Outlook has these "rule" features, but I'm not sure how about Mac OS e-mail applications and Open Office.
• Is this implementation going to cause too much chaos and confusion in everyone's inbox?

Clarification:

Based on content in the comments and answers, the following information should be helpful:

• The goal is not to restrict private communication
• The goal is to enable open communication
• Each employee at this company works from home, on their home computers. Employees control their computers and working environment. Employees are not restricted from using any applications such as private e-mail.
• This company does not sell software
• Customers are people who are purchasing a service in the $200 range.
• Many customers are one-time customers. Customers who are not one time would make purchases 1-2 times a year.
• Typical sale usually involves one 5-15 minute phone call
• The most a sale takes would be a few e-mail exchanges and a few phone calls
• Customer service people need to have access to details such as:
  • What discount did the customer get last time
  • Where did they hear about us
  • What concerns the customer wants the service to address
• Internal e-mails do not need to be shared
• Each person in marketing/customer service probably needs to have access to the entire communication thread with each customer
  • Customer service people need to have access to this information so that they can be knowledgeable about the customer's history with the company if and when they call to schedule another service
  • Marketing people need to have access to this information so that they can send customized materials to previous customers
  • Marketing people study previous exchanges with customers in order to help optimize lead conversion rates
• Each person in the company already has access to recordings of phone calls
• This is a feature that my team requested that I implement.

Answer 1

I have decided to have a stab at answering this because, despite my reservations, this forum is to gain answers to questions not necessarily invoke criticism. It also fits haphazardly into the Project Management box so here goes.

Case Studies

Both the relatively new startup Buffer App and the mature startup Stripe practise completely transparent email company-wide as a policy and advocate it's use.

Buffer Technique

To keep things fully transparent, we’ve put some practices in place to ensure that all email gets shared across the team.

For starters, we have several internal email lists, one for each team and many more for different aspects of the company. I’ve been at Buffer for four months, and I just now discovered there’s an Android list, so the following might very well be missing a few I’ve yet to catch.

• team@ – this goes to the entire team

• engineers@ – includes all our engineering team

• heroes@ – for our happiness hero (customer support) team

• crafters@ – related to content marketing

• design@ – for design discussions

• product@ – for product feedback and signals

• metrics@ – anything to do with company metrics

• bizdev@ – for BD activities (partnerships, integrations)

• marketing@ – related to press activities

• improvements@ – for team improvements

• hiring@ – anything related to hiring and applicants

• ios@ – for iOS app discussion

• android@ – for Android app discussion

• champions@ – related to community engagement

• housekeeping@ – anything to do with bills, insurance, and misc.HR

• retreats@ – for retreat discussion

• culture@ – for culture and value discussion

These lists can either be sent to directly, cc’ed, or bcc’ed depending on the context. Here’s generally how we decide how to send to a list.

• email a specific team member and cc a list
• email an external person and bcc a list
• email to a list to notify a whole team

Stripe Technique

Over the last two years, we’ve gradually added structure as necessary in order to keep things under control. What we have today works pretty well for our current size—around 45 people.

We use Gmail for email and Google Groups for lists. We’ve been able to scale our particular usage with a custom list management interface built on the Google Groups API. The interface makes it easy to manage list subscriptions, get notified of new lists being created, and so on.

We have 119 lists as I write this post. Most of the lists are specific to a particular project, but some (such as 311@, if you have an issue you’re otherwise not sure where to send, or shipped@, where you announce something you’ve launched or completed) are company-wide.

foo-announce@: Email from the foo project to the company at large. These lists are generally low-traffic, have self-contained postings, and are intended for people who aren’t keeping up with the project in real time. For example, recruiting-announce@ is where we post notifications of job offers and outcomes thereof.

foo@: Email that would be on a traditional discussion list goes here. In other words, pretend that foo-archive@ did not exist. In that universe, would you send you mail on-list or off-list? If on-list, send to foo@.

foo-archive@: Email that you want to grant other people read access to, but don’t have any real expectation of them reading. Use this for email that would traditionally be off-list, whether due to volume or being targeted to a particular recipient or just being generally uninteresting.

foo-bots@: Automated mail for the foo project goes here. Depending on the project, it may be important for you to read this email. (For example, all breakages go to breakage-bots@, and so people who are triaging breakages should watch that list.)

In general, if you’re debating including an archive list, you should probably just include it. This includes internal P2P email which you would normally leave off a list, emails to vendors, and scheduling email. (If the email is sensitive in some way, though, it’s fine to leave it off-list.)

Both of these approaches are covered in much more detail in the hyperlinks I posted above.

Answer 2

The problem as you put it is one of the possible solutions to the problem.

In the spirit of Scrum, each person needs to have access to all communication to and from the customer so that when they communicate with the customer next, they have access to all the necessary information.

While true, it does not imply that they share a mailbox. More than that, it does not imply that they need every single email.

If you set up a system like you describe, it will lead to huge amount of waste (consider the time needed to glance through or read all those numerous replies nobody cares about anymore). It usually takes many emails to find a solution or come to an agreement for one question. The rest of the team should be interested in the outcome, not in the whole thread.

If your team shares the outcomes of discussions within itself, you should be fine. This can be done by either forwarding the last email to the rest of the team, storing it into a shared folder, or putting it into some kind of a wiki - plenty of choice there.

Answer 3

Shared email sounds over-complicated and inappropriate to me. A CRM system or customer service ticket management system feel like the most appropriate tool to achieve what you are after.

We use Zendesk to communicate with customers. Depending on the way it's set up every 'agent' can access everyone else's comms (including phone calls) with customers but generally speaking one agent 'owns' that communication. This can change depending on whether issues need to be escalated or dealt with by a specialist.

We integrate Zendesk with JIRA so that customer issues can be escalated to our technical team. You can set this up so that customers can see everything that happens in JIRA or you can keep it separate so that agents can see JIRA comments and supply further customer info but customers don't see what developers are saying.

If you feel like you want team members to be alerted to particular events then I'd recommend a group chat tool like HipChat, FlowDock or Slack. Most of these integrate quite nicely with CRM and customer service tools so everyone has visibility of activities but doesn't necessarily need to read through all of them to get to critical info.

I think your team will have more flexibility with a system like this without losing the benefits of email (private, one-to-one comms). There are dozens of tools out there that you could try but you might find Zapier a useful place to start. It's a service that joins up hundreds of services by triggering actions in one from actions in another (like pinging a chat service when an email with a certain subject is received). It's pretty powerful and we use it for a load of time saving integrations between our various services.

Answer 4

Why wouldn't you use some sort of Customer Relationship Management software to track things?

Might be a bit more work to reply to an email, but should make it easier to track conversations and promises...