A scratch ticket can be sold in seconds. The systems behind that sale are another story.
We’ve been building LottoShield for seven years, and we’ve come a long way. But much of that progress came from running into problems we couldn’t see at the beginning — and having to solve them one by one.
U.S. lotteries generated more than $109.3 billion in sales in fiscal 2025. Behind that scale is a surprisingly complicated retail category, where POS systems, state lottery data, inventory, cash, employee shifts, payouts, and reconciliation all have to line up.
Over the years, we’ve dealt with difficult hardware installs, legacy systems, unreliable integrations, and state-specific nuances that no manual could teach us.
Some challenges changed the product. Others changed how we think about customers, teamwork, focus, and building a company around a problem that keeps revealing new layers.
We spent close to a year developing the early product before taking it beyond stores operated by people we knew. Then, across two California convenience-retail events, roughly 40 stores signed up to try it.
That was the encouraging part.
The less glamorous part was installing it.
Our original hardware was an adapter that connected to the scanner already attached to the POS. We drove to each location, unplugged equipment, connected the adapter, configured scanners, and worked around whatever setup we found behind the counter.
There’s nothing like spending an afternoon on your knees behind a dusty register to show you whether a product truly fits a store.
The system worked, but the installation placed too much responsibility on the retailer. A tool designed to reduce manual work shouldn’t begin by giving the manager another complicated project.
We eventually replaced the adapter with a standalone lottery scanner. Stores no longer had to disconnect and reconfigure the equipment they were already using. That change made deployment much easier, and we ultimately shipped roughly 2,000 dedicated scanners before moving toward supported mobile devices and Android-based scanners.
The experience changed how we approached the product. Instead of asking how many capabilities we could add, we paid closer attention to every step a cashier or manager still had to complete.
At first glance, lottery inventory seems straightforward. You know what entered the store, subtract what sold, and confirm what remains.
In practice, each part of that equation may come from a different source.
The POS records sales. The state lottery system records its own activity. Pack information may be entered somewhere else. Shift records might live on paper or in another back-office module. When those numbers don’t match, the manager has to play detective.
Some early lottery-management products could track tickets but didn’t connect with POS data. Broader back-office platforms had POS information, yet their lottery modules could still require retailers to manually enter packs and other details.
With each of the existing solutions, there was still quite a lot of manual work required to use it.
The real gap wasn’t a lack of data. It was that no system we saw brought all of the important data together.
Lottery-specific tools could track inventory but often lacked POS integration, while broader back-office systems had POS data but still required retailers to manually enter lottery information because they weren’t connected to state lottery data.
That gave us a clear opportunity: connect inventory, POS, and state lottery data in one system, then use those integrations to remove as many manual steps as possible. The lesson was bigger than integration itself — if the customer still has to fill in the gaps by hand, you haven’t really automated the problem.
There’s nothing like spending an afternoon on your knees behind a dusty register to show you whether a product truly fits a store.
Convenience stores don’t operate in controlled environments. According to NACS, the average U.S. convenience store handled approximately1,484 transactions per day in 2025. At that pace, what looks smooth in a product demonstration can fall apart during a busy Tuesday afternoon.
Lottery makes that challenge even more interesting because there is no single national operating model. States have different games, procedures, data structures, and reporting requirements. A workflow that works neatly in one state may require a different approach somewhere else.
Then there are the POS systems. Many stores use older platforms with limited documentation, unusual configurations, and bugs of their own. State lottery systems can also return incomplete or inconsistent data. The job is not simply connecting those sources; it is making the combined result reliable.
There wasn’t a master guide that explained every scenario. Much of what we now know accumulated during the first four or five years through real customers, new-state launches, difficult integrations, and situations that nobody had documented particularly well.
After enough time, those unusual cases stop feeling unusual. They become part of what the product must handle — and part of what makes this category so difficult to solve. Every state brings its own nuances, edge cases, and undocumented lessons. There’s no playbook for many of them. You learn by being in the market, working with customers, and solving each new situation as it appears. That knowledge compounds over years, and it’s one of the hardest parts for any company trying to do this well.
Getting the data into one place solved one problem. It created another: helping retailers make sense of it.
A manager shouldn’t have to dig through several reports to find the issue that matters. The system needs to surface the most important exceptions, show the patterns behind them, and make it easy to drill down into the underlying activity. Otherwise, you have brought the data together without eliminating the investigative work.
That becomes even more important for retailers managing hundreds of stores. They cannot review every transaction or investigate every discrepancy individually. They need to quickly see which locations require attention, whether an issue is isolated or recurring, and where the problem likely began.
We learned that presenting the data wasn’t enough. The real challenge was turning it into something a retailer could quickly understand and act on.
Early on, positive feedback was encouraging, but behavior told us much more.
A retailer would pay for a full year rather than go month to month. Stores would use the system every day. Then customers began recommending it to other operators.
I call referrals the ultimate validation. Recommending business software isn’t like suggesting a restaurant. Someone is effectively willing to put their friend’s money on the line and say, “Trust me. This is good.” That carries more weight than a compliment after a demonstration.
As larger retailers adopted the platform, they also began measuring the operational impact themselves. H&S Energy reported a 95% reduction in lottery theft, manager audit-review time dropping from 45–60 minutes to about 10 minutes, and a 12x return on investment.
Those numbers were useful because they measured more than software usage. They showed what changed inside the operation: fewer losses, less time reviewing audits, and fewer hours spent chasing information across disconnected records.
That became a more practical way to judge progress. Were managers getting time back? Were shortages being caught sooner? Were employees doing less repetitive work? Those questions told us more than logins or feature counts ever could.
The biggest lesson is that familiar pain has a funny way of becoming invisible.
A 30-minute reconciliation becomes “how we’ve always done it.” A repeated shortage becomes part of the monthly routine. A manager moving numbers between reports feels normal because nobody remembers a version of the process that worked differently.
Retailers don’t need to replace every system or chase every new piece of technology. But it is worth walking through the lottery workflow and asking a few practical questions:
Where are employees entering or comparing the same data more than once?
How quickly can a manager narrow a shortage to a game, shift, or transaction?
Which report does the team trust when two systems disagree?
Which recurring workaround has quietly become part of the job?
Seven years ago, we thought we were building a better way to track scratch-ticket inventory. What we were really learning was how much work happens behind that count—and how many operational problems appear when the systems around it don’t agree.
For retailers, that is still the most useful place to look. Wherever employees are manually connecting systems, repeating the same investigation, or accepting a recurring gap as normal, there is probably a process worth fixing.