This is the third 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 2 here. For a complete overview of the blog posts in the Cloud for Service Expert Corner, you can start here.
So far we have reviewed how the Administrator can enable the email-to-ticket process in a tenant, and the detailed configurations of the different flows. Let's now review how these configurations reflect upon the user experience, and what capabilities are available when responding to an email.
In this post we will focus on the capabilities available within the current HTML5 Ticket UI. The same capabilities are gradually becoming available in the new Responsive UI, but that's a topic for a different post.
As for any other ticket, Incoming emails frst appear in the Queue. It is easy to immediately recognise emails tickets by the icon in Channel column, which also shows the name of the channel through which the email was received.
Once the ticket is opened in the Agent Workspace, the email is visible in the Interactions section (or in the Interactions tab, depending on your setup). The user is offered three self-explanatory options: Reply, Compose New Email, Forward.
Clicking on any of the options opens the response editor, prefilled based on specific logic:
When replying, the FROM is defaulted to the channel through which the latest incoming email was received (i.e. most often the TO of the incoming email).
When composing a new email, the FROM is defaulted to the email address of the Team to which the ticket is assigned. Such email address can be maintained by the Administrator in the Org Structure, and needs to be a valid FROM (i.e. it must also be maintained as an outbound email channel). If the Team has no email address, the FROM will be empty.
The FROM can also be manually selected by the agent among all outbound email channels, by clicking on the pencil icon next to it. This is required when the Team has no email address, and useful when the agent prefers to reply through a different channel. It is also possible to restrict via SDK which outbound channels should be available for selection.
When replying, the TO is defaulted to the sender of the latest incoming email.
When composing a new email, the TO is defaulted to the email address of the customer linked to the ticket, visible in the Customer section of the Ticket UI. If the customer has no email address, the TO will be empty.
When forwarding, the TO is by default empty.
In all cases, recipients can be manually added as free text, or selected among Individuals, Contacts, or Employees using the "+" icon next to the field.
It is also possible to use the SDK to clear or change the default TO.
CC and BCC
When replying, CC is defaulted to the CC of the latest incoming email (minus the channel, if it was originally in CC and has now become the FROM)
BCC is always by default empty
Recipients in CC and BCC can always be added manually, similar to those in TO.
The Subject is always defaulted to the combination of Ticket ID and Ticket Subject (which was automatically derived from the subject of the first incoming email)
The Ticket ID is included following a specific pattern, and it is required in order to make sure that further responses are threaded within the same ticket.
In Part 2 we reviewed two kinds of templates: Branding Templates and Response Templates. Branding Templates are configured by the Administrator while setting up email channels, and Part 2 shows how to use them. Response Templates are text-only snippets which help agents be more efficient, by not having to type the same standard response multiple times. Response templates can be added to a response by clicking on "Insert Template", right below the response editor.
All templates are managed from the workcenter view Service -> Templates. While Branding Templates require uploading an HTML file, Response Templates can be created directly within Cloud for Service. Companies can create corporate templates visible to all agents, and users can create personal templates based on their own habits and preferences. Response Templates can include placeholders, which are automatically resolved by the system while adding them to a response. It is also possible to directly convert an outbound interaction into a new template.
When selecting a template to add, the system will show by default those that match the current communication channel (e.g. when composing an email, the system will show Email templates and not SMS or Social Media templates). Users and Administrators can define queries to show only specific templates, for example based on ticket language. It is also possible to use the SDK to define a set of "proposed" templates, for example based on service categories or other custom attributes.
Using external email editors
In certain scenarios, companies may find it convenient to compose email responses outside SAP Hybris Cloud for Service, leveraging the capabilities of a standard email client. This could be useful for example if it is important for users to have access to the corporate address book or to specific capabilities not available within the ticket response editor.
The system offers two options to address such need: the ability to "Reply via Microsoft Outlook", and the more generic ability to "Reply via External E-Mail Editor". They can be enabled via two mutually exclusive scoping questions:
And can be temporarily disabled by unchecking the flag shown below the Reply box:
In both cases, "Reply" and "Compose New Email" behave as mailto links, and clicking on them triggers the opening of the default email editor. Also in both cases, the outbound email is automatically brought back into the system, and added to the correct ticket as a new interaction. There are however fundamental differences between the two options, which should help choose the best one for each scenario.
Reply with Microsoft Outlook
Assumes that the default email editor is Outlook; that the SAP Hybris Cloud for Customer Outlook Add-In is installed; and that the Service option of the Add-In is active and configured.
Allows the user to select which of the available Outlook inboxes should be used as the sender for ticket responses, regardless of the default inbox. For example, an agent may have access to both her personal inbox and the shared support inbox: the system can be configured to automatically use the shared inbox as the sender of new ticket responses, while the agent keeps her personal inbox as the default for all other emails.
The Add-In can recognize ticket responses (by noticing the pattern in the subject) and automatically bring them back into Cloud for Service as interactions within the correct ticket.
Given the dependency on the Add-In, this capability can only be used on machines running Outlook and the Add-In itself (i.e. not on mobile devices).
Reply with External Editor
Does not make any assumption on the email editor, and can therefore be used on any device, including tablets, and with any editor, including web editors with no local client.
Since there is no Add-In available to influence the sender (which cannot be set via mailto), the sender is always defaulted by the email editor. In most cases, this means that ticket responses are sent from the user's personal inbox.
Also, since there is no Add-In to automatically bring back the email, the system adds the support channel in CC of every new response (via mailto). This ensures that a copy of the email will come back into the system, where it is recognised as an outbound response (rather than a normal inbound email), and threaded accordingly within the correct ticket.
Each option has therefore its pros and cons. Using Outlook requires the Add-In and limits the choice of devices, but allows sending emails from a shared inbox with no extra recipients in CC. It is a good fit, for example, for support organisations whose users already have access to a shared inbox, and would like to keep using it when composing responses. Using a generic external editor allows full flexibility of editor and devices, but sends responses from the user's personal inbox and requires keeping the support address in CC. It is a good fit, for example, for sales users who also need to reply to tickets and want to do it from their mobile device.
Actions on Emails
To close this post, let's review the actions available on incoming email interactions and the specific scenarios they address.
"View Original Content" allows opening a copy of the original email, as received by the mail server and before it was converted to an activity. It is useful in order to see HTML content or inline images which are not rendered correctly within the Interactions list.
"Copy to Ticket..." allows creating multiple copies of the email content, in multiple tickets. The email itself is not moved, as one email can only be linked to one ticket; but its content is used as the description of new tickets, as many times as needed. For example, a customer may have sent an email reporting multiple issues or placing multiple orders, and the internal policies may impose tracking each issue/order in a different ticket. This action is available on all incoming emails.
"Split to New Ticket" allows creating a new ticket out of the latest incoming email. For example, the customer may have responded to an old thread to report a new issue, and the agent may prefer to track the new issue as a new ticket. This action is available on all incoming emails that have not been responded to, with the exception of the first email in the thread (as in that case the email is already in a new ticket).
Finally, "Move to Existing Ticket..." allows merging different conversations. For example, the customer may have sent multiple emails about the same issue, which have been converted into different tickets. By using this action, all emails can be consolidated into a single thread, and all other tickets can be marked as irrelevant. This action is available on all incoming emails that have not been responded to.
The tenant is now ready to receive emails, the channels are configured to convert them into tickets, and the agents are fully equipped to reply to them. In the next posts we will cover how these capabilities are evolving with the move to the new Responsive UI, and we will address some advanced topics which may be of interest to Administrators.