How we taught brick & mortar tills to go online

So1 set out to build an AI platform that offers promotion personalization in real-time. Personalization and real-time are two capabilities that we at So1 believed were crucial to making brick & mortar retail competitive with online. Personalization means the ability to offer consumers what they are interested in, and only what they are interested in at an attractive price. And in real-time means whenever the consumer interacts with any of a retailer’s communication channels, combining all knowledge currently available about the consumer, omitting any lengthy BI research and segmentation, as if the retailer knew their consumers personally.

Traditional till software and its discount and pricing modules, on the other hand, are very much built around the notion of segments (in some limited number) and discount campaigns (in some limited number), which are set up beforehand and then deployed to the individual points of sale. Early assessments showed us that we would both run into sizing issues (when personalizing down to the individual with billions of combinations in a set of product, price or discount rule, and person), and fail to meet the real-time requirements in a configuration update regime based on SW deployment.

The magic we had in mind requires a highly parallel cloud deployment, which I will come back to later. So1’s vision is to turbocharge brick & mortar retail. How? By answering the retailer’s most important question: what to offer my customer right now to get them to visit my store and buy more? Product recommendation as well as price optimization (determining the highest product price at which a consumer buys) is where So1 delivers the might of machine learning to grocers of all sizes. Consumers benefit, too, as they will see less offers which are much closer to their shopping habits. And finally the manufacturing industry can use the system for targeted offers as I will be explaining in the end.

Here is what So1 makes happen at the flick of a switch for either a retail category or a brand manager:

  • A new price promotion is issued including text and picture media for all channels
  • It will be distributed from that very moment on to the best-suited consumers at an individual price
  • The individual price will be charged at the checkout when a targeted consumer buys the product

Let’s unpack those bullet points. The first bullet sums up the process of determining all constraints for the promotion and the benefit. Most importantly, a GTIN-set to be promoted needs to be defined, as well as the business goal, such as “unit sales” or “revenue increase”. Each channel where the promotion should appear may have specific media (texts, pictures) associated with it. Also, the rules for discounting must be associated with the promotion, such as price range and other conditions. The second bullet is about distribution, which starts immediately once the promotion data has been submitted to our system. The promotion is shown with an individually-determined incentive using the on-demand media that are available (i.e. connected terminals, apps, check-out printers, newsletters). And the third bullet is about redemptions, which are possible at the till as soon as the first distribution has occurred; clearing of all the redemptions may be involved in this final bullet, too.

We see two fundamental differences between the So1 solution and the way traditional tills work with discounts (see above). Sizing is the first: our system can work with the whole product range. At any moment when incentives are to be created, our system can select just the right products at the right price to augment the shopper’s basket beyond her initial intent. In such an automatic campaign management regime, products may appear multiple times in different promotions, and neither the incentive type nor its value are fixed before a consumer is actually selected to receive an offer. Till discount engines are not built to deal with such a vast number of possibilities and checkout processing speed would drop unacceptably. Nor is it practical in terms of architecture to keep all discounts options in the till: the till’s discount base is designed to decide on applicable discounts at check-out time based on the current purchase. So1, on the other hand, selects specific offers before the shopping is done based on the full shopping history.

The second difference comes from real-time delivery. Traditional promotions are determined well in advance, before any applicable shopping trip happens. But So1 supports digital distribution channels, like delivering to an app or to in-store terminals. These channels, which the shopper can consult just before purchase, allow So1 to achieve the best upsell results. Distributing promotions in-store means in turn that the time between distribution and redemption can be very short; too short for promotion-rule transport to the till in a traditional method that is based on batch mode.

More about the solution…

The first architectural decision was to locate the logic for discount application in the So1 cloud. This enables the So1 system to compute all values relative to the redemption of a promotion offered to and redeemed by a consumer, and return fully-updated line items to the till. As I mentioned above, the system holds too many discount possibilities for it to be practical to store them in the till. When the So1 system instantiates a promotion for distribution, it also knows how the discount must be applied later to any eligible line item.

This is also the reason why traditional online wallet systems cannot be considered as building blocks in the solution. Online wallets are conceived around the notion of triggering existing till rules on a user, which we do not have in our more dynamic setting. We concluded that keeping discount configuration in our system in sync with a couple of other systems would be not feasible, and the risk to the user experience (inconvenience) if that sync did not work in certain cases would be too high.

What we wanted to do was to manipulate baskets at the line-item level during the checkout process. This represented a rather profound integration into a checkout system. Doing this meant that So1 needed a unified approach that would scale. As a startup, we did not want to commit too many resources to till integration because, for us, this is really “just” the execution part of our core ambition: being the world’s best AI targeting engine for grocery retail. Hence any specifics of a POS software system, in particular with regard to its rule system, had to be abstracted by our integration approach. And finally, we wanted the retailer to be in control of the integration; this is not part of So1’s IP. The till process is at the heart of a grocer’s business operation. Consequently, they needed to be in the driver’s seat when it comes to extending the till.

An interface we quickly identified as a candidate once we had these requirements in sight was POSlog. Mostly known for serialization of completed retail transactions for use in a data warehouse ETL process, it also comes with a WebServices wrapper for business-to-business integration, called Retail Transaction Interface, following an SOA approach. This makes the widely accepted serialization syntax suitable for online communication during a retail transaction. In addition to this, the fact that POSlog is curated by a cross-industry body means that the integration we offer does not lock any party into a proprietary feature. Beginning this year, POSlog and all other artefacts of the NRF ARTS XML effort are being managed by the Object Management Group.

The So1 service implements two methods from the Retail Transaction Interface, namely, total calculation and transaction finalization. Our service uses them to update the basket once before the consumer is asked to pay. It is worth mentioning that So1 receives only a token of the consumer, such as the loyalty card number, and is hence approved as an anonymous service by the German data privacy authorities. And using the consumer ID, all applicable discounts are retrieved by the So1 cloud. This updates the basket total once, just before payment. Updating the basket with each item scanned would be a conceivable improvement, but would not be feasible in all cases due to the network bandwidth required in each communication step.

“But what about offline?” you might be wondering. And, yes, we acknowledge that the So1 use case is one that will only work online. Much as the title of this blog post says, tills go online to dramatically extend their capabilities by leveraging So1’s superior AI. Pop-up tills in a special sales area will not work unless a LAN connection reaches them in addition to electricity. But there’s really no way around it: for grocery retail, keeping up with Amazon means that if you’re offline, then your business is down.

The good news is that the online communication produces no noticeable delays during the checkout process: one major retail software supplier implemented the So1 cloud at the request of one of our clients and processes a basket of typical size and with 3 discounts added by So1 in less than 250 ms. This includes network latencies up and down, all marshalling, and of course, the application of discounts by So1 (as well as their transformation into the till’s own data format) upon arrival of the cloud’s response!

More use cases

One additional capability we support is the distinction between price promotions issued by the retailer and money vouchers for promotions issued by manufacturers. While the former means an effective reduction of the sales price of the item, the latter is essentially a payment tender added during the payment phase of the till transaction. This differentiation allows grocers to rake in additional advertising budget by marketing So1’s system capabilities directly or indirectly to manufacturers as their own programmatic promotion channel.

The next use case which opens up thanks to a real-time integration into till and distribution channels is that of remnant sales. Excess stock, particularly on perishables, is of some concern for every store manager. Using the So1 system, any such excess stock can be set up as a campaign with just a few clicks, either at the store or centrally. The goods will then be marketed to shoppers to increase sales, while taking into account regular sales, until the excess is depleted just in time.

From here on forward

Implementing the So1 service into the tills is a work package of its own within a cooperation project. But it is not the most complex one. In one of our full-fledged integration projects, involving the till SW product of a major supplier, we measured only 6 weeks pure coding before a software update deployment was processing So1 online discounts at the lab. The universally known semantics of POSlog contribute to this impressive integration performance, as do special test environments provided by So1 to support the development and laboratory stages before production. But ultimately a smooth integration is most facilitated by clear-cut use cases in a service-oriented architecture. This removes the IT portions from the critical path of project management. And in the long run, SW maintenance and total cost of ownership is minimized, too.

In closing, I want to mention that one can clearly choose other routes to integration than SOA-style, particularly if the required capabilities of the solution deviate from the above or other constraints require it. One alternative is part of ECREBO’s portfolio: Ecrebo can connect the till to cloud intelligence where interface-based automation of the till software is not possible. What they do is basically hands-off to the retailer’s IT and the POS software provider. So1’s intelligent promotions cloud can be connected here, too.

Whichever route you choose, if you are a grocer and you want to start increasing your bottom line by intelligently offering the right products at the right price as if you knew your consumers personally, So1 delivers the AI you need.