Wednesday, October 27, 2010

Routing of escalated service tickets

When an agent creates a service ticket or service process which is supposed to be picked up by another department, SAP CRM supplies an escalation process. This means that SAP can determine which agent or group is supposed to be the next to take a look at the service ticket.
The service ticket escalation process is part of the Rule Policy functionality. Based on several conditions, different agents or groups can be determined to look at the service ticket.
Most common conditions would be that the status must be OPEN, and then per category a different agent or group will be determined. A common process would be as follows:
  • The customer has a question or complaint that cannot be immediately resolved
  • The agent creates a service ticket
  • The agent enters the details. One of the actions is to select the correct categorization.
  • When clicking the escalate button, the system determines the responsible group based on the selected categories.
The service ticket is now assigned to the correct department (for instance the financial department in case of dunning questions). They will pick up the service ticket from the Agent Inbox, and handle the customer's question.

The settings for the escalation routing can be done in het IC_Manager business role under Process Management --> Rule Modeler.

The rules can be implementing Rules in the ORDERROUTING node.

Wednesday, October 20, 2010

Efficient Agent Inbox Processing

In the IC Webclient, functionality is available called the Agent Inbox, formerly known as the Universal Agent Inbox (AUI).

A typical proces involving the Agent Inbox is the processing of complex customer questions that have been escalated by callcenter.

The Agent Inbox basically is a list of items to be processed. The items can be workflow Items, Activities, Emails, Service Tickets, Service Processes, etcetera.

The list is determined using a search on the database. It thus isn't an actual 'inbox' (where items are placed in a box), but a search result page.

When working on the agent inbox, you first select the parameters on which you want to search the system for the items. Users can be helped by Fast Search options, which are defined by the system administrator or the Callcenter Manager. A typical Fast Search option would be 'Open Items assigned to My Group'.

After the items are determined, the agent can process the open items.

PRO's of the agent inbox:

Dynamic inbox definition
Because you can set the search parameters you can define the inboxes so that one item can be in several boxes at the same time. For instance, an open service ticket can be in the Open Items box, as well as in the unfinished items box, where the Open Items contains only the Open items, where the unfinished items box also contains the items with status ‘In Progress’.

Single point of entry for different types of items that need attention
You will have Workflow Items, Contacts and Service Requests all in the same place.

Immediate Customer Context
When you choose to edit the item, the attached businesspartner (customer) is automatically ‘confirmed’ This means that you have all relevant information at you fingertips immediately without having to search for the data

Multiple User
Multiple users can work on the same inbox without running into locked items.

Search based on the Organisational Model
When retrieving the data from the system, you can use 'Items assigned to My Group', which retrieves all items assigned to any of the organisational groups the agent belongs to.

The Agent Inbox can prioritize based on Due Date. If you implement so that items with a higher priority or with a certain classification have an earlier Due Date, the Agent Inbox can give them priority.

Automatic Next Item Determination
You can have the Inbox determine the next available (highest priority) item automatically.

CON's of the Agent Inbox

The agent inbox does not automatically refresh
When the agent has processed an item it would be helpfull if this item would automatically be removed from the inbox. In some cases, this does not happen.
Especially if the item would be assigned to another organisational unit or if the item's status has changed, but is not closed yet.

Loading all items can take a while as technically it launches a search on the system
Depending on the size of the database, a search can take a while. You can set the maximum number of hits though, so it won't look for all of the thousand open tasks ;-). Standard number is 50, which should be sufficient.

No Automatic 'next-item-determination'. 
The screen does not automatically determine the next item to be processed, but there is button with this functionality.
No automatic return to the Inbox
When finishing an InboxItem, the system will not automatically return to the inbox, but to the search screen.

So, what to do now?
Of course, this blog would be useless if it would not give you an answer to the CON's.

The agent inbox does not automatically refresh
To tackle this issue, you can implement a refresh in the do_prepare_output.
You might expect longer runtimes as the system retrieves the data from the database every time, but in practice the search time is ok, as all info is already buffered.

  DATA: lv_index TYPE int4,
        lr_node TYPE crmt_bsp_treetable_node,
        lr_mixed_ent     TYPE REF TO   cl_bsp_wd_mixed_node,
        lr_item TYPE REF TO cl_crm_aui_entity.

  CALL METHOD super->do_prepare_output
      iv_first_time = iv_first_time.

* We want to retrieve the current data EVERY time the screen is opened, 
* to avoid showing lines that have already been processed.

  DATA: lr_controller TYPE REF TO cl_iccmp_in_bspwdcomponen_impl,
        lr_context TYPE REF TO cl_iccmp_in_bspwdcomponen_ctxt,
        lr_search TYPE REF TO cl_iccmp_in_bspwdcomponen_cn00,
        lr_collection_wrapper TYPE REF TO cl_bsp_wd_collection_wrapper,
        lr_bol_access TYPE REF TO if_bol_bo_property_access,
        lr_query_service TYPE REF TO cl_crm_aui_advquery_service,
        lr_result TYPE REF TO if_bol_bo_col.

      lr_controller ?= me->comp_controller.
      lr_context ?= lr_controller->typed_context.
      lr_search ?= lr_context->search.
      lr_collection_wrapper ?= lr_search->get_collection_wrapper( ).
      lr_bol_access = lr_collection_wrapper->get_first( ).
      lr_query_service ?= lr_bol_access.
      lr_result ?= lr_query_service->get_query_result( ).
    CATCH cx_sy_move_cast_error.
