Introduction

Since the very early days of using computers, the question of how far we go in letting computers make decisions for us has played an important role. From business investment decisions, to airport traffic control, to medical diagnosis, to managing an inter-continental ballistic missile engagements. Many of these applications for computer decision-making are mission critical, with thin-to-no margins for error, regardless of who makes the decisions–computers or humans.

One of the key drivers for designing computers to make decisions is the need to achieve high performance consistently–that is to minimize dependence on the skills, experience and knowledge of a few good people. In other words computer decision-making aims to elevate all human decision makers to an expert level. Accordingly, the primary criterion for answering the question, “When do you allow computers to make decisions for you?” has been, “When these decisions are likely to be the right ones.” That is, when the computer makes decisions which are consistently at least as good as those of human experts.

But what has this got to do with customer relationship management? Surely the decision-making process for scheduling service calls is not as intense or critical as medical diagnosis or directing an ICBM. Still, the imperative to respond quickly and adequately to customers, compounded by the labor and logistics costs associated with scheduling and deploying service technicians, makes good scheduling decisions as critical to the long term viability of your organization as traffic direction is at the world’s busiest airports.

If you rely on computers to make decisions, you want to make sure they are going to make the right decisions–decisions which optimize your resource utilization, minimize your service cost and are consistent with your policy regarding service level agreements (SLAs).

Software Products for Service Decision Making

In the context of managing daily service operations, software products range between two extremes. On the one hand, you have products that offer solely data processing capabilities and do not make or recommend decisions. On the other hand, there are products that produce decisions automatically for a significant part of the business workflow. Consider, for example, a customer of a utility company who calls in with an issue.

Using a CRM (Customer Relationship Management) system, the call center agent will start by recording the problem, verifying the customer’s address, and the status of his contract. Depending on the information in the system, the agent may even wish the customer a happy birthday, if appropriate. These are traditional data processing activities with no decisions involved. Data is retrieved and recorded based on the dialogue between the agent and the customer.

The point for decision making comes when the customer asks, “When will you send someone to fix my problem?”. At this stage, a traditional CRM system may generate a list of time windows that may be offered to the customer. These time windows, however, take into consideration only limited aspects of the complexity of the decision.

They are primarily based on queries from databases looking for the technicians in the relevant geographic region, with the right skills, and for whom no more than a certain number of calls are assigned. They do not run an algorithm that addresses the full complexity of the problem and the multi-dimensional aspects of decision making for this problem. Let us elaborate on this point.

The challenge of decision-making in this context is far more complicated than it may first seem, because the customer in question is not the only customer interacting with the company at that moment. There may be hundreds or thousands of other customers who have already called or are likely to call today, all wanting service as soon as possible. And there are only so many technicians who can respond to these customer calls.

In order to effectively and efficiently assign and schedule these calls, the utility company needs to consider simultaneously a myriad of factors, including service level priorities, call urgency and possible technicians’ anticipated locations, as well as the customer’s location, drive time, overtime and a host of other parameters.

The company challenge is to manage the delicate balance and trade-off between minimizing travel (in order to maximize technician’s productivity), maximizing compliance with service level commitment, and minimizing other costs such as overtime cost. And all of this needs to happen in a matter of seconds while the customer is on the phone. Human-brain capabilities in this instance are obviously limited, and the benefits of computer-based decision making are clear. The question is will the computer’s decisions be of sufficient quality.

Not All Software Is Created Equal: The Travel Time Factor

While computers have the potential to be as good or better than their human operators with regard to decision-making, computer decisions can only be as good as the logic with which the machines have been programmed. For a computer to respond to the previously-stated challenge, a sophisticated algorithm is required for searching, analyzing, and scoring a huge number of possible combinations, and then selecting the best ones.

Not all software products make decisions in the same way, and the quality, cost and benefits of these decisions are greatly impacted by how the algorithms work. Most CRM products, for example, display options using only a small subset of the relevant factors. For instance, the travel between consecutive assignments is not properly considered when making these decisions.

