The goal of Predecessor analysis is to find all patterns of specific event combinations and break it down by the person/or resource who performed the first event to find the root cause of the subsequent patterns of specific event combinations.
Users can create a query block that defines the specific event combinations that they would like to filter to.
Then a user can select an attribute they would like to use as the root cause. This could be the day of the week, person, resource, or any other value.
This can then be viewed as a breakdown of the attributes broken down by frequency and users can then apply a filter based on these attributes.
In virtually all case management, ad-hoc processes, call centers, and similar environments, some decisions of the next step in the process are done by people or maybe even a machine. For example, a customer calls a phone company and explains his problem to the first-line support representative named John. John routes the call to Mary from billing.
Sometimes the process is misdirected. Mary was the wrong person to deal with it. So she returns the call back the first line support department, when a representative named Mark picks up, and then routes the call to Sam, who resolves the issue.
What we have is the process pattern:
PBX – Answer (John) – Route (John) – Return (Mary) – Route (Mark) – Resolve (Sam)
The questions we have that can be answered through Predecessor analysis are:
- How after does it happen?
- Who is the person who misroutes the calls most often?
- Is there a specific department that misroutes the calls most often?
- Could an automated answering service eliminate call routing and improve the customer experience?