≡ Menu

First Look – ServiceBench


I saw ServiceBench when I presented at the Warranty Chain Management Conference and got a chance to get a more detailed presentation just recently. ServiceBench is aimed at the Service Supply Chain and is now part of NEW (who also presented at the conference). The service supply chain is often very complex because of the number of entities that are involved (i.e. retailer, service provider, manufacturer, TPA) and consumers often find it hard to determine where to go for help or service. It can also be very hard to determine who is responsible for the cost of the repair.  Once you figure out that a service call is necessary then you have to select someone to do the service, find the parts, get the customer, servicer and parts all in the same place at the same time etc. Everyone is trying to improve customer service, reduce their costs and simplify the business process for service providers.

ServiceBench creates a data hub for this information for service, repair, delivery, warranty, extended warranty. ServiceBench is a single internet-based system with access to a common set of data. It is designed to resolve more problems on first call and provide better and more complete data. This is all based on a common platform for Service Management and delivers what they call  Service Intelligence across the products.

  • Service Call Management
    A subset of CRM call center functionality focused on service calls. Handles event capture, dispatch and ServiceLocator. Typically integrated with a major CRM system.
  • Field Service Management
    Contracts, surveys based on statistical model developed for each, territory management, coverage analysis etc.
  • Parts Management
    A lightweight product to make it easy to order parts from within the same portal. NEW is in the process of extending this to create a virtual inventory management product to handle shipping/ordering parts from one of several locations etc.
  • Claims Management
    The core product capturing registrations, claims, returns, payments. Claims is often the first module and drives adoption. Claims data is often the cleanest and most complete. As a result it drives a lot of analytics in the service supply chain.

I am not going to try and describe all the capabilities of ServiceBench but will focus on the analytics it provides – service analytics. All the transactional applications run on a common Oracle database. Lots of data is collected about service calls and service call / claim quality. Most customers are focused on a weekly analysis cycle when the collected data is transformed for analysis. Everything is customizable for a customer but typically customers focus on financial, performance and quality analysis. Performance analysis might include part or service provider performance for example. Analytics often cover fraud warnings, travel costs, labor costs, parts costs, claim trending and internal process improvement. Customers define KPIs and can see the trends across periods – percentage of claims with a bad address, for example. Dimensions for slicing are defined based on the customer’s data e.g. product line or geography. The whole environment is very warranty and service focused and can be localized to a specific role. Besides this general analysis there is also a move to support pay for performance in the service supply chain. Pay for performance can be complex in terms of how service providers are rewarded. Others, like NEW itself, route more work to high quality service providers, using the analysis to identify those service providers who should get more work. While customers are not typically changing behavior from analytics directly they are updating data and rules based on analytics – the beginnings of a true analytic feedback loop.

ServiceBench also collects business rules as part of the setup. Some rules are only changed by the administrators e.g. those to keep data clean. Customers can change some rules, particularly thresholds like time allowed to submit claims. ServiceBench uses a proprietary rules engine and some coding to provide this environment.

One of the most interesting things about talking with NEW/ServiceBench was listening to them describe the sequence of their customers. ServiceBench is always trying to help its customers optimize their service supply chain. Most have never had this of the robust data organized in a manner that enables decision making, before so they often spend the first couple of years just exploring and learning about their data for the first time. As they get familiar with their data they begin to react to trends and analysis. Ultimately ServiceBench/NEW would like to see customers use analytics to drive behavior but it takes times for a company to trust the analytics and move to exception only reporting, for instance, and most begin by reviewing everything.

As an example, fraud analysis involves lots of data. Rarely can one find or claim fraud with a few points of data among thousands of warranty claims. To find the needle in the haystack you need to highlight trends and outliers. For instance a trend which involves increasing use of bad or unrecognized addresses (per the USPS) on claims can be a leading indicator of fraudulent behavior.  However it also could be an indication of a contractor working in areas with a lot of new construction.  ServiceBench warns those entering an address that it is unrecognized by the USPS and it can be edited or entered anyway. ServiceBench keeps track of this and many other points of data. Analysis includes identifying high rates of re-submission, regularly requesting greater reimbursement amounts than are approved, high incidence of labor only claims etc. As this data is collected and analyzed it can also be compared to data collected in customer surveys to find correlating information such as customers reporting that no work was done. ServiceBench in currently testing a beta product that pulls claims suspected of fraud into a work queue automatically based on this kind of analysis – the beginning of fraud decision management.

Just as it takes companies time to get used to trusting the analytics, it takes time to get used to queuing too. Queues get used for approvals, claims review etc. Lots of these are based on the company’s own rules. ServiceBench aims at 93-97% auto adjudication for claims – they want customers to let the system make decisions and it takes customers a while to accept this too. Initially customers want to see everything, even the claims being auto-adjudicated, and only over time will they move to reviewing just the queues of items needing review.

ServiceBench is an interesting example of a product moving along the decision management maturity curve. It is using rules, but not yet really exposing all of them to business users to maintain themselves yet. They are integrating data and providing analytics, that their customers use to change their behavior, but the analytic feedback loop is not yet automatic. And their customers need to be led gradually to accept high rates of auto-adjudication and to trust analytics.