Consider, for example, how different software applications integrate the geography and travel time factors into scheduling decisions. For a given set of customer calls, as the candidate technicians are identified, the software needs to calculate the best time estimate for traveling from the each technician’s previous location to a particular customer’s location, integrate this into the full route of the technician, re-consider the sequence of the technician’s previously-scheduled visits, and come up with the best selection of the assignment and the route.

Optimally implementing this process requires a sophisticated algorithm as a base, but the effectiveness of this algorithm is dependent upon the quality of its inputs. In this situation, the first fundamental challenge is to get the most accurate time estimates for traveling from point A to point B.

The best way to determine travel-time and distance calculations is to utilize detailed street level maps. (These are similar to the maps that are being used by Internet sites to produce driving directions from point A to destination B and are much more than just map displays used as a means to visualize geography.) Very few software products for service scheduling utilize street level databases in their decision-making logic.

Simplistic scheduling products estimate travel time using the “as the crow flies” (i.e. “line of sight,” “air distance”) travel time. Others use postal codes to determine the locations of technicians and customers. This process assumes that all entities in a given postal code are at the centroid of the area of the postal code and then uses the “line of sight” method for travel calculations.

Both techniques produce very poor estimates of the true travel time. Studies conducted with real service data have shown that, when using postal code geocoding, 21% of the tasks were not scheduled to the truly optimal technicians, when compared to street address level geocoding.

These inaccuracies limit a computer’s ability to schedule well at best, and create unreasonable routes at worst, especially in areas with bodies of water, dense metropolitan populations, or rural obstacles such as mountains. Figures 1 and 2 illustrate these points.

Looking at Figure 1, “line of sight” analysis would show that Technician A is fairly close to (let’s say about 1 mile from) Job X; certainly closer than technician B. The only problem is that the location of Job X is across the river which would make Technician A drive 3 miles up the river (potentially in heavy traffic) to the nearest bridge, cross the bridge, come down 3 to 4 miles to Job X.

On the other hand, Technician B would only have had to drive the 3-4 miles from his current location to the site for Job X. Assigning Technician A to job X is unacceptable. A software producing such routes even in 1 out of 20 cases will quickly lose credibility. Think about the dispatcher seeing it, or the technician driving it! In fact, because such extra travel is not factored in when making this scheduling decision, the decision is likely to cause delays for the subsequent calls for the day, possibly not leaving Technician A enough time to deliver his or her last call for the day, which leaves more unhappy customers complaining about the “cable guy syndrome”. The postal code method suffers from similar deficiencies as illustrated in Figure 2.

It is not a matter of just a higher monthly travel; it is a matter of credibility. Clearly, the schedule proposed based on “line of sight” has not made a decision that is at least as good as a human could make given the same information, and using computer decisions in this case may end up doing more harm than good.

Simplistic Scheduling Products will Not Make it in the Real World

A poor schedule impacts the daily life of every technician in the organization, as well as, of course, the company’s customers. No technician will remain quiet if the schedule makes him drive uptown, then downtown, then back uptown. Neither will he or she be happy if she is consistently finishing the day 80 miles away from home, when smarter assignments and routing could have prevented it. And how should a technician feel with software that schedules him with no time for a lunch break?

Similarly, angry “platinum level” customers will call the VP of Customer Service complaining they do not receive service according to their SLA. And when the VP Service stops by the dispatcher's desk to check, he quickly sees that better decisions could have been made. The dispatcher's response? "It is the software which is making these poor decisions. I do the best I can reversing its poor decisions, but you know how it is, you touch one place and you create a problem some place else; the domino effect...I probably would have done much better building it all from scratch the old way…"

Unlessdecisions are very good, schedulers will be manually shuffling the results of the computer with one change leading to another until eventually, after a few days, they will give up. Furthermore, users do not tolerate silly mistakes by computers. The moment that the algorithm commits silly mistakes is the beginning of the end for the algorithm. One silly mistake sets distrust of the computer’s decisions in the mind of the human operators, and that one mistake is remembered better than tens of good one.

In summary, if you are going to let computers make decisions, in this case automatic scheduling decisions, they’d better be of top quality; taking into consideration all the relevant factors that a human decision-maker would take under similar circumstances. “Good enough” is just not good enough.

ClickSoftware Inc.