Tips on implementing an OTA call-logging system
Monday, June 12, 2006 10:48 AM
So you're ready to set up your new over-the-air (OTA) call-logging and assignment system. Your field force is spread across the whole country. All you need to do is decide upon a system to use and a set of procedures to follow, create a workflow and customize your software to accommodate it, and think of every eventuality and develop a plan to cover them all.
Then, you need to select your hardware, negotiate with a mobile telephony operator, choose the devices your field staff will use, arrange to train them, decide upon a go-live date, test, retest, and bug-fix the routines, complete your user acceptance testing, put a good support system in place, roll out the system, troubleshoot any unforeseen problems, and learn from all the mistakes.
Phew! Easy wasn't it?
With all this out of the way, you will now start to benefit from a quicker dispatch system. Your customers will benefit from better response times and will enjoy shorter downtime. Here's a look at some of the issues you must address before adopting an OTA system.
Timescales
First, as with any project, decide on the implementation
date and work back. Be clear about all the tasks that need to be completed and
what tasks depend on others being completed. Assign all the tasks to
appropriate people and make sure that they're comfortable with their
assignments.
Support structure
Make sure that all the users have quick access to a varied
level of support. Initially, a lot of handholding will be required, but that will
diminish as users get accustomed to things and as all the teething problems are
eliminated.
Also, you'll need to build a clear process for implementing changes to the system, because you won't get it right the first time. Be prepared to educate users about new procedures and to handle any issues that come up as changes are rolled out.
Communication
Communication is probably the single most important element.
It is vital that everyone involved knows what is expected of them and by when. All
end users need to be given a full set of the relevant documentation, clear and
practical instructions, and the opportunity to question anything they don't
fully understand. This may sound blindingly obvious, but I've been appalled at
the kind of oversights that are made with regard to communications.
The worst kinds of communication barriers occur when somebody assumes that information has been distributed by somebody else. It might be a good idea to appoint a member of the project team to have sole responsibility for recording all communications so that you can verify that each person involved has been informed of everything that is needed.
Equipment
The kit you issue to your workforce is critical, and you need
to get right. In our company, not all the field engineers are IT literate to
any high degree, so the unit needs to be simple to use. It also needs to be
robust. Ours are dragged around from call to call day in, day out. They get
shoved into pockets, dropped, placed in toolboxes among all the spiky stuff. They
get scratched and battered, and most of the connectors get damaged. My PDA is a
case in point. It's a Windows for Pocket PC based unit with a touch screen,
stylus, and built in Wi-Fi, Bluetooth, infrared, GSM,
and GPRS connectivity. The connection at the bottom is unprotected and doesn't work
anymore. Synching with my PC at home is no longer an option, as the connector
has become contaminated with pocket debris.
Backing up is, as you will all agree, a vital part of data integrity, so it's particularly awkward to be unable to do it. We've been live on a mobile solution since Feb. 6, 2006. This handset is my third! If I were to be involved in a similar project in the future I might consider spending a little more to get a more robust product. Although the bean counters like to prevent capital outlay, I think we could have saved a lot of money had we bought a better quality product. The initial expense would have been greater, but it's not viable to have engineers idle through unreliable equipment. When the PDA gives up, I am effectively out of communication.
Unfortunately, the unit also has a built-in camera with an operating button placed so that you press it every time you pick it up. You can reallocate the button to be used by another application, but that reassignment is lost every time you soft-reset the unit, and the button reverts to the camera. For a field force, simpler is better. A unit with a decent quality phone and a simple organizer function that can be linked to your host application via GPRS or a 3G (Third Generation) connection is all you need. Everything else can potentially get in the way and cloud the issue.
Checklist for choosing a PDA
Talk to your cell phone provider and ask them to suggest a
range of handsets that will fulfil your requirements. Get them to arrange some
trials so that you can encounter any problems first hand. Trying a few
different handsets will give a clearer understanding of operational advantages
and pitfalls. Whatever you do, don't take the first handset the operator offers
you. It may cost a bit more to get ruggedized PDAs
but they may well be worth the extra initial layout.
Think about:
- Battery life: Ours can't quite last the day without a top-up charge.
- Contacts database: It's important to keep a check on all your names and numbers, who they are and what they do. If your memory is as poor as mine, there's no substitute for making a note of everything.
- Unnecessary features: These include cameras, Web browsers, and so forth.
- Simplicity of operation: Sometimes details on the screen are too small to read.
- Protected connectors: The synchronizing connection on mine stopped working a month ago; I back up to an SD card now.
- Touch screen sensitivity: This can be a nuisance if you carry the phone in your pocket; can the screen be locked or covered?
- Network coverage/reception black spots: Some parts on my territory are very rural and I can be out of communication for hours at a time.
- Data download charges: Not a worry for the end user, but costs can mount up if you don't have the right deal with the network.
- Estimated data usage: Think how much data will be transferred and work out the cost; mobile networks charge by the megabyte.
- Ability to capture customer signature as a jpeg: This works well on our system, but some customers have expressed concern about it being stored and the possibility of it being used for fraudulent purposes.
- Ability to alter font size on display: This would be a good thing for those of us who are getting on in years! Ideally, you should be able to read the screen clearly at a range of distances and under variable light conditions. If the sun is shining and I am in my car, I can't read the screen.
- Hands-free capability, such as Bluetooth: These days this is a must; PDAs are not the most comfortable things to hold to the ear.
- Range of supporting accessories: These include car cradles, chargers, and extension antennas for weak reception areas.
- Durability: The PDA must be able to take a few knocks. It will be handled a great deal during a working day and will have to endure a wide range of working environments.
- Availability of replacement styli: Some of our engineers lose these as fast as they lose ballpoint pens. They're expensive to replace and people often use a pen instead, shortening the life of the screen.
- Availability of replacement batteries: With a short battery life, a spare is essential.
- Compatibility with hands free/Bluetooth kits: It's annoying to have to change the car kit every time the phone is upgraded. It's far better to buy a hands-free device that can still be used on other phones.
- Voice quality: There are too many communication barriers as it is; poor reception makes for mistakes and misunderstandings. Communication misses cost businesses several fortunes every year. If the line quality is poor, don't feel foolish about using the International Phonetic Alphabet to check that you have been understood.
Call assignment
The system used by my company references each call first by
location and then by engineer. We support a wide range of equipment and not every
engineer is qualified on every piece of machinery. It's therefore important to
ensure that the calls are filtered by location, engineer, and skill. As with
any system, the quality of the information loaded into it is the key to its
success.
Sometimes calls are assigned to me on equipment I don't work on. I then need to have the option to get the call reassigned to the correct engineer as quickly as possible. The system has to be able to determine whether the first-line engineer is available. If he or she is on vacation or attending a training course, the system must remove that person from the pool of available engineers.
Conclusion
There are many steps on the journey to automation, and they must all be taken purposefully and with attention to detail. As with any project, you want to stay on schedule--but it's more important to get it right. A day's delay to fix a problem is a price worth paying.
There are currently no comments for this post.