In customer service every second matters. Angry customers don’t like to wait, and agents must to be able to address their questions promptly. In order to deliver great customer service, agents should be supported by a well tuned system, optimized to provide the best experience with minimal response times.
There are several ways in which a skilled administrator can optimize the performance of SAP Hybris Cloud for Service. The objectives of this post are to share these best practices, illustrate the compromises that some of them entail, and eventually allow you to shave precious seconds from the response time of your tenant.
This is Part 1 of this blog post. You can find Part 2 here. For a complete overview of Cloud for Customer performance best practices, you can start here: SAP Hybris Cloud for Customer: Performance Landing Page.
Customer Service agents are constantly working on a ticket after the other. The time it takes for the ticket UI to open, and the time it takes to save a ticket after a change, are usually the two most important factors in determining the performance experienced by agents. We will review several ways to optimize the Save step in Part 2. In this section, let’s review a few ways in which you can optimize the time to Open.
- Hide all facets that are not needed by your agents.
- Cleaner UIs load faster and provide a better user experience, and even secondary facets can have an impact on the load time of the UI.
- For example: if your agents will never need to review the Involved Parties, or the change history (Changes), or the Document Flow, hide those facets. Same for Feed, Attachments, Activities, etc.
- Review each facet and consider hiding it if it’s not required.
- In the Header and Overview facet, hide all fields that are not required by the agents. Hide entire sections, if possible.
- Each field in the Overview has to be loaded and rendered every time the UI is opened, even if it’s empty.
- Remember: cleaner UIs load faster and provide a better user experience. Your agents will appreciate the spring cleaning!
- For example: if having access to Similar Tickets is not useful in your scenarios, hide that section. If you don’t use all the timepoints exposed in the Timeline section, hide them. If you only need one field from the Additional Information section, move it to the header and hide the section.
- Review each of the fields exposed in the Header and Overview, and remove everything that is not strictly needed.
- Of course this best practice does not apply only to the Ticket Header and Overview: any facet, and any UI in general, should be subject to the same kind of scrutiny.
- Consider whether to show the ticket Interactions in the Overview or in a separate facet.
- The Interaction section is usually the heaviest component of the ticket UI, as it is designed to handle complex cross-channel threading logic. However, in many scenarios the agents only need the ticket description, for example when all tickets are created manually.
- If your agents don’t need the Interactions, or don’t need them for most of the tickets, hide the section from the Overview and replace it with two other components: the Description section in the Overview, and the Interactions facet.
- The Description section shows… the ticket description, and it is very efficient because it does not need to access any other object.
- The Interaction facet is functionally identical to the section in the Overview, but will only load the complex list when the facet is opened.
- What if a certain field (or facet) is required by just a subset of users? Consider using page layouts to optimize the UI of each user group.
- Page Layouts can easily be assigned by Business Role, which you should already have configured in your tenant.
- For example, you could define a “minimal” page layout for your service agents, and a more complex one for your managers.
- Another option is to move all the “extra” fields to a separate facet, so that they have minimal impact on the users who don’t need them.
The Live Activity side pane is the entry point for all phone support flows. A little-known feature can help streamline your process, reducing end-to-end times.
- If your agents always need to edit phone tickets after creating them, enable the “New Ticket” button which goes directly to the full Ticket UI.
- Here is the little-known fact: Live Activity actually provides two “New Ticket” buttons. The default one behaves exactly as the normal ticket Quick Create in the left toolbar: it opens a pop-over where the user can input the basic ticket information, and then provides the options to “Save” the ticket or “Save and Open” it in the Ticket UI.
- The second “New Ticket” button skips the pop-over, and immediately opens the new ticket in the Ticket UI (similarly to what happens after a “Save and Open”). The agent can then edit the basic information (service categories, notes, etc.) but also access more complex features such as the Involved Parties or the Service and Repair facet.
- If your agents consistently need to open the Ticket UI while on the phone, the second “New Ticket” option can optimize their flow by saving them at least one click. You can enable it by adapting Live Activity in Silverlight.
- In some scenarios it may even make sense to expose both “New Ticket” options. In that case, keep in mind that you should rename one of the two buttons (via Language Adaptation), and you should also remove one of the other buttons, as Live Activity can only accommodate three buttons in total.
An optimal Ticket UI is a basic requirement towards achieving good performance. In Part 2 we will review additional ways to minimize the waste of resources, selecting the right Scoping questions, configuring Workflow correctly, and keeping in mind a few other very important factors.
Have you found other interesting ways to improve performance? Don’t forget to share them in the comments!
All the best,