The Wireless Data Handbook, Fourth Edition James F DeRose Copyright © 1999 John Wiley & Sons, Inc ISBNs: 0-471-31651-2 (Hardback); 0-471-22458-8 (Electronic) 19 USER APPLICATIONS 19.1 VERTICAL VERSUS HORIZONTAL The trade press is rife with conventional wisdom reports on vertical versus horizontal markets ARDIS is known to focus only on the verticals because of its heritage and infrastructure limitations1 or its genetic differences.2 BSWD is thought to focus only on horizontals In reality, during 1996 roughly 90% of BSWDs revenues came from vertical applications.3 CDPD carriers work for the horizontal market with credit card processing4 or Smartphone plans, but sell in the verticals, especially public safety It is fair to say their focus is highly variable, with some exceptions: GTE is concentrating on vertical markets.5 Ironically, in 1995 ARDIS departed from its relatively successful vertical marketing strategy in a failed attempt to push Marco and Envoy for its then parent company, Motorola BSWD, having seen the light in 1994 with a series of E-mail failures, switched to a vertical approach with considerably more success It targeted five vertical markets6 (field service, field sales, transportation, utilities, and finance), relegating horizontals such as messaging and point-of-sale to secondary applications In late 1997 BSWD swung back to the horizontal market with a vengeance, staking the future of the business on two-way paging What these vertical/horizontal buzzwords mean? To most people a vertical is application specific: perhaps parts order entry from a mobile device transmitted upward to the same companys host computer for processing The applications are highly tailored since field service firms, for example, often see the intricacies of their particular part-stocking response as a competitive edge The applications are not generic and not transfer well from, say, high-technology medical/computer service to truck repair serviceor to public safety or field sales for that matter A horizontal 302 19.1 VERTICAL VERSUS HORIZONTAL 303 cuts across market segmentation boundaries with generic tasks: broadcast information such as financial or sports reports, credit card authorization, E-mail, or paging/messaging, for example ARDIS began life with a good hand-held device, strong field service experience, and a bias to take those two assets into a vertical market: field service The only radio modem alternative for the ARDIS laptop user was both external and expensive There were no extant wireless applications for the laptop It is true that messaging, a horizontal task, was well understood About a third of IBM traffic, which accounted for >90% of all ARDIS devices in 1990, was messaging (nonmailbox, intracompany) But IBM could not calculate displaceable costs based on messaging and neither could ARDIS The horizontal alternative was stifled So, too, was the attempt to provide fax servers. Customers clearly wanted true image fax, not cost justifiable on packet switched networks, and used cellular instead ARDIS began to focus more and more on the vertical markets, where it could make money BSWD became operational without a captive application Its initial orientation was horizontal, a notion that was continually reinforced by (then) executive management of Ericsson GE, which carried enormous weight with BSWD: E-mail applications will be a vital component of the Mobitex strategy theres likely to be faster and potentially greater payoff from concentrating on horizontal applications (because) the sales cycle is significantly shorter.7 BSWD created a rich array of business alliances, especially in E-mail, clear testimony to a horizontal drive But it was unable to make a successful business in those markets Gradually, BSWD stopped trying to make money on just E-mail/messaging alone and began having success in verticals: Field Service: GE Appliances, Hobart, Kodak, Olivetti, Unisys, Xerox Field Sales: Data Solutions, Pepsi-Allied/Pennsauken, Physicians Sales & Service, Ryckoff Sexton, Sysco Finance: Bank of America, CitiCorp, Home Savings, Morgan Stanley Transport: American Freightways, G.O.D., Merchants Home Delivery, Transmodal Trucking, Yellow Freight Utilities: Boston Edison, Florida Power, Illinois Power, Jacksonville Electric, Pacific Gas & Electric, Southwest Gas, Washington Natural Gas But the focus changed constantly ARDIS application profiles revealed that two-way messaging was critical to the functionality or economics of 20 out of 22 application profiles.8 E-mail (mailbox, intercompany) was not critical to the bread-and-butter field service application but began to appear more often as a critical requirement for field and insurance sales, financial services, lawyers, accountants, consultants, and executives/managers (many of these applications also require voice, a powerful lure for CDPD marketing personnel) The need was not lost on Motorola, who initially invested $2 million for a minority share in RadioMail,9 then converted its bridge loans to equity and gained a majority interest.10 ARDIS tried the horizontal track with RadioMail11 in September 1993, and 304 USER APPLICATIONS the Motorola PM100D ARDIS modems came packaged with RadioMail as standard ARDIS also announced its own PersonalMessaging12 service in March 1994 and made its prices more competitive the following October.13 But RadioMail failed in mid-1998, and the majority of new ARDIS success stories came from vertical applications such as United Parcel Service 19.2 VERTICAL APPLICATION EXAMPLES: FIELD SERVICE 19.2.1 IBM’s DCS IBMs field service dispatch history stretches back decades to pager-based systems (until ca 1984 IBM had the largest private paging system in the United States) Split into two service divisions in the 1970s, each division pursued alternatives to pure paging The first change came with voice pagers The field engineering (FE) division, after measuring thousands of dispatch calls, developed the dependable time profile shown in Figure 19-1 The sequence of actions was as follows: The customer called an IBM 800 number to connect to an agent at a dispatching center Using a custom application that identified customer, maintenance contract status, equipment location, and primary/secondary field service personneland listening to the customers problemthe agent made a voice page to the right service person (the primary service person could be on vacation, already on a call, or otherwise unavailable) When the service person got the beep, an average of 72 seconds was required to listen to the voice page The service person then required, on average, 120 seconds to find a phone (often a customer phone, not always appreciated) Dial time required an additional 10 seconds The ring/hold/talk time required, on average, another 136 seconds If the talking was to the dispatch agent in order to sell the call (reassign it because the Figure 19-1 Beep-to-complete field service dispatch via alpha paging 19.2 VERTICAL APPLICATION EXAMPLES: FIELD SERVICE 305 service person was already busy), there was inevitable time lost asking how the Cubs did last night On average, the service person was back at work in 60 additional seconds Total beep-to-complete time was thus 72 + 120 + 10 + 136 + 60 = 398 seconds Meanwhile the customer service (CS) division had been experimenting with portable terminals It had developed a small unit that altered the dispatch flow, as shown in Figure 19-2 The sequence of actions was now as follows: The voice pager was replaced with a simple tone pager (IBM tended to be antivoice) When the customer called, the agent filled in the trouble report on-line, then beeped the service person The service person took 120 seconds to find a phone Picking up the unit (3 seconds), plugging it into an RJ-11 jack (15 seconds), dialing the number (same 10 seconds), and handshaking with the dispatch host (2 seconds) came next for a total of 30 seconds The dispatch host then responded with the trouble report previously entered by the agent The read/response time was 25 seconds Next the terminal was unplugged (10 seconds) and put down (3 seconds) The service person was back at work in the same 60 seconds Total beep-to-complete time was thus 120 + 30 + 25 + 13 + 60 = 248 seconds: It took no rocket scientist to deduce that most of the 136 seconds spent in agent ring/hold/talk time vanished with approach Call it minutes It was clear that taking the dispatch via a data message would radically reduce the number of dispatch agents, their tubes, desks, even offices (some regional centers were closed in the subsequent consolidation) The next step was to go after the service representative time consumed by telephone search and dial The only answer was wireless; several in-house prototype units were built and tested They led to interesting business case discoveries: Figure 19-2 Beep-to-complete field service dispatch: page plus terminal 306 USER APPLICATIONS When the device beep occurred, the dispatch message was already present With a small unit the service representative could pick up the device in seconds Reading the message and keying the response to accept or sell the call took 14 seconds Putting the device down took additional seconds Now the beep-to-complete cycle had contracted to 20 seconds Automated dispatch was getting interesting Further, the system absolutely knew that the message had been delivered and could begin seeking alternative service personnel quickly if it had not been (there was always a time uncertainty with paging) Further, it was clear that two other pay-off areas existed: Parts Order Entry: Embraced not just ordering but also checking on the delivery status and changing priorities It was later expanded so that the field service representative could be told that the part sought was in, say, the city warehouse five blocks away Incident Reporting: Caused the failure source, its part number, and symptoms to be sent to a central file Summary reports were then sent to the responsible engineering group for early warning use Other areas could not be justified: Pure messaging, as noted in Section 19.1 The use of the portable wireless terminal as a plug-in diagnostic aid Building on years of steady application development, knowing which applications paid off, which did not, how rapidly the new system must come up, and counting on resale of the paging system (which happened), the DCS contract was signed in November 1981 A classic vertical system, it took on the form shown in Figure 19-3 The customer called in the trouble report to a regional dispatching center The dispatch agent posted the problem to the regional hosts The regional host paged the field service person of choice That is, it sent out the briefest are you there? inquiry to the last known location of the service representative The page was highly likely to get through because of its short length It also required no ACK, an application requirement that modified how the radio system functions The field representative receiving the inquiry responded with an I am here message This brief, manual ACK did two key things: It let the application system know that the selected service representative was available It let the data radio system know the received signal strength from the device Note that it would have been theoretically possible for the device to also report 19.2 Figure 19-3 VERTICAL APPLICATION EXAMPLES: FIELD SERVICE 307 Vertical application example: IBM field service the signal strength it had received from the base station This was not implemented The application system now responded with the full dispatch text to the radio system The radio system selected the best route, aided by signal strength indications from multiple base stations that had received the I am here message It thus delivered the full text with high (>90%) probability of success on the first attempt (error retries are the responsibility of the radio system; the application is unaware of any underlying messiness) A variety of things could happen next The most common was that the service representative took the call The time was posted back to the application and the customers trouble call updated on-line If the problem was complex or unfamiliar, there was often peer-to-peer messaging as the representative asked buddies if they had ever seen this problem If it was really bad, or the customer was livid, the representative might contact the field service manager for assistance When the trouble was corrected, the representative closed out the incident and possibly back ordered parts These messages arrived at the regional dispatch center 308 USER APPLICATIONS first; it realized they were intended for another system and forwarded them over the interconnected SNA links to the proper destination Built into the application, not the radio system, were contact scenarios If representative A had primary responsibility for the customer, and the radio system was unable to get a response in four tries, that fact was reported to the application A broader search pattern could be requested by the application (very rare) and the radio system would range outside home areas Typically the application logic decided that: This is not a burning problem (e.g., an annoying flicker on a PC screen) and will initiate a request for representative A every 1530 minutes People often like to eat in peace; the representative may have turned off the terminal After an hour the application program may revise its strategy to step 2 This problem cannot wait The radio system is instructed to find representative B Note that an underlying assumption of the system design is that the service representative is not wide ranging If someone does jump in the subway at Grand Central Station, cutting off communication, the reregistration message signals that they are once again reachable when they surface at Battery Park Ironically, the initial infrastructure design seemed to indicate that the system was intended to let the field service representative roam the nation IBM secured a common nationwide channel from the FCC, with some exceptions in areas abutting the Mexican and Canadian borders But the goal was far more pedestrian The hand-held devices weight/size/battery life targets were so stringent that Motorola was unable to include a synthesizer The KDT terminals had crystal cut oscillators Since IBM was concerned with spare stocking, matching devices to numerous possible city frequencies would have been a logistical nightmare; ergo, a common frequency Coverage requirements were plotted with great precision The nation was broken up into 2-kilometer zones and service representative populations were projected for each zone There are enormous population differences between Manhattan, New York, and Manhattan, Kansas It was thought that a significant number of service representatives would never receive radio coverage Thus, the KDT also had a 300-bps integrated modem standard, since it might be useful in a base-station-down situation The KDT was priced with and without radio transceiver As the roll-out proceeded, and as the base station reliability was measured, the decision was made to ship all KDTs with radio transceiver in place if only to minimize spare-parts-stocking problems In fact, radio coverage became ubiquitous, extending to the business areas of Alaska, Hawaii, and the Caribbean Field trials were held with the marketing divisions in an attempt to establish a business case for them Sales personnel loved to be notified when a customers mainframe had been down for hours with the problem not yet diagnosed They were able to speed over and reassure the customer that they were on top of the situation But a price value could not be placed on such information and the field trials were abandoned 19.2 VERTICAL APPLICATION EXAMPLES: FIELD SERVICE 309 New, cost justifiable applications could be envisioned However, they usually did not fit in the memory-constrained KDT800, and they were always extremely hard to develop There was also the usual risk of committing them to ROM when still unstable As the devices aged, IBM began to move away from the KDT It experimented with its own ThinkPAD laptops with integrated radio modems but settled on the I@P as a suitable substitute The day of the special-purpose, rugged hand-held radio unit is probably coming to a close, though, for example, Husky, Itronix, Melard, and Telxon would certainly dispute that conclusion 19.2.2 Pitney Bowes’ AIM Roughly five years after IBMs pioneering field service work, Pitney Bowes began to plow similar ground Like IBM, it had developed (1985) a mainframe-based field service system called ACESS: Automated Customer Support System This system was essentially telephone-based Service representatives called in at the end of the day to obtain the first call for the following day When they called in to report the job complete, they received their next dispatch Only special field service representatives were given pagers; thus the managers could not initiate calls to most of the staff Pitney Bowes knew that its customers disliked field service representatives using their phones In January 1990 ARDIS was announced; the two companies were working together by February The agonizing application specification, cost justification, and coverage tests consumed a year, without a contract in place Large-scale implementation took nearly another year Some mistakes were made, especially in terms of message volume and length This problem was compensated for by doubling the size of the front-end processors and a great deal of system optimization work at the hand-held device (the KDT840, a memory-enriched successor to the KDT800), including data compression and transmission of only changed data There were also registration problems, which were satisfactorily patched for Pitney Bowes but forced ARDIS to deal with its lack of automatic roaming By the beginning of 1993 more than 2800 users were on the system The payoff was clear14: Eighteen dispatch centers consolidate to six Dispatch agents were reduced by 60% There was a 5% increase in representative productivity (there were reductions in the number of representatives) And during this time, Pitney-Bowes machine inventory grew 4% There were also problems In spite of the fact that the KDT840 has considerably more memory than its predecessor, it was not enough Further, the lack of a synthesizer hurt Pitney Bowes, which had to stock spares with 10 different frequency allocations 310 USER APPLICATIONS Radio coverage patterns differed from IBMs so that dead spots existed Further, Pitney Bowes wanted multiple public airtime service providers to drive down airtime costs In spite of repeated coverage tests, no suitable replacement was found 19.2.3 Sears In 1985, Chicago-based Sears could see IBM technicians arriving at their locations after having been dispatched by DCS Plans were put in place for a Sears-specific effort, but the Motorola KDT terminal was ruled out as a device; a full-screen unit capable of 3270 emulation was sought In late 1990, after the announcement of ARDIS, IBM approached Sears with a partial answer: the PCRadio A disastrous emulation project was actually attempted but failed miserably In mid-1991 the decision was made to develop a wireless application from the ground up, which consumed nearly 18 months before the first pilot could be attempted at the close of 1992 A California test area was selected for the new pilot, not the least because the ARDIS coverage was good and would not plague the test with unwanted problems Another full year was spent redesigning work flow and writing the necessary application package As with IBM, justifiable applications were discovered and exploited This included up-to-the-minute information on parts and their prices By 1994 about 500 service technicians were gainfully using the applications But the IBM PCRadio was not adequate to the task Sears sent out RFPs for a new device Some were tested but found wanting Itronix developed the winning unit, the XC 6000: rugged, print capable, a better radio modem than on the IBM device By now it was late 1995 and the project was treading water A new, accelerated rollout plan was put in place with important delegation of responsibility, much of it to Itronix The first five months of 1996 were filled with intense activity as 5000 technicians went on the air via ARDIS in its areas of best coverage As the rollout picked up steam, Sears began running into geographic areas with inadequate coverage BSWD did not have the coverage either, but it had a fresh, inventive idea BSWD proposed a multiprotocol solution that had a key satellite dependency The satellite vendor was Norcom; AMSC (now ARDIS parent company) has a polled system and the 510-minute latency was completely unworkable for Sears Nettech replaced all the obsolete middleware with its own design; the new applications could operate with ARDIS or BSWD terrestrial and Norcom satellite By mid-1998 (13 years after inception) Sears had 12,000 technicians on this hybrid system: 7000 on ARDIS, 5000 on BSWD/Norcom In many areas of the country the Sears technician connects solely by satellite, there is simply no terrestrial coverage Note that satellite coverage is street-level only The device must be connected to a satellite antenna in the service vehicle 19.2.4 A Generic Approach The overriding message of the DCS, Pitney Bowes, and Sears examples is that vertical applications demand enormous planning, long development cycles, an understanding 19.2 VERTICAL APPLICATION EXAMPLES: FIELD SERVICE 311 of cost benefits, and a tailoring of the radio system and devices to meet the application needs It is no surprise that ARDIS chose to concentrate on field service as an initial application They understood the problems, many of the IBM/Motorola heritage staff having bled through DCS, and had a unique device with the integrated radio modem (KDT840) But the fastest sales cycle (this is EDS) required more than two years (see Table 19-1).15 This enormous up-front investment in each customer, accurately foreseen by the IBM participants in the first IBM/Motorola exploration of the airtime service business, is akin to having a business like selling clarinets Not a bad business, but not a big one either, because clarinets are too hard to learn to play (apologies to Paul Carroll).16 ARDIS resources were strained by the requirement to provide the end-to-end implementation services shown in Figure 19-4 It seemed clear that there would be no way to make the necessary investment to reach the small (