Who they are

They run a software platform for the hospitality industry. One of the features of their platform is letting their customers order everything they need through a single source of truth, rather than going supplier by supplier to place each order themselves.

Where a supplier can be connected to, the platform places the order directly. Plenty of suppliers can't be, so those orders still get placed by hand on the supplier's own portal. Every new customer they win adds more of them. The ordering grows with the business.

The work, as it actually happened

One person on the operations team placed those orders by hand. Every order that couldn't go through the platform automatically landed on their desk, and they logged into each supplier's portal, one at a time, and entered it. Today that route carries roughly £40,000 of orders a month.

The suppliers' portals are mostly legacy systems with no API, so there was no shortcut. Someone signs in, finds the products, builds the basket, places the order. Then does it again on the next portal, for the next order.

No single order was hard. The difficulty was that all of it sat on one person, and it got heavier with every customer they signed. More customers meant more revenue and more manual ordering, and all of it depended on one person being at their desk.

Why it hadn't been fixed already

This was treated as an operations problem rather than a product problem, and that is why it stayed manual. The engineering team's time goes to the product their customers pay for, and rightly so. Internal ordering was never going to win a sprint against that, however much it needed doing.

Off-the-shelf tools don't reach it either. Other automation platforms are fine when there's an API waiting at the other end. Here there isn't one. Placing these orders means driving the supplier's own portal the way a person would, signing in and clicking through it, and that kind of browser automation is hard to build, expensive to run and prone to breaking. So nothing off the shelf solved it, and paying a person stayed cheaper than trying to fix it.

What we did

We watched the real work. We recorded the ordering exactly as their team did it, portal by portal, rather than working from a written spec of how it was supposed to go.

We built it around browser automation. These portals have no API, so there was no other way in. Rivulo drives the supplier portals directly, signing in and placing each order the way the ops person did. Handling the logins reliably across a range of legacy portals was one of the harder parts, and one of the most important to get right.

We designed around the exceptions. The one that mattered most: an order should never be placed, and money should never be committed, without a person signing it off. So we built a human-in-the-loop “Check With Me” step. The automation prepares the order and pauses for the ops team to approve the spend before anything is submitted. We also built a QA layer that runs an automated check on every order before it completes, comparing the basket it has built against the original order, so a mistake gets caught rather than sent to a supplier.

Browser agents can make mistakes, much as a person entering an order can. We don't claim the automation is more accurate than your team. What the “Check With Me” approval and the QA check give you is control: a person still signs off the spend, and every basket is checked before it goes.

We run it. This is a managed service. Rivulo monitors the runs, QA-checks the output and updates the workflows as the portals change, so it keeps working instead of failing unnoticed.

The outcome

The number. Around nine working days a month, handed back: close to two full days of someone's week, every week. The basis: over the last month there were roughly 360 workflow runs across 25 live workflows. We asked the team to estimate how long each of those orders would have taken a person to place by hand; totalled up, it comes to about nine days of work a month that no longer needs doing.

The second-order effect. They can take on more customers without adding a person to place the orders. Ordering used to scale with headcount. It doesn't now.

Proof it's still running. We've been running it with them for about a year, and it's grown from the first workflow to 25 live today, placing on the order of £40,000 of orders a month. They've been our design partner throughout, which means the browser automation, the login handling, the “Check With Me” approvals and the QA checks were all built and improved underneath them as we went, without them having to upgrade anything.

What's next

More suppliers, more volume, without the bill scaling in step. Rivulo prices for the complexity of building a workflow, not for how many times it runs, so when their order volume through an existing workflow doubles, their cost doesn't. The economics run the opposite way to headcount: the more they push through what's already built, the cheaper each order gets to place. From here that means bringing more of their suppliers under automation, while the workflows already live absorb the growth.