* set result to custom controller
      typed_context->items->set_collection( collection = lr_result ).
    CATCH: cx_bol_exception, cx_root.

  LOOP AT typed_context->items->node_tab INTO lr_node.
    lr_mixed_ent ?= typed_context->items->get_bo( lr_node-node_key ).
    lr_item ?= lr_mixed_ent->if_bsp_wd_ext_property_access~get_model_node( ).

  READ TABLE typed_context->items->selection_tab INTO lv_index INDEX 1.
  IF lv_index < 0. "No line selected yet.
*  if iv_first_time is not INITIAL.
    typed_context->items->refresh( ).
      CALL METHOD eh_onitemnext.
    typed_context->items->build_table( ).

Automatic Next Item Determination
This one was easy. You might have noticed that in one of the last rows of the coding above, the method 'eh_onitemnext' is called. This method determines thre next available item to be processed. Combined with the typed_context->items->build_table( ). that follows it, the table is also re-built.

No automatic return to the Inbox
In order to return to the inbox when the agent has pressed the 'end contact' button, an IDI rule can be implemented, that if the CURRENTINBOXITEM in the GDC is bound, the system should navigate to the inbox. As there is no standard attribute in the IDI concerning the CURRENTINBOXITEM from the GDC, you will have to create one as described here.
Of course, you will have to add some other coding in the fact gathering class.
You can for instance determine the processtype of the currentinboxitem (so you can make rules based on whether a serviceticket or contactlog or service order has been processed if you want to).

*get current inboxitem

      lv_string = lo_bdc->get_entity_attribute_as_string( path = '//CURRENTINBOXITEM/BTOrderHeader/PROCESS_TYPE'
                                          iv_suppress_creation = abap_true ).
      CALL METHOD me->set_fb_attr_by_id
          id    = 'INBOX_TYPE'
          value = lv_string.
    CATCH cx_root.

So basically, with a few adjustments, the inbox can be a very user-friendly and efficient tool to process the backlog of items.

If you have any other requirements concerning the agent inbox, feel free to leave a message in the comments below :-).

Wednesday, October 13, 2010

Navigation based on the IDI

Call Center Agents can be supported by automatic navigation in the interaction Center. This is especially recommended to be implemented on the events BPConfirmed and InteractionEnded.

In the rule policy you can select the logical link you want to automatically navigate to. This can for instance be the customer overview, the factsheet, the IC Inbox or even some transaction outside of SAP CRM (for instance in the ERP system) using the transaction launcher.

Together with the creation of own events as described here, this can be a powerful enhancement of the IC. The navigation to logical links can be defined based on events and conditions such as country of the customer, postal code etc.

The IDI rules as well as the navigation targets can be maintained in the IC Manager role.

Wednesday, October 6, 2010

Alerts in the header of the IC Webclient

Call Center Agents can be supported by alerts that appear in the header of the interaction Center.

SAP has implemented some alerts standard available in the system. A nice one is the FICAALERTACCOUNTWITHMANYCONTACTS. This alert counts the number of interaction records in the last 30 days, and displays this. In combination with a check on the number of calls in the last 30 days in the rule policy, this can be valuable. You can for instance implement that when the customer has more then 5 interaction records in the last month, the alert will pop up.

The Alerts can be triggered using the Intent Driven Interaction Rule policy as described here.

If you want to implement your own alert, you can do so by logging on to the CRM system using the IC_MANAGER business role and selecting Process Modeling --> Alerts. Here you can find all SAP standard Alerts and create your own.

You will notice that you have a predefined set of dynamic attributes to your disposal.

If you want to add attributes to the list, this can be done in customizing en ABAP programming.

Customizing extra attributes cen be done in the IMG in:
  • Customer Relationship Management
    • E-mail Response Management System
      • Define Repository
In the contexts, choose ICRULE and double-click Attributes in the left side of the screen.
Now add your (Z-) attribute.
Important when creating a new attribute is that you use a new 'fact gathering Service'. For instance ZFG_IC_BP to retrieve more Business Partner attributes.

Now in customizing, add the new Fact Gathering Service in

  • Customer Relationship Management
    • E-mail Response Management System
      • Service Manager
        • Define Services
The Fact Gathering Service should have a Z-class as service class, This Z-class should be a subclass of CL_CRM_SMF_ABSTRACT_SERVICE.

In this class, implement method IF_CRM_SMF_SERVICE~EXECUTE.

Add coding to retrieve information. For instance:

* Get current customer
*     bp number
      CLEAR lv_string.

      lv_string = lo_bdc->get_entity_attribute_as_string( path =
                      iv_suppress_creation = abap_true ).

    CALL METHOD me->set_fb_attr_by_id
          id    = 'BP_NUMBER'
          value = lv_string.

    CATCH cx_root.

Now last but not least, add your own fact gathering service to the service manager profile you have created (or create one and assign it to the business role) in customizing:

  • Customer Relationship Management
    • E-mail Response Management System
      • Service Manager
        • Define Service Manager Profiles
Add your own Service in the list. Make sure it is not in the end, as you want to gather the facts BEFORE calling alerts.
You will now be able to add the newly created attributes both to Alerts as well as to conditions in the IDI maintenance in the IC Manager Role.

As the fact gathering services will be called frequently when in use, stick to efficient BOL programming in fact gathering services as much as possible.