COMPUTERIZED DISPATCH

CODES, LANDMARKS, AND NAMED BUILDINGS

by Don McCurdy

Recently, I had a discussion with a taxicab customer regarding the failure of a company to deliver a taxicab to a passenger at a major building. The passenger couldn't believe that the company wasn't able to find a library. That led me to ponder why exactly the company had such trouble dispatching cabs with its million dollar computer system.

Computerized dispatch offers some fine advances in speed and accuracy, but also offers some real service killers if you don't set it up properly. Let's look at a fairly simple trip from a speed and accuracy perspective.

In most cases voice radio requires a dispatcher that is familiar with the city. If you hand the dispatcher a piece of paper with a reasonable sized building on it the dispatcher should know know where it is.

Now, fast forward to your computerized system. You've dumbed down your staff to save money so you don't have to put up with obnoxious, high priced dispatchers. However, when a customer calls for a cab from a major building your new less experienced, less expensive operators don't have a clue where the address is. The computer requires an address so how do you go about teaching your new operator these addresses? The answer: "Codes, Landmarks, and Named Buildings".

An issue that crops up when you create "Codes, Landmarks, and Named Buildings" in your system is how you insert them into the system. Often, the staff that creates the "Codes, Landmarks, and Named Buildings" enters them in cabease. Cabease is the language that the voice dispatcher uses with veteran cab drivers when dispatching these trips.

A classic example of this is the IBM complex on Burnet road, in Austin Texas. On voice, the dispatcher simply gave the trip out as "flagpole", since the flag pole was the most common pickup point in the complex. The veteran drivers knew what it was and they would explain it to the less seasoned drivers as the need arose. Now comes the code for IBM, "flagpole".

Each new operator had to learn the "codes" for various locations which became a nightmare. It became a simple productivity issue for me to develop a naming convention that would allow operators to guess a code.

Naming Convention

A naming convention is simply a method of creating Codes, Landmarks, and Named Buildings that would allow an operator to learn the convention instead of the codes. I was amazed that the experienced operators complained that the new operators were catching on too quickly to what the experienced operators had to struggle to learn.

Most computer systems will pop up a list as you type in the code. An operator can then select the building from the list. All HEB supermarkets started with the letters HEB and were followed by the cross streets. If there were variations in how the customer asked for a cab at that location then all of the variations were put into the computer as codes. This sped up the call taking operation and made new operators productive in a more timely manner.

Named Streets

Along with "Codes, Landmarks, and Named Buildings" you should create a series of codes for major streets. South Congress, a major street in Austin, simply read "sc av". I put the street type on the code to allow for more codes with the same initials and, more importantly, streets with different street types (lane, circle, cove) and the same name. The object being to reduce the number of key strokes required to enter an address.

Keep it simple. For instance, North Lamar Boulevard became "nl bl". To sweeten the pot a little I made named buildings on North Lamar with codes that had nl after them. The HEB on North Lamar became "HEB nl". The code was simple, easy to guess and followed my naming convention.

Operator Training

Now that you've got all of your codes entered, it might be a good time to mention that your operators shouldn't depend exclusively on them to provide the customer location. Even though you have a code for the building that your operator thinks is the location of your customer it is best to train your operators to ask follow up questions.

By evaluating my statistics carefully I found that one of the best call takers I had, based on percentage of "no trips dispatched", was a former driver. He knew what questions to ask in order to determine specific locations. I attempted to train my other call takers to ask follow up questions that might ease the loading process for the driver and rider.

Database Refinement

Along with your "Codes, Landmarks, and Named Buildings" it is important to refine your database, especially if you have similarly named streets in adjacent cities.

The vast majority of streets are entered into the computer by the programmers in blocks. A block face in the street database may be entered as 300-498 which allows any address between those numbers to be entered as a valid address. A more accurate representation of addresses that actually exist might be two block faces that look like this: 300-306 and 400-400.

In the first example, 310 would work as a valid address even though it doesn't exist. In the second example, If the address is on a street in an adjacent suburb that has a 310 it would eliminate the possibility that the vehicle is sent to the wrong town. While this refinement is not mandatory to the operation of the system it reduces the opportunity for errors that adversely affect service to the rider and the driver.

There are many facets to operating a computer dispatch system successfully. In fact, there are several different opinions as to what exactly a successful operation is. For me, a successful operation is efficient and accurate dispatching. There's a bit more to a successful operation than entering a trip and zipping it off to cyberspace.

—dmc

© 2015 TLC Magazine Online, Inc.