Template for Success Stories from the Field

Event-driven Applications to Real-Time Business Intelligence and Business Performance

[This is the template for the usage scenario summaries (“application stories”) to be posted on thecomplex event processing and real-time intelligence website, An example of what the content should look like using anonymous company names is shownin italics below.]

Title: End-to-end Monitoringand Alerting for a Customer Onboarding Process

Company using the application: XYZ Cable

User company industry: Cable Communication Provider

Tool used: Anonymous Operational Intelligence Platform

Vendor of tool (and URL): Anonymous Software Inc. (

Applicationsummary: XYZ Cable, a cable communication provider, implemented a system to monitor its end-to-end customer onboardingbusiness process to ensure that each request for service will be fulfilled on schedule. The company receives more than a thousand customer requests for new cable service per day. The onboarding process involves creating or updating customer account and billing data, altering network configuration tables, and sometimes sending set-top boxes and routers, or performing on-site work by field service team to physically install wires and equipment. The monitoring system providescontinuous visibility into the end-to-end process and detectsmatters requiring attention, such as customer transactions (process instances) that are stuck at a particular step because of incorrect data,an application system that is down, or when a business partner hasn’t carried out the onsite work on schedule.

Input data (IT data, sensor data, other?):All of the input event data comes from 5 application systems that support 5 different steps in the onboarding process, including order entry, customer administration, network configuration, field service (from a third party contractor), and billing applications. The data are subset copies of EDI files and database update events(IT data) that occur within the applications. There is no sensor data in this application.

User dashboard (yes/no):Yes. Customer service agents and managers in the customer transaction department have graphical dashboards that displaydiagrams of the end to end process and traffic lights to monitor the health of each step of the process.

What is monitored (process metrics or other KPIs)? Mostly process metrics, but also application system status and health. Customer service agents can look up the status of any individual transaction and get alerts when follow-up is needed for a transaction. Managers have a different dashboard with summary data, including the number of transactions that have been completed today, the number of transactions that are pending at each step of the onboarding process and other metrics. Dashboards are updated every 5 minutes.

Alerts (yes/no/explain):Yes. Customer service agents get alerts through email for transactions that have not moved to the next step in the process more than 2 hours after the expected time to complete that step, or when a house call has slipped more than an hour past the promised time. Managers get alerts when a system in down or when more than 10 percent of transactions are missing the service level targets.

Responses to matters requiring attention (manual or automated?):Manual - problem resolution is always managed by a person, this system does not trigger any fully automated responses. The system has a workflow manager that coordinates the appropriate resolution process.

Project development effort: Thecustomer onboarding process took 4 developers 3 months to put into production. Additional processes (service disconnect, service reconnect, and termination) are expected to take about half as long each, but these are still under development.

Benefits: Improved customer service and reduced customer churn.Customer surveys indicate that satisfaction is higher than previously measured because the provisioning process is completed at the promised time in 95% of all cases, up from 85% in the past.XYZ Cable estimates that it is also saving 5% of the customer service agents’ time because there are fewer customer calls to ask about the status of their service request and to resolve complaints.

Lessons learned:

  • This operational intelligence application was noninvasive – it did not require changes to the existing application systems or the basic business process. It was an additional layer of monitoring oversight that was added on top of the existing applications without changing them. The event data required for end-to-end monitoring is captured from DBMS updates, not from custom code in the applications or application server logs.
  • There was no workflow or process orchestration tool actively driving the end-to-end process (although there is now for problem resolution processes).
  • Users (customer service agents and managers) didn’t want detailed updates on the flow of transactions within applications. They only wanted to monitor 8 major milestones in the process when the transaction crossed from one application to another or from one business department to another.
  • The operational dashboards were modified several times in the first month of production. The customer service agents originally got alerts when the system predicted that a customer service request would fail to complete by its promised date. An additional alert was added to notify the agent when the system detected that a house call was projected to be more than an hour late.
  • The management dashboard was also modified several times because the key performance indicators that were originally chosen were too low level and detailed. Managers did not want to see the details of individual overdue transactions unless they were projected to be more than two days late.

1