Preoday × QikServe
Two ordering platforms brought together after QikServe acquired Preoday, with both estates live throughout and the customer carrying none of the cost.
- Client
- QikServe
- Role
- Head of Product Design
- Timeframe
- 2021–2022
- Sector
- Hospitality technology
- live estates kept serving throughout
- 2
- operator downtime during migration
- 0
Two products, one company
Acquisitions get told as commercial stories. Inside the product they are design problems: two ordering platforms, two codebases, overlapping features with different opinions, and customers on both sides who chose the product they already had and rather liked it.
QikServe acquired Preoday just before I arrived in June 2020, and the technologies were still two separate estates. Through 2021 and 2022 our team led the design side of bringing the two product lines together. Both platforms had to keep serving live operators throughout. There was no pause button and no quiet season to hide the work in.
The principle we actually worked to
We always managed things so that we took the burden. Never, ever the customer. If a feature was going away, if something was being migrated, our teams did the work. The customer never got turned off and never lost something.
We did it on a value basis. The team genuinely cared about hospitality and about operators, and the business needed its customers. So we did everything we could to keep and support them.
The map
One of the first things I did was draw the whole thing. Every screen, every experience, every function. The full architectural map, from the front end all the way to the back, every system and every hand-off, diagrammed. It was incredibly detailed work, and everything that came afterwards stood on top of it.
What overlapped, and what we did about it
Menu management was the biggest overlap. The kiosk had its own menu manager. The middleware had its own. Preoday had its own. And there was a fourth, an early prototype built for the middleware, which had more capability than any of the others.
We kept all of them. That is not the tidy answer and it is what happened. Resources were such that we did not have the time or the money to build the clean, re-platformed system we would have wanted. When Access acquired the business later, they added more menu managers to the picture rather than fewer.
Mobile ordering was the overlap we did resolve. Preoday had mobile deployments already in the field, and we migrated those onto ours, with the change communicated to customers ahead of time rather than after it.
The trade
Our ambition was always to consolidate further, because there was a lot of overlapping technology. What we did instead was evolve towards more products that were more highly specialised, and then use that to our advantage, including in how we talked to customers about it.
A merger that keeps four menu managers looks like a failure on a slide. In a business with no money and live operators depending on it, it was the right call.
Team and credits
Convergence was a whole-company project wearing a design badge.
- Design colleagues from both product lines, who merged patterns they had often built themselves, which takes a particular grace
- Engineering teams on both codebases, who carried the migration without dropping live service
- Product management, who sequenced the work around operator realities rather than internal tidiness
- Customer success, who carried the message out to customers and carried their reactions back to us
What it taught me
The merged experience became the foundation the later platform work stood on. It also taught me that the tidy answer and the right answer are often different, and that the discipline is being able to say which one you took and why.