Escalate button in the Interaction Record

Pieter Rijlaarsdam, 08 September 2010

When working on inbound phonecalls or emails in an interaction center, it might occur that an agent cannot resolve the customer’s request immediately. The system requirement would now be that the customer’s request would be forwarded to a different department within the company. There are several ways to achieve this:

• Creating a ‘service ticket’ and forwarding this to another group

• Creating a ‘case’ and forwarding this to another group

• Enable forwarding of interaction records

Benefit of the first two options, is that these items are meant to be forwarded in the standard system.
Benefit of the last option is that you can keep all information together on one document, and forward this to departments throughout the company.

To support the forwarding of an item, you can enable the escalate button using a simple modification. After this modification, the functionality that is normally only available on service tickets, will now also become available on the interaction record. The contact log of the call can now, based on the context in the interaction record be escalated to different departments in the company. The routing is handled by routing rules in the rule modeler

In order to enable the escalate button in the interaction record, enhance class CL_ICCMP_BT_BSPWDCOMPONE6_IMPL method WD_USAGE_INITIALIZE, and add the following code:

If iv_usage->usage_name = ‘InrButtonBarId’.

lr_node ?= iv_usage->get_context_node( iv_cnode_name = ‘BUTTON’).

lv_button-id = ‘ROUTE’.

lv_button-enabled = abap_false.
lr_node->add_button( is_thtmlb_button = lv_button ).

Endif.

You will now see the escalate button in the interaction record screen as well. The button can be used to automatically assign an organisational unit to the interaction record as the responsible group.

You can also implement the automatic triggering of the escalation when the status of the interaction record has changed. This way, users do not have to click the button while they already changed the status of the interaction record from closed to open.

This can be implemented by enhancing the component ICCMP_BTSHEAD view BTSHeader, redefining the event EH_ONSTATUSCHANGE.

In the event, add the following coding:

call method super->EH_ONSTATUSCHANGE
EXPORTING
HTMLB_EVENT = HTMLB_EVENT
HTMLB_EVENT_EX = HTMLB_EVENT_EX.

data:
      lr_cucobt type ref to cl_iccmp_cucobt_impl,
      lr_btadminh type ref to if_bol_bo_property_access,
      lr_btstatush  type ref to if_bol_bo_property_access,
      dref       type ref to data.

FIELD-SYMBOLS:
<lv_status> type any,
<lv_process_type> type any.

TRY.
lr_cucobt ?= get_custom_controller(
controller_id = if_iccmp_global_controller_con=>cucobt ).
catch cx_root.
ENDTRY.

IF lr_cucobt IS NOT BOUND.
RETURN.
ENDIF.

lr_btadminH = typed_context->BTAdminH->collection_wrapper->get_current( ).

if lr_btadminH is bound.
dref = lr_btadminH->get_property( ‘PROCESS_TYPE‘ ).
ASSIGN dref->* to <lv_process_type>.
CHECK <lv_process_type> = ‘[your process type]‘.

lr_BTSTATUSH = typed_context->BTSTATUSH->collection_wrapper->get_current( ).
dref = lr_btstatusH->get_property( ‘ACT_STATUS‘ ).
assign dref->* to <lv_status> .
check <lv_status> = ‘[the E**** status]’.

lr_cucobt->route( ir_btorder = lr_btadminH ).
endif.

The coding checks on whether it concerns the interaction record process type, and will only escalate if the correct status is set.