The focus of this article is on how to properly organize the use of email in your organization in order to improve the quality of the support you provide.

If your organization relies heavily on email for receiving and answering support requests, you should find it interesting.

Let's start.

Considering all the email addresses an organization uses, we see that most belong to one of just three main categories. Using a fictional organization, called 'Some Organization', as an example, these categories are:

1) Single-Person Email Addresses: Email addresses of individuals - personal email addresses.
For example, Mr. John Doe has the john.doe@someorganization.tld personal email address.

2) Multi-Person Email Addresses: Email addresses of groups of individuals.
Mr. John Doe, above, works for the Service Activation Team, which has the service.activation@someorganization.tld Multi-Person Email Address and which is a sub-unit of a bigger business unit called the Operations Department which, in turn, has the operations@someorganization.tld Multi-Person Email Address.

Typically, Multi-Person Email Addresses correspond to organizational entities, like departments, teams, units, verticals etc. A usual set of requirements for Multi-Person Email Addresses are that each individual in the group can access the received and sent emails, and can send emails on behalf of the entity ( that is, with the email address of the entity as the sender ). Such a setup is commonly called a 'Shared Mailbox', 'Shared Inbox', 'Team Email', or 'Group Email'. The way you implement such a setup is not standard. There are email platforms that include such functionality and there are dedicated applications that provide it. In some cases, Multi-Person Email Addresses are setup so that they accept emails only from a limited list of senders ( typically, only senders from inside the organization, making them 'Internal Only' email addresses ).

3) Interface Email Addresses: Email addresses that serve as interfaces to system platforms.
For Example, the Support interface has the support@someorganization.tld interface email address.

At this point, it is important to state that Interface Email Addresses and Multi-Person Email Addresses are quite different propositions and they should never be mixed.

In fact, having email addresses that are, at the same time, expected fill both the Multi-Person Email Address and the Interface Email Address roles, is one of the biggest mistakes an organization can make.

Even if you have just one Support Team, you absolutely must not use just one email address ( for example, support@someorganization.tld ) as a combined Interface Email Address ( for the Support Function ) and Multi-Person Email Address ( for the Support Team ). It can be done, but it is a very bad idea. The right thing to do is to use different email addresses for Interface Email Addresses ( for example, support@someorganization.tld ) and Multi-Person Email Addresses ( for example, support.team@someorganization.tld ) and there are plenty of compelling reasons for that.

In the case of Freshdesk, let's start by categorizing incoming emails as either Related Incoming Traffic ( emails that should be forwarded to your Freshdesk - anything related to actual tickets) or Unrelated Incoming Traffic ( emails that should not be forwarded to your Freshdesk - for example internal emails, subscriptions to newsletters, alert emails etc ). With this in mind, major reasons to not mix Interface Email Addresses and Multi-Person Email Addresses in your Freshdesk platform are:

a) Avoiding flooding your Freshdesk platform with Unrelated Incoming Traffic and wasting resources over it.
Keeping Interface Email Addresses distinct from Multi-Person Email Addresses means that as little Unrelated Incoming Traffic as possible will reach your Freshdesk platform. In this way, your Agents will mostly be working on legitimate support cases - not weeding out "unqualified" tickets. This is critical for maximizing performance, and minimizing mistakes and oversights. And, by the way, even if some email was sent to the wrong address ( like your info@someorganization.tld or the personal address of a supporter ), your staff can always forward it to your Freshdesk manually, with ease.

b) Avoiding unnecessary automatic responses to Unrelated Incoming Traffic from your Freshdesk platform.
Freshdesk may send various automatic responses. For example, a new ticket generates emails such as New Ticket Notifications, Group and Agent Notifications etc. When these are generated for Unrelated Incoming Traffic, they distract your Agents and annoy the sender.

c) Avoiding unnecessary automatic responses to Related Incoming Traffic from your email platform.
Email platforms may send Out-Of-Office, address does not exist, message rejected for such-and-such reason, and other automatic responses. None of these is something that a legitimate Requester would like or have to see. This is unprofessional and may confuse the sender.

d) Avoiding skewed Freshdesk statistics.
The more Unrelated Incoming Traffic your Freshdesk platform handles, the more unqualified tickets will be created. Your Agents may outright Delete or Close these tickets. In the later case, the statistics will become skewed as there will be more New tickets than there should be, and a high proportion of these tickets ( the unqualified ones ) will be Closed in a very short time.

e) Avoiding issues when you reorganize.
When your Support Team grows and splits into multiple tiers or specialized sub-teams, the fact should not be apparent to the outside world. An advantage of well chosen Interface Email Addresses is that they can be kept to a minimum and rarely, if ever, need to be changed. Even huge organizations, may utilize just a handful of Interface Email Addresses for most tasks. For example, a support@someorganization.tld is usually as good an Interface Email Address for an organization with a staff of 10 as it is for an organization with a a staff of 10,000 or even 100,000 people. However, in the course of its life an organization will certainly create / merge / delete / split / rename organizational entities and, therefore, Multi-Person Email Addresses. If you don't mix Interface Email Addresses with Multi-Person Email Addresses, changes in organizational structure will have minimum impact on your contact interfaces with the world.


This brings us to the second major mistake, which is exposing to the outside world more of your internal workings than you have to.

In the case of how you approach support via email the two extremes of the spectrum are:

1) You can use one or two Interface Email Addresses and forward all incoming email traffic to a first tier of support. This first tier of support may handle easy tickets and re-assign the rest to your Freshdesk Groups most appropriate for handling them.

2) You can advertise one Interface Email Addresses for each Freshdesk Group you have and let each Freshdesk Group decide what to do with incoming traffic ( handle it themselves or forward it to another Freshdesk Group ) and how to coordinate with other Freshdesk Groups.

The first approach, namely a minimum number of Interface Email Addresses is the right way, but with a few caveats.

The reasons supporting this statement are numerous. To state a few:

a) If you decide to use multiple Interface Email Addresses ( say, support@someorganization.tld, orders@someorganization.tld, activations@someorganization.tld, repairs@someorganization.tld, service@someorganization.tld, logistics@someorganization.tld, returns@someorganization.tld, ...@someorganization.tld ) you shift the responsibility of proper case assignment ( deciding what email to contact ) to the requester. Or, from a different perspective, you grant the requester the power to select the routing of their choosing. The requester may deal with this in a number of wrong ways: they may be frustrated by the multitude of options for Interface Email Addresses ( especially if it is difficult to decide what the right Interface Email Address is ) and / or they might try to game the system by sending the same email to many Interface Email Addresses, believing this will increase their chances of success and / or they may address an Interface Email Address that they guess is not the right one but out of which they got better support in the past.

b) If the requester posts a new request to multiple Interface Email Addresses, you will end up with multiple new tickets for a single case and, to make matters worse, you can't even be sure that any of these emails will be addressed to the right Interface Email Address.

b.1) Multiple new tickets for a single case means that the Requester will receive multiple New Ticket Notifications from Freshdesk ( if you have that option enabled ). This is not only annoying but also largely cancels the idea of replying to the New Ticket Notification to follow-up on the ticket thread. Experience shows that in such a case the Requester will probably not reply to any of your New Ticket Notifications but, instead, send a new email to the original list of Interface Email Addresses with something like "btw, I forgott to mention that ..." leading to another round of new tickets and New Ticket Notifications.

b.2) Multiple tickets for a single case also means increased workloads for your personnel ( to handle the increased number of tickets, even if they only have to conclude that it is not meant for their Freshdesk Group ), increased coordination efforts and increased room for errors. Typical such errors include: all Freshdesk Groups ignore a new case, thinking another Freshdesk Group should and will handle it - two or more Freshdesk Groups independently take up a new case, not realising that other Freshdesk Groups are also working on it.

c) Another, more indirect benefit, of using few Interface Email Addresses is that an organization has a very hard time putting into place a proper support structure if it starts by trying to bring together support functions that are spread across many organizational entities. Using few Interface Email Addresses necessitates having some kind of first tier of support, thus guarantees that there will be at least a basic level of centralized, dedicated, professional support structure. Even if you start with just a couple of people that sort cases out and then rely on other organizational entities to address them, at least you have a foundation on which to build ( by adding resources like staff, training, infrastructure, tools etc ) and evolve ( by adding more tiers and/or specialized support teams ). You can also build enough critical mass to have other departments cooperate with you on more balanced terms. For example, you can have the IT Department of your organization offers you tailored interfaces to the ERP, CMS and other platforms or to even create custom tools for you or the Product Department, Engineering Department and/or Operations Department to your needs and feedback ( especially when backed up by Freshdesk statistics ) into account when designing, producing and offering products and services. The support function should be a valued player in the team that your organization should be but this will not happen if the support roles are chaotically disperesed in disparate business units.

d) Finally, if you opt to use few Interface Email Addresses it will be easier to offer extended hours support ( even if it is just Tier-1 support, even if it is not full 24/7/365 ). This will be much harder and costlier - probably, not even feasible - if you have large numbers of Interface Email Addresses and corresponding Teams.

On a sidenote, you can use Freshdesk Groups with different SLAs to realize support policies like "our technical support is available 24-hours a day but with SLA #1 for cases created during work hours and SLA #2 for the rest" because, say, the 1st shift is fully-staffed and the other two shifts have reduced personnel or rely on on-call supporters. This would mean creating two Freshdesk Groups ( with matching SLAs, Dispatchr rules etc ) for just one Tier-1 Team but it isn't difficult to setup.

However, there are the caveats mentioned above: You should keep the number of Interface Email Addresses to the minimum viable but not less than those.

There are two main reasons for opting to have more Interface Email Addresses than the bare minimum:
1) When the purpose of each Interface Email Address is so clear that only rarely will Requesters will use many of them and create multiple new tickets for a single case. For example, instead of support@someorganization.tld you may decide on the pair of technical.support@someorganization.tld ( and a Technical Support Tier-1 Team ) and commercial.support@someorganization.tld ( and a Commercial Support Tier-1 Team ) if you know that it is clear when someone should address Technical Support ( when your products don't work properly ) or Commercial Support ( in all other cases ). Going this way, will provide a first level of filtering cases, allowing you to staff the Technical Support Tier-1 Team and Commercial Support Tier-1 Team with more specialized personnel and / or working on appropriate shifts.
2) When you have so discrete policies for each Interface Email Address that you want it made very obvious to the Requester. For example, if you offer business-hours support in general but 24-hour technical support in particular, you would probably want to make this very clear and say so in your Contact Us webpage: "Contact technical.support@someorganization.tld for our 24-hour technical support. Contact commercial.support@someorganization.tld for all other cases."

Tip: you might want to create aliases for long email addresses, especially if they are frequently communicated over the phone. It is easier to say "please contact help@someorganization.tld" / "please contact ts@someorganization.tld" / "please contact cs@someorganization.tld" than saying "please contact support@someorganization.tld" / "please contact technical.support@someorganization.tld" / "please contact commercial.support@someorganization.tld" and even spell it to the other party.

To sum up, start by figuring out the minimum viable number of Interface Email Addresses. They must be few and easy to figure out.

Then, match each Interface Email Address to a Tier-1 Team, as one or more Freshdesk Groups, that will screen new cases, provide basic support where it can or escalate the case to the right Freshdesk Group where it can't.

Make the ground rules clear. For example, the other Freshdesk Groups may be able to interact directly with the customer ( don't forget that the sender email addresses they will be using will be the Interface Email Addresses of Freshdesk so your internal structure is not exposed to the Requester - only the signature of each Freshdesk Agent may reveal what their function/unit is ). Or, they might not be allowed to do that but be instructed to pass their input to theTier-1 Team for relaying to the Requester. It is your call. Just make sure that your rules cover most scenarios, assign responsibilities and list expected outcomes in a clear, concise and comprehensive way.

One last tip about Single-Person Email Addresses:

Freshdesk uses the Single-Person Email Addresses of each Agent as an identifier and contact address. However, Freshdesk goes one step beyond and treats differently emails that enter Freshdesk from Agent email addresses than those that enter from regular senders. The two most obvious differences are that Freshdesk will create a Public Note when an email from an Agent is threaded to an existing Freshdesk Ticket ( even if the Requester was not in the list of recipients - you might seriously want to avoid that ) and that Freshdesk will create a new ticket with the original sender as Requester if a forwarded email from an Agent creates a new Freshdesk Ticket.

In our organization, we don't want Public Notes created in the scenario mentioned above. We do that by using an alias email address as the Freshdesk Agent email addresses. As our mail platform is configured, this alias address should never be used as a sender email address in outgoing messages. Suppose that the user is Mr. John Doe and when he sends emails from his email client they appear with john.doe@someorganization.tld as a sender. There is also a jdoe@someorganization.tld alias email for the same person and this is the one we use as his Freshdesk Agent email address. Therefore, if he uses his email client to post something that will end up in Freshdesk, it will come from john.doe@someorganization.tld, which Freshdesk does not associate with any Agent, and be treated as a regular sender ( thus no Public Notes ). The trade-off is that he can't forward an email to Freshdesk and have it automatically create a ticket on behalf of the original sender ( he has to login to Freshdesk and edit the new ticket to set the Requester ), but that is something we can live with.