Controlling MV by phone Part 2

As a result of my recent blog on using telephones as an alternative user interface device, one of our clients requested phone access to their data. The first task is to allow sales reps and other authorized users to get inventory data by phone. The second task is to allow delivery people to send an order number, indicating they’re starting delivery, and to send another SMS later to indicate completion. These interfaces can be enhanced later to add much more functionality.

I’ll apologize up front that this isn’t one of my most articulate or succinct articles. I’m banging this out just to pass on some information. From here I need to get back to banging out some code.

Inventory Inquiry

For the inventory inquiry, a phone SMS request with a part# is processed through a web server, and from there to MV. For example, when “TG4321R” is sent, the following is received immediately:

Item: TG4321R
30AMP FUSED RAINTITE SWITCH
Last Cost: 82.23
Price: 98.99
Available: 386

(Data modified to avoid revealing actual cost/price)

That’s all there is to it. This isn’t supposed to be a new command-line interface, not a new GUI, not a new menu system to fit a phone-sized screen. It’s just a quick way for people to get fast access to basic data.

Delivery Status

The interface for delivery people allows the office to track what their people in the field are doing. Sending “12345” as an order number may seem very sparse and unhelpful, but a lot can come from this:

• We know who the driver is based on the incoming phone number.
• We know when they’re leaving for a specific location.
• Based on where they are and where they are going, we can link with Google Maps and produce an ETA.
• That ETA can be provided to the customer receiving the data, either by SMS or with an automated phone call that says something like “Your delivery from ABC Widgets is currently scheduled to arrive around 3pm”.
• After notifying the customer, and perhaps asking them “are you ready to receive your order”, we are in a position, if required, to immediately notify the driver to skip that delivery or maybe to delay for some period of time.
• When the driver completes that delivery and they enter a new order number, we have the starting location for the next destination.
• We also have the actual time it took to make the trip so that later checks at Google can be adjusted for an Estimated vs Actual ratio.
• The Estimated and Actual times can be used for scheduling of other deliveries, and this can help to compare drivers to ensure that some individuals aren’t taking significantly longer than others to make the same trip.
• At any time, someone in the office can run a report from a menu to find out exactly where people are, where they’re going, and perhaps to answer questions from customers like “when will my stuff be delivered”.

Of course we will probably not implement all of these other special features. Each change depends on the value the enhancement may hold for the company. What’s important for our purposes is that all of this is possible with people in the field simply texting one word. Significantly more is possible if people are texting just a bit more information.

For example, to keep each interface simple, we have two phone numbers, one that receives a part number and one that receives an order number. If we had one number for both, how could we tell the difference between Item# 12345 and Order# 12345? Well, as I said above, we can add another word to differentiate the function:

order 12345
inv 12345

A number of synonyms can easily be created to faciliate quick entry:

o 12345 = ord 12345 = delivery 12345 etc
i 12345 = inventory 12345 = item 12345 = part 12345 etc

Allowing users to perform different functions based on a combination of Command and Data is really just an exercise in string parsing. We could further distinguish the beginning and ending of an order using something like this:

start o 12345
done order 12345

or

12345 begin
12345 end

Since an inventory item has no start/begin or done/end, the presence of any of these words is a clue that we are talking about order delivery and not accepting a request for an inventory item. It should be evident at this point that we can process any text received, deduce what the user wants to do, and return a meaningful response.

Having a separate phone number for each command eliminates the need to parse commands to differentiate functionality. But do you really want a separate phone number for every function? How tough is it to get people to add two phone numbers to their address book, maybe labeling one “Inventory” and the other “Deliveries”? Each company needs to find the right balance of functions per phone number. This balance will be different depending on the audience. You might want one phone number with multiple functions for all employees, but a separate phone number for each function exposed to consumers. And – you may want to give your preferred customers their own phone numbers, exposing specific functionality, and make the back-end a little more intelligent to only offer information relevant to that customer for all inquiries.

I elaborate on the notion of Commands vs Data above because I frequently find myself in a development dilemma about making phone interfaces useful without making them too complex. Truck drivers are usually not techno geeks and someone might say these guys aren’t going to remember a lot of commands. The same could be said for sales people, people in the warehouse, or even customers using a new vendor phone service. If you think about it, that sort of gut reaction is rather insulting. The average person is capable of remembering a lot of details about a lot of different interfaces. These days the mobile phone is as familiar as a pencil, and people have no problem managing contact lists, texting, apps, downloads and even upgrades. People regularly text one another with terms like “how ru”, “brb”, “ttyl”, and other shortcuts that have significance to someone on the other end. Why is it any harder to remember to put “begin” in front of an order number? I think as soon as people start thinking of this as a computer function, a “rule”, or something technical, they glaze over as though it’s something outside of their experience. I think this temporary lapse into “I don’t get it, it’s too hard” mode will quickly disappear for anyone who is qualified to hold employment for any possible position. I think most people will face a slight bit of curiosity over the idea that their text messages are being processed as commands by software, but they should get over it within a few seconds or minutes. That’s the world we live in today. That’s why an SMS interface might not have worked ten years ago when I was first doing this stuff, but it might be ideal for today’s world.

With the success of inventory lookups, our client is now asking for the ability to run backups and other server macros which return data from the business server. They also want to customize the responses returned depending on who is making a request: Only some employees, and no customers, should see Cost data, and some customers may get better pricing than List. They’re also asking about outbound notifications – making phone calls to clients to advise them of order status, credit changes, price changes, and other details of interest or importance. As I code this functionality I’m going to extract the generic functionality into the “packaged” offering that I discussed in my previous blog.

As always, inquiries are welcome.