Cordell Supplies is the kind of business where operations run on institutional memory and improvised spreadsheets. They distribute specialist cleaning and facilities equipment to commercial clients across the South West of England, and for most of their existence, that has worked fine. The problems show up in the edge cases. Returns are an edge case that happens every single week.
When I spoke with their operations director, Marcus Prideaux, he had a very clear picture of exactly where the process broke. "A return comes in, and it touches four different places before we close it out," he told me. "The customer portal, our inventory system, the accounts system for the credit note, and then a follow-up email to the customer. Every step was someone manually copying information from the last system into the next one."
That was not the worst part. The worst part was that the person doing the copying changed depending on who was in the office. There was no single owner, which meant no consistent timing, and the occasional credit note that got issued twice because two people had both seen the open return and acted on it independently.
What the process actually looked like before
Before I describe what changed, it is worth being precise about what "manual" meant here, because it was not just inefficient — it was structurally fragile. Here is the sequence Marcus described:
A return request would arrive via email or their customer portal and land in a shared inbox. Someone on the ops team would open the portal, confirm the return request, then copy the order reference, the item codes, and the return reason into a row in their inventory management system to log the expected incoming stock. Then they would open the accounts system and raise a credit note, copying the same order reference and line items across again. Finally, they would compose a confirmation email to the customer, confirming receipt of the return request and the expected credit timeline.
Four manual transitions. Each one was a moment where something could be entered incorrectly, missed, or duplicated. The team had developed a colour-coded spreadsheet to track which steps had been completed for each return — a tracking system for a process that should not have needed tracking.
What Agenno was asked to do
Marcus's team came to Agenno through a recommendation from another Bristol-based distribution business. His first instinct, he admitted, was scepticism. "I assumed we'd need a developer to set anything up. Our IT person is part-time and we didn't want to create a dependency."
The description he gave Agenno was close to what he told me: when a return is confirmed in the customer portal, update the inventory system with the return details, create a credit note in the accounts system, and send the customer a confirmation email.
What he did not expect was that the plain-English description would be enough. "I kept waiting for it to ask me for a webhook URL or an API key, and it just... didn't. It asked which accounts system we use, which was Xero, and it already knew how to connect to it."
The setup took about two hours, which included time spent clarifying what "confirmed" meant in their portal's context — specifically, the status field Agenno should watch for. That was the most technical conversation Marcus had that afternoon, and it amounted to: "The status changes to 'Approved'. That is when you should trigger."
The part we should be honest about
We are not saying this was instantaneous or that nothing went wrong in the first week. There was one evening where a return came in with an unusual item code format that their inventory system rejected, and the automation flagged it rather than proceeding silently. Marcus had to handle that one manually. But — and this is important — he knew about it immediately because Agenno surfaced the failure in the run log rather than dropping the record.
Previously, a stuck return might have sat in the shared inbox for three days before anyone noticed. With the automation in place, Marcus got a notification within the hour. The failure rate was lower, and the visibility into failures was dramatically higher. Those two things together changed what "managing the process" meant for the team.
He also noted that the credit-note-created-twice problem disappeared entirely. Because the automation was the only thing that could trigger the credit note creation, and it only ran once per return confirmation, the duplication vector was removed structurally rather than by asking people to be more careful.
Six weeks later
When I spoke with Marcus again six weeks after they went live, the returns automation was running reliably and the tracking spreadsheet had been archived. They had started describing a second process to Agenno: their weekly stock replenishment request, which had a similar multi-system copy-paste pattern.
"The thing that changed how I think about it," he said, "is that I stopped thinking of automation as something you commission from IT and started thinking of it as something the operations team can just do. The bottleneck was never the technology. It was that describing a process in plain English is something my team can do, and writing a webhook integration is not."
That sentence is probably the most direct articulation of what we are trying to build at Agenno. The knowledge of how the process works lives with the people running it, not with developers. The gap has always been translation — from process knowledge to executable logic. Our job is to close that gap.
What translated and what did not
It is worth noting what Cordell's returns process had going for it that made it a good first automation candidate. The trigger was clear and discrete: a status change in a single system. The actions were deterministic: always update inventory, always create a credit note, always send an email. There were no branching conditions that required judgment — no "if the return value is over £500, escalate to the account manager" logic.
Most companies have at least a handful of processes that fit this pattern. They are the ones that get done reliably when the right person is in the office and slip when they are not. They are the ones where you have built a tracking spreadsheet specifically because you do not trust the process to run itself.
The second process Marcus's team described — the replenishment request — had more conditional logic, and the Agenno description took longer to get right. That is normal. Processes with human judgment baked in require more precision when you are describing them to an automation system. But the mode of interaction remained the same: describe what happens, refine the edge cases in plain language, run it.
The afternoon Cordell Supplies spent on their returns automation was the first time they had successfully automated a multi-system process without involving a developer. That is the benchmark we care about. Not "world-class" or "enterprise-grade" — just: did the ops team do it themselves? In this case, yes.