Responder adds customers to a Callback list depending on specific user-defined criteria, then presents this list to the IVR or a customer service representative (CSR). Depending on the callback configuration, this list may be impacted by edits to incidents. The Callback List page describes which incident edits affect the callback list and how. You may configure how the callback list is generated by creating scenarios in the Miner.Responder.DataServices.exe.config file. You may create multiple scenarios.

By default, Callbacks generated when requested by the customer. You must configure callbacks in order to use them. Remove the tags that comment out the callback scenarios (<!-- and -->) in Miner.Responder.DataServices.exe.config file. Then replace the "none" value in the CurrentScenario attribute a CallbackEvent Name value.

Look for the <CallbackConfig> tag. The attributes within this tag contain connection information for handling customer callbacks.

General Callback Settings

These are the default settings. Any attributes set in the CallList tag will override a setting in the CallbackConfig tag. The line numbers correspond with the code sample below.

Line 2: The CurrentScenario attribute indicates the scenario to use. You may create multiple scenarios and indicate in this attribute which one to use. By default, three scenarios are provided:

• Default: Generates callbacks upon restoration, if requested by the customer.
• Critical: When an incident is created, generates callbacks for all critical customers regardless of whether they called or not.
• Verbose: Generates callbacks for 1) all critical customers when the incident restoration time is defined and 2) all critical customers and customers who called and requested a callback when the incident is restored. Residents of multi-customer load points (e.g., apartment buildings) receive callbacks if they called or if the dispatcher has checked them using the Select Affected Customers tool.
• Storm: Generates callbacks for all critical customers regardless of whether they called or not and all customers who requested a callback when the incident is restored. Residents of multi-customer load points (e.g., apartment buildings) receive callbacks if they called or if the dispatcher has checked them using the Select Affected Customers tool. 

  Multi-Customer Load Points: If the CallbackEvent is IncidentCreated, then all customers on the multi-customer load point receive callbacks assuming they meet any additional criteria (e.g., critical, priority). If the CallbackEvent is IncidentRestored, then only customers who called or were selected using the Select Affected Customers tool will receive callbacks.

Line 3: The CallUsing attribute lets you determine how the calls are handled, via IVR, CSR (customer service rep), or Both.

Line 4: When a call is attempted and failed due to a busy signal, the customer is returned to the callbacks list for a minimum period of time. The BusyWaitMinutes attribute lets you determine how long until the customer may be called again.

Line 5: When a call is attempted and failed due to no answer, the customer is returned to the callback list for a minimum period of time. The NoAnswerWaitMinutes attribute lets you determine how long until the customer may be called again.

Line 6: The MinCallAttempts attribute lets you set the minimum number of attempts for a customer callback. If the AutoDelete attribute is set to True, the customer will be automatically deleted from the callback list after the minumum number of attempts have taken place.

Line 7: Once the minimum number of attempts (MinCallAttempts) have been made to reach a customer, Responder may automatically remove them from the callback list. If the AutoDelete field is set to True, the customer is removed when the MinCallAttempts attribute value is reached using either the IVR and/or a CSR. If this attribute is set to False, the customer will not be removed from the callback list automatically, but may be removed manually using the Don't Call Again option on the Callbacks form.

Line 8: When an operator opens a callback, it is temporarily unavailable to all other operators. This ensures that two operators don't call the same customer. A callback remains unavailable to other operators (or "checked out") for a set amount of time. After this time expires, the callback is returned to the callback list. Use the MinutesCallingValid attribute to set the amount of time a callback is "checked out".

Line 9: If an outage lasts only a short period of time (blink outage), you may not want to generate callbacks. This attribute allows you to set the duration of a blink outage. Any outages that last less than the specified amount of time will not generate callbacks. In the example, the blink outage is set to one minute. Callbacks are not generated for any outages that last less than one minute.

Scenarios

Look for the <Scenarios> tag (Line 10). In this section, you may create various types of scenarios for different situations. The line numbers correspond with the code sample below.

Line 11: Indicate the name of your scenario. Use the value in the Name attribute to set the CurrentScenario (Line 2).

Line 13: Each Callback Event refers to an extension. We provide several samples with the Responder installation. The IncidentCreated callback event is used when the outage initially occurs. The IncidentRestoreTimeDefined event is used when an estimated power restoration time has been set. The IncidentRestoreTimeChange event is used when the estimated power restoration time has been modified. The IncidentRestored event is used when power has been restored. There are several values in the CallbackEvent tag:

• Name: This attribute has a unique name to identify the callback event.
• Type: This attribute defines the Responder extension object that will handle the Callback Event. Several examples are provided with the Responder installation: CallbackOnPowerOut, CallbackOnRestoreTimeDefined, CallbackOnRestoreTimeChange, and CallbackOnPowerRestored.
• CallReasonCode: This code corresponds with the text that appears in the Callback Reason field on the Callbacks form. 0=Power has been restored; 1=The estimated time to repair has been revised; 2=The estimated time to repair has been estimated; 3=A power outage has been reported; 4=A non-outage incident has been completed.

Line 14: The CallList tag allows you to determine which customers to call for each callback event and with what priority. There are several attributes in the CallList tag (not all are shown in the example below):

• WhoToCall (required): This attribute has three options: OnlyRequests, AllCallers, and AllAffected. OnlyRequests includes only customers who requested callbacks. AllCallers includes all customers who called regarding the outage. AllAffected includes all customers affected by the outage.
• Priority (required): This attribute indicates the priority given to the CallList. The higher the number, the higher the priority. In the example below, the Priority 1 calls will be attempted before the Priority 0 calls.
• Critical (optional): This attribute indicates the critical level. It corresponds with the Critical field in the RX_CUSTOMERS table. The settings in this table are customizable. The default settings are: 0=Non-Critical, 1=Residential Medical, 2=Public Utility, 3=Medical Care Facility, 4=Emergency Responder.
• CallUsing (optional): This attribute indicates whether the IVR, a CSR, or Both are used to contact customers with outage information. This field is case sensitive. Type the values as shown.
• BusyWaitMinutes (optional): When a call is attempted and failed due to a busy signal, the customer is returned to the callbacks list for a minimum period of time. The BusyWaitMinutes attribute lets you determine how long until the customer may be called again. If set, this attribute value overrides the attribute in the CallbackConfig tag.
• NoAnswerWaitMinutes (optional): When a call is attempted and failed due to no answer, the customer is returned to the callback list for a minimum period of time. The NoAnswerWaitMinutes attribute lets you determine how long until the customer may be called again. If set, this attribute value overrides the attribute in the CallbackConfig tag.
• MinCallAttempts (optional): The MinCallAttempts attribute lets you set the minimum number of attempts for a customer callback. When this number of attempts has been reached, the Delete Callback button is enabled on the Callbacks form and the CSR may choose to delete the customer from the callback list. If the AutoDelete attribute is set to True, the customer will be automatically deleted from the callback list. If set, this attribute value overrides the attribute in the CallbackConfig tag.
• AutoDelete (optional): Once the minimum number of attempts (MinCallAttempts) have been made to reach a customer, Responder may automatically remove them from the callback list. If the AutoDelete field is set to True, the customer is removed when the MinCallAttempts attribute value is reached using either the IVR and/or a CSR. If this attribute is set to False, the customer will not be removed from the callback list automatically, but may be removed manually using the Don't Call Again button on the Callbacks form. If set, this attribute value overrides the attribute in the CallbackConfig tag.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<CallbackConfig
  CurrentScenario="default" 
  CallUsing="CSR"
  BusyWaitMinutes="10"
  NoAnswerWaitMinutes="12"
  MinCallAttempts="3"
  AutoDelete="false" 
  MinutesCallingValid="15"
  BlinkMinutes="1">
  <Scenarios>
    <Scenario Name="default">
      <CallbackEvents>
        <CallbackEvent Name="IncidentRestored" Type="Miner.Responder.Processors.Callback.CallbackOnPowerRestored" CallReasonCode="0">
          <CallList WhoToCall="OnlyRequests" Priority="0"/>
        </CallbackEvent>
      </CallbackEvents>
    </Scenario>
  </Scenarios>
</CallbackConfig>

Send Comment to ArcFMdocumentation@schneider-electric.com