Your Next POS Demo Should Use Your Own Data

Imagine you're watching a demonstration of a new POS system. The salesperson opens the reporting screen and you recognise everything on it. That's your Friday lunch service, those are the meal deals you introduced last month, and you know exactly why that refund happened. You've sat through demos before. For a long time they were built on a made-up café with a tidy menu, and although more providers now go to the trouble of loading realistic data into a working system, it's rarely yours. This one is different, because you can judge the answers. How does the system show a meal deal and its extras? Where does the refund appear? Can you compare your two sites the way you normally would?

That is an experience we're working towards at Databiite. The building blocks are in place, and while we turn them into something every business on our platform can use, we're happy to do it by hand. If you already share your trading with us and you're thinking of switching, tell us which systems are on your shortlist. We'll help you test them on your own data. This essay is about what that work involves, what we've learned so far, and why we've decided to do it in the open.

From a question to a test

In my previous essay I suggested that anyone choosing a POS provider should ask what happens to their history if they leave. It's the right question, but it's easy to answer with a promise. Of course you can export everything. A demo is where that promise could be tested, and it's a useful place to test it, because it comes before the contract rather than after it.

Here's how we picture it working. A provider gets in touch about a demonstration. The operator already shares their trading with Databiite, so they fill in a short request for a limited sample of it. Where we have a suitable mapping for that provider's system, we would prepare the sample in its format. Where we don't, we would supply it in a common format and let the provider work from that. The operator would receive a download link that expires after a while and share it with the provider, who downloads the sample and is responsible for loading it into its own system. Databiite doesn't write into the provider's system at any point.

That last step matters more than it might look. Sending a file doesn't prove that another system can use it. The provider may need to build an import, may not support some kind of historical record, or may have to explain which details it can't represent at all. I don't see any of those as failures of the idea. They're exactly the things an operator would want to find out before signing, and at the moment most people only find them out after they've gone live. A good demo wouldn't make a move painless, either. Hardware, contracts, training and setting up the new system all remain. What it offers is a way of looking at the data risk early, using something more solid than an assurance.

What it would take

Databiite already translates trading from different POS systems into one shape inside its own platform, so that it can be queried together. That works well for our own reporting. Handing information to someone else's system asks more of us. We have to describe exactly what is being passed over, how its parts relate to each other, and what a receiving system needs to understand, and our own reporting needs can't be the only thing shaping that description.

So we've started developing what we're calling the Databiite Exchange Schema, or DXS. A schema is a structured description of information: what a sale contains, how its lines relate to products, how payments and refunds are recorded, and which details are missing or unsupported. The idea is a hub with spokes. Each provider maps its information to and from one shared structure, instead of building a separate translation for every other provider. Ten providers translating directly between each other would need ninety one-way translations. Through a shared structure, they need twenty, one in and one out for each. It doesn't mean every system can accept everything, because receiving systems genuinely differ in what they can store. But those differences can at least be described in one place rather than rediscovered in every migration.

What we've learned so far

We've tested the idea by running trading from three providers through draft mappings: a day or two of real trading from two of them, and a day from a test café we set up on the third. That third provider joined through its own mapping alone, with no code written for any particular pair of providers. I find that encouraging, but I want to be clear about its size: three providers, a few days of trading, one of them from a test site, some known exceptions, and no receiving provider has yet imported a sample.

The more useful lesson was a warning. In one provider's data, products and modifiers are numbered from separate sequences, and some numbers appear in both. A sale line that looks up an item by its number alone can attach itself to the wrong thing, and nothing in the file would tell you. In the trading we tested, 26 modifiers shared a number with a product, and each one was a link that could quietly land on the wrong item. To picture the effect, if "extra cheese" happened to share a number with a burger, a report could count extra cheese as burgers. Every field would be filled and the file would look perfectly orderly.

That's why we test mappings against actual records rather than against a list of fields, and check that the figures reconcile, so that the lines add up to the takings, basket by basket. A checklist of populated columns can't tell you whether the information survived the journey. It's also why I've become wary of the word "compatible" without a purpose attached. A system might hold enough for a sales demo and still lack the details needed to move a whole catalogue across, and operators and providers both need to be able to see where that line falls.

Why build it in the open

I mentioned ImageNet in the first essay. Reading more about how it was put together is what changed the direction of this work. ImageNet didn't invent its own way of organising the world. It attached its images to an existing hierarchy of concepts, WordNet, and that shared structure let work done by one group be understood and built on by others.¹ We already had a unified model inside Databiite. The change wasn't in the model; it was in the question I asked of it. If we were going to describe sales, modifiers, refunds and discounts carefully enough for exchange, was there any good reason to keep that description to ourselves?

Construction suggests not. IFC, the open and vendor-neutral model for building information I worked with in my previous career, is exchanged by proprietary design software without any of those companies giving away their source code, their storage design or the interface that makes their product worth buying.² I'd expect hospitality providers to have concerns about intellectual property, as businesses in other industries I've worked in have had. My view is that a provider can describe a customer's trading in an agreed structure and still keep everything it has built around it: the speed, the reliability, the hardware and the experience its customers actually pay for.

Our intention is to publish DXS so that providers can understand and implement it without joining Databiite. That would include its definitions, its mapping rules and the checks a mapping has to pass. We haven't yet settled the licence, how it will be governed or where it will be published, so this is a direction rather than the announcement of a finished standard. Publishing it wouldn't make anyone's trading data public, either. The specification describes how information is organised, not whose information it is.

That raises a fair question for us as founders: if anyone can use the format, where is Databiite's advantage? I think we have to earn it through dependable integrations, mappings that have been tested against real trading, useful analysis, and the trust of the businesses whose information we handle. None of that comes from publishing a specification, and publishing one doesn't guarantee that anyone adopts it. If two providers one day use DXS to move an operator's history between them without Databiite in the middle, I'd count that as a success. We would still need to give that operator good reasons to use our platform.

What comes next

DXS is still a draft. It needs more testing, real experience from providers on the receiving end, and input from the people who would actually use it. Rather than disappear for a year and come back with a finished standard, I'd like to write up the work as it goes: what we test, what breaks, and what we change because of it. This is the first of those pieces.

If you're a provider and would like to see the draft as it develops, or to try a sample on the receiving end, we'd be glad to hear from you. There's something in it for providers too. Every provider trying to win a customer from another system has an interest in making the move less daunting, and showing an operator their own trading working properly could do more for that confidence than another slide about migration support.

If you're an operator, there's nothing to stop you asking the question yourself in the meantime. If a provider offers you a demo, ask whether they can show you some of your own trading in it. The answer will tell you a good deal about what would happen to your history if you switched, and the system that records your next five years should be able to show you something of the years you've already built.

Footnotes

1. ImageNet: About, describing its organisation around the WordNet hierarchy and human-annotated images. ↩

2. buildingSMART: Introduction to IFC, describing its open, vendor-neutral data model for information exchange. ↩