Email Response Management in C4C – Part 2 – Cloud for Service Expert Corner

This is the second part of a blog post on how to configure and use Email Response Management in SAP Hybris Cloud for Service.  You can find Part 1 here, and Part 3 here.  For a complete overview of the blog posts in the Cloud for Service Expert Corner, you can start here:  Introducing the C4C Service Expert Corner Blog Series.

So far we have reviewed how the Administrator can enable the email-to-ticket process in a tenant.  Let’s now review the details of the different flows, and understand how the process can be influenced by the channel configuration.

Basic Setup

Regardless of the kind of flow, configuring any email channel requires providing some basic information.  Besides (obviously) the actual email address, the system requires an ID, and the direction of the channel.  The ID will be used wherever the channel is exposed for further settings, for example in the routing tables.  The direction defines whether the channel will also be available as a FROM address when responding to tickets, i.e. used not just to receive inbound communications, but also to send outbound responses.

B2C Customer Support

Whenever an email is received by a B2C channel, the system first creates an email activity, and then analyses the email subject looking for a specific pattern used to track emails belonging to the same ticket:

Re: [ Ticket: # ] <Subject>

If a ticket ID is found in the subject, the email is threaded within the ticket, unless the ticket is in status Closed or the ID is invalid (e.g. there’s no ticket with such ID).  If the ticket is Completed, its status is automatically set back to In Process.  If the ticket is Closed, the ID is ignored.

If a valid ticket ID is not found in the subject, then the email generates a new ticket.  But first the system needs to determine which customer to use when creating the new ticket.  The sender’s email address is used to search among all Individual Customers already known.  If no match is found, by default a new customer record is created automatically.  Finally, a ticket is created using the Ticket Type configured by the Administrator.

If the Administrator does not want new individual customers to be created automatically, he or she can configure a Default Customer for the channel.  Tickets will be created on the Default Customer whenever the sender is not found in the system, allowing agents to manually review those emails and take the most appropriate actions.  Using the Default Customer in a B2C scenario is quite rare, but it can be appropriate for companies that happen to have full knowledge of the consumers who could potentially reach out.

B2B Customer Support

The main difference between the B2B flow and the B2C flow is that in the B2B flow new customer records are never created automatically.  The main assumption is that a B2B organisation would already know the majority of contacts who could potentially reach out, typically because they have been replicated from an ERP system, and that the creation of new customer records should be a closely controlled process rather than an automatic one.

Whenever an email is received by a B2B channel, the system creates an email activity and searches for the sender’s email address among all known Contacts.  If the sender is unknown, the email takes the exception path regardless of whether it carries a valid ticket ID or not.  If the sender is known, the system analyses the email subject looking for a ticket ID, and if a valid ID is found the email is threaded within the ticket.  If a valid ID is not found, the email generates a new ticket, linked to the Contact identified and to the corresponding Account.

By default the exception path is the shared inbox under Service -> Unassociated Emails.  This is where the system would drop all emails from unknown senders, and also emails that for various reasons could not complete the standard process (e.g. because the system found multiple contacts with the sender’s email address).  If the Administrator prefers a more structured way to handle these exceptions, he or she can configure a Default Account for the channel.  If a Default Account is defined, all emails that take the exception path become tickets on the Default Account and its main Contact.

Unassociated Emails vs. Default Account

The decision to use Unassociated Emails or a Default Account is an important one when configuring a B2B channel.  Unassociated Emails allow for a quite straightforward management of the exceptions, allowing the user to convert each email into a new ticket, add it to an existing ticket, or delete it from the system.  At the same time, the Unassociated Emails path is best suited for a low volume of exceptions, since it does not allow for any complex routing or task assignment.

If the expected volume of emails taking this path is quite high, defining a Default Account is very often a better option.  As a side note, a high volume of emails taking the exception path is also a signal that there may be issues with the master data, or that the B2C flow could have worked better.  The Administrator can define different Default Accounts for each of the support channels, and then define routing rules based on these Accounts.  This way the tickets will end up in different queues, and the handling of exceptions will be shared across the organization.

Employee Support

The Employee Support flow is very similar to the B2B flow, with two key differences:  it focuses on Employees;  and there’s no Default Employee option.  The main assumption is that an organization supporting employees would definitely have a good understanding of all the people who could possibly reach out, and therefore an unknown sender would be a true exception.

Whenever an email is received by an Employee Support channel, the system creates an email activity and searches for the sender’s email address among all known Employees.  If the sender is unknown, the email is dropped under Unassociated Emails regardless of whether it carries a valid ticket ID or not.  If the sender is known, the system analyses the email subject looking for a ticket ID, and if a valid ID is found the email is threaded within the ticket.  If a validID is not found, the email generates a new ticket.

Outbound Setup

If the channel is configured to be used for outbound responses, the Administrator can customise it with one additional attribute:  a branding template.  The branding template will be applied to all outbound emails sent from the channel, adding it around the response prepared by the agent.

A branding template is a simple HTML file with a #TEXT# placeholder, usually included between a standard header and footer which carry the brand logos and disclaimers.  The Administrator can configure a different branding template for each channel, making it easy to support multiple brands.  The agents will only have to pick the right FROM address, which in any case will most of the times be automatically determined by the system (as we will see in Part 3 of this blog post).

Branding Templates and Response Templates

It is very important to understand the difference between the various kind of Templates available, as they play different roles in the email response process.  Response Templates are text-only snippets which the agent can use to avoid typing common responses.  We will review them in detail in Part 3.  Branding Templates are HTML files, typically used to add header and footer to outbound emails.  The result is that emails received by end customers are the sum of the agent response + any response template selected by the agent + the branding template defined for the channel.

The tenant is now ready to receive emails, and the channels are configured to convert them into tickets as defined by the Administrator.  In Part 3 we will review the email response capabilities available within SAP Hybris Cloud for Service, covering both the agent interface and the various features that support it.

All the best,
Gab