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:
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 ).
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:
HTMLB_EVENT = HTMLB_EVENT
HTMLB_EVENT_EX = HTMLB_EVENT_EX.
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.
: <lv_status> type any,
<lv_process_type> type any.
TRY. controller_id = if_iccmp_global_controller_con=>cucobt ).
lr_cucobt ?= get_custom_controller(
IF lr_cucobt IS NOT BOUND.
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 ).
The coding checks on whether it concerns the interaction record process type, and will only escalate if the correct status is set.