Lottery scratch tickets have always been a source of instant gratification or instant disappointment. At the Indiana State Lottery, Andrew Hendricks experienced the latter.
Hendricks arrived at the lottery in 2000 as sales director, with a mission to raise its profile with (and, consequently, sales to) the public. While he envisioned an overall effort of greater advertising and marketing, he faced a grim situation on the IT front as he tried to derive maximum value from those channels: 55 sales agents roaming the state, visiting 4,200 convenience stores and other lottery outlets, trying to calculate the best mix of games to sell—and not a single electronic tool among them.
Hendricks diplomatically described the lottery back then as "an undeveloped shop. ... Our sales force was not only not using e-mail of any kind, they were basically using pen and paper."
Facing fierce competition from other retailers that craved the lotterys space on store shelves, Hendricks knew he needed to bring his sales force online. The agency already operated a database to track which lottery games sold well; Hendricks simply had to give his sales agents tools to access that information at any time.
Why? More timely data would prevent popular games from selling out and less desirable games from taking up shelf space, and it would boost the "haul rate" of how often a sales agent visited an outlet. Historically, an agent might visit a client every two weeks. Hendricks said the Lottery Commission wants to reduce that time lag to several days.
"If we can see more people in a day," he explained, "that will translate into more sales." Annual lottery sales hit $750 million last year, with $470 million of that coming from scratch tickets.
As often happens with public-sector projects, the Indiana State Lottery (promoted as the "Hoosier Lottery" within the state) took several years to move forward. The Indianapolis-based agency did some preliminary experiments in 2002 and 2003 to determine which real-time tools would work best with its field agents. Last year, it struck a deal with Cole Systems Associates Inc., a systems integrator in New York, to install a real-time data distribution system and outfit Hendricks sales staff with tablet PCs to access that data.
Cole Systems designed a straightforward system: a Microsoft Corp. SQL server housed at lottery headquarters that pulls sales data as needed from the agencys main computer, an IBM AS/400. The Microsoft SQL server runs Coles OrderPad Enterprise application, which manages queries from sales agents and supplies them with the data they need in real time. Sales agents make their queries through an OrderPad client application on their tablet or a desktop PC if they happen to be at a lottery office.
According to Adam Perlow, Coles vice president for technology, the linchpin of the system was the ability to achieve timely downloads even with low bandwidth or poor connections. Lottery agents might tap into the database under all sorts of conditions: from a cellular phone while sitting in a car, via dial-up while eating breakfast or from a broadband connection at the office.
"Your bandwidth can be pretty good, or it can be pretty bad," Perlow said. "We wanted to ensure the sync would be successful even when the bandwidth was really bad."
The electronic brainpower behind that part of the system is PeerDirect, a database synchronization technology developed by Progress Software Corp., of Bedford, Mass. Progress has dabbled in real-time data synchronization for several years; PeerDirect allows more flexible slicing of data so that only the precise data sets necessary are sent to the user—meaning less data overall and better performance at lower bandwidth.
Users, Progress Vice President Kenneth Rugg said, "dont want to know whether theres a network there or not. They want to have a high-quality interaction with their application regardless of network connectivity."
During field tests of PeerDirect last year, Perlow said, users fired some "pretty intense" queries to OrderPad, yet PeerDirect still kept overall CPU usage at tolerable levels.
"During the evaluation, we saw that bandwidth was always the bottleneck. That was important to us," Perlow said, because bandwidth can always be increased. "We didnt want the server to be the bottleneck."