When it comes to mastering Unified Service Desk (USD), it’s important to remember CSR. CSR stands for Control-Session-Rule and is an approach to the most effective way to learn USD. In system design, quality relies on the vision and expertise of the team. To gain these strengths as your team learns USD, the best approach is CSR.
USD is new technology, which means there’s a lot to learn, so learn Controls, Sessions, and Rules one by one with the help of this three-part blog series. With all of this knowledge under your belt, you’ll be in a much better position to begin designing the USD configuration that will improve efficiencies and drive down costs in your Customer Care environment.
USD’s controls are officially dubbed Hosted Controls. These are configured in CRM and provide the functionality that a Customer Care Agent needs to fulfill their role. USD provides many standard Hosted Control types, as well as the option to develop your own custom controls using .NET code. The possibilities are vast, so here are a few quick examples of the Hosted Controls that a typical USD configuration might have.
In the main area of the USD window, a Hosted Control could display a portal page, a legacy application, CRM forms, or custom screens. Along the edges and sides, other Controls might be configured to show menus, buttons, scripts, or links. In the background, inconspicuous Controls provide vital application functionality, like managing USD’s connection to CRM and arranging the layout of the user interface.
Like the rest of USD’s configuration, controls are defined as records in CRM. At startup, the USD Client connects to the CRM organization and initializes by downloading the user’s assigned configuration data, including Hosted Controls. This is how USD makes configured features available to a Customer Care Agent.
A Hosted Control is technically a single CRM record, but there’s a little more to it than that. Controls need Events and Actions in order to actually function, but what are those things anyway? Actions provide a way to send a command to a control, and Events notify USD when something noteworthy is happening inside of a control. If one Hosted Control needs to send some data to another control, that data is typically bundled into an Event. When USD sees the Event, it can trigger Actions on other controls and pass the data right along. In short, this is how the USD framework operates, fueled by Events and Actions. Any Hosted Control, once created, only becomes useful after the Events and Actions are added.
Thankfully, CRM plugin automation handles most of the heavy lifting here. When a Hosted Control is created, many Events and Actions are added automatically. This can save a lot of time, since a standard control may have dozens of Event and Action capabilities. However, custom Hosted Controls do require a bit of manual effort here. The CRM plugin is unaware of any custom Events and Actions in the code, so to make use of those features, the corresponding Action and Event records will need to be added to the control manually.
Among the standard control offerings, the obvious standout is Agent Scripting. This control is designed to guide agents through business processes by providing literal scripts to be read to customers, instructions for the current stage of the business process, and buttons (known as Answers) to facilitate automation and branching business logic, pictured below. Agent Scripting is also sensitive to changes in “context,” USD’s repository for contextual information. This means, for example, if the Scripting Control is displaying the address from a customer record, then an update to that address will reflect in the Scripting Control upon save of the record.
USD’s not so obvious standout among the standard controls is the Session Overview. USD can host custom XAML controls readily, but those controls need to be properly coded if they are to respond to changes in USD context. Session Overview is different because it both interprets XAML and responds to context changes, making it incredibly useful as a standard Hosted Control. It can offer configuration-level, “above-the-code” solutions for desired functionality that is not offered by Agent Scripting.
USD also offers standard controls for timing sessions, tracking to-dos, and taking notes, just to name a few. Occasionally, however, it’s necessary to develop similar controls with additional features in order to either facilitate a business process, or to add features for automation and efficiency. To code, or not to code, that is the question. Understanding the capabilities and limitations of the standard controls and how they can communicate with each other will be very important once you start planning your production environment’s first USD configuration.
Check out MSDN for more information on USD’s standard Controls, and make sure you tune in for the next installment of the series where we talk about sessions.