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.
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.
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.
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,
You mention that inbound e-mails can't be associated with a default employee record. This means that inbound e-mails for employee support (with no ticket ID reference) where the e-mail address is unmatched must inevitably end up in the unassociated e-mails list.
How do these e-mails get converted into employee support tickets? There's an option to convert to new ticket but this doesn't convert to an employee support ticket; it converts to a 'standard' support ticket.
You need to ensure that your user has the Employee Support workcenter assigned. All users with the Employee Support workcenter are considered Employee Support agents. All users without that specific workcenter are considered customer service agents.
Employee Support agents are only offered the option to create Employee Support tickets, and vice versa for customer service agents. So only an employee support agent will be able to convert an unassociated email into an employee support ticket.
Hope this helps!
Thanks for this blog.
We have a situation in B2C, where in tickets or customers should not be created automatically from the email. It should be a manual activity. Looks like it is not possible to restrict creation of tickets or customers through the scoping if I am not not wrong. Please suggest if there is a way of doing it via scoping.
As an alternative we are trying to achieve it through SDK, service request validation on save logic. However strangely the validation on save method of service request is not getting triggered when the ticket is getting created via email. In all other cases this method is getting triggered.
Also, EmailActivity BO does not allow to add any script files on the other hand to restrict creation of the ticket follow-up item in SDK.
Please suggest a workaround.
Please see above in the post, in the section "B2C Customer Support":
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.
I have disabled the auto ticket creation from email in project scope and defined the default customer in B2C email channel, but when I send the email to B2C technical ID it still creates the ticket. Please advise how can I stop the ticket creation ?
We have B2B and B2C both business environment, I came to know that we can either use b2B or b2C technical ID for customer email forwarding in exchange server to c4c. my question is how we can manage this scenario where both B2B and B2C is required ? If we use both technical ID for email forwarding then in all the cases either contact or indvidual customer will be missing in c4c and system will either send the email under un-associated email or it will create new individual customer. Please advise.
For B2B scenario, "system searches for the sender’s email address among all known Contacts"
Is it looking for exact match of contact email address?
is it possible to create a new Contact from incoming un-associated email if extension of email is matching with an account corporate email extension? and then create the ticket for this contact?
that would be great from customer experience perspective. customers contact people can change in time and to update contact people in vendors CRM system (which is our clients C4 system) is not a priority. so these emails will go always un-associated box. I dont think so service managers or technicians will check this always, since it is not B2C there might not be a centric customer support center.
i really like to create directly tickets from incoming emails for regarding service teams. in my scenario teams differentiate by region. however we don't intent to create different email IDs for different team. we can determine regarding service team by customer address. however we need account in tickets.. do i have to use un-associated emails?