Case Study
A UK dry fruit and nut importer running on spreadsheets and the memory of a few key staff moved onto one Odoo ERP, with custom dashboards and bespoke modules built around how the team already worked. Guesswork stock became real-time inventory they trust, and weekly hours lost to manual rekeying fell sharply.
14 min read By Deen Dayal Yadav, Founder & AI Automation Director
UK dry fruit and nut importer, GBP 1-5M turnover, 10-25 staff, single site
A UK dry fruit and nut importer running on spreadsheets and the memory of a few key staff moved onto one Odoo ERP, with custom dashboards and bespoke modules built around how the team already worked. Guesswork stock became real-time inventory they trust, and weekly hours lost to manual rekeying fell sharply.
A family-run importer and wholesaler of dry fruit and nuts approached Softomate with a problem common in food distribution but rarely solved well: the business had grown faster than its systems, and nobody in the building could give a straight answer to the simplest question in the trade, which is how much of any given product is actually in the warehouse right now. With turnover in the £1-5M band, between ten and twenty-five staff, and a single warehouse and office site, the company imported pallets of almonds, cashews, pistachios, walnuts, dried apricots, raisins, dates and a long tail of seasonal lines, then broke them down and sold on to independent retailers, caterers and other wholesalers. The commercial side was healthy. The operational spine holding it up was a stack of Excel spreadsheets and the knowledge in the heads of a few long-serving staff.
Stock levels were, in the owner's own words, an educated guess. There was a master spreadsheet that was meant to reflect what was in the racking, but it was updated by hand, usually a day or two behind the actual movement of goods, and only when someone had a spare moment to do it. By the time it was reconciled it was already wrong. The sales team would promise a customer a quantity of cashews based on what the sheet said, then discover at the point of picking that the real figure was lower, because a chunk had been allocated to another order that had not yet been written down, or because a pallet had been found damaged on arrival and quietly set aside. The opposite happened just as often: stock sat in the warehouse that nobody was actively selling because the sheet understated it, tying up cash in product that was edging towards its best-before date.
Dated and short-life stock is the part of this trade that punishes a weak system hardest. Dry fruit and nuts are not ambient goods that sit happily for years. Many lines carry a meaningful best-before window, and the value of a pallet falls as that date approaches. Without a system that knew the date profile of what was on the shelf, the warehouse could not reliably pick oldest stock first, so newer deliveries were sometimes shipped ahead of older ones, and the older stock aged out and had to be discounted heavily or written off. The business had no structured way to see, at a glance, which batches were closest to expiry and needed pushing. That intelligence existed only in the head of the warehouse manager, and only for the lines he happened to be thinking about.
Allergen handling added a layer that no spreadsheet was ever going to manage safely. Tree nuts are among the most serious allergens in food, and an importer handling almonds, cashews, pistachios and walnuts alongside dried fruit has a genuine duty to know exactly what came in, in which batch, from which supplier, and where every part of it went. If a supplier issued a recall, or a customer raised a complaint, the company needed to trace a specific batch backwards to its import and forwards to every customer who received any of it. On the spreadsheet system this was close to impossible. Batch information was recorded inconsistently, if at all, and reconstructing the chain of custody for a single lot would have meant a day of cross-referencing delivery notes, invoices and someone's memory.
The cost of imported stock was a second blind spot that quietly eroded margin. When a container arrived from overseas, the price on the supplier invoice was only part of the true landed cost. Freight, insurance, import duty, port handling and currency movement all added to what a pallet of pistachios had genuinely cost to get into the racking, and those figures often did not land until weeks after the goods themselves. The spreadsheets recorded the supplier price and little else, so the margin the sales team thought it was making on a line was frequently not the margin the business was actually making once the full landed cost was known. Pricing decisions were being taken on numbers that were comfortable rather than correct.
Underneath all of this sat the deeper structural risk, the one that worried the owner most when he was honest about it: the business ran on people, not systems. The warehouse manager knew the stock. The senior administrator knew the suppliers, the lead times and the quirks of the import paperwork. The owner knew the customers and the prices. None of it was written down in any retrievable form. When the senior administrator took a week of leave, purchasing slowed to a crawl because nobody else fully understood the ordering rhythm. When the warehouse manager was off, stock questions went unanswered. This is key-person dependency, and in a business of this size it is an existential exposure, because the knowledge that keeps the company running could walk out of the door with a single resignation or a single illness.
The day-to-day texture of the problem was relentless manual admin. The same numbers were typed over and over: a delivery would be written on a goods-in sheet, then rekeyed into the stock spreadsheet, then the related purchase figures keyed into the accounts package separately, then an order keyed into a sales sheet and rekeyed again when it was invoiced. Every rekey was a chance to fat-finger a figure, and every error then had to be hunted down later when something did not reconcile. The team was working hard and conscientiously, but a large share of that effort was being spent moving information between disconnected sheets rather than on anything that grew the business.
The owner had looked at off-the-shelf inventory software before and held back, for a reason that turned out to be central to the whole engagement. Every package he had seen wanted the business to change how it worked to fit the software. The team had developed its own way of organising stock, its own language for product lines, its own rhythm for purchasing against seasonal availability, and its own way of dealing with the particular customers who bought in unusual ways. The owner was clear that he did not want a system that forced his experienced team to abandon methods that genuinely worked, just to satisfy the assumptions of a generic product. He wanted the reliability of a real system without losing the practical knowledge baked into how his people already operated. That requirement, more than any single feature, is what shaped the brief he brought to Softomate.
Softomate started where every engagement of this kind should start, which is by watching and listening rather than installing anything. The first phase was a structured discovery carried out on site at the warehouse and office, sitting with the people who actually did the work. The aim was not to document an idealised process from a textbook but to capture how this specific business genuinely ran: how goods were received and checked, how a purchase was decided and placed, how stock was located and picked, how an order moved from enquiry to invoice, and crucially where the existing spreadsheets and tribal knowledge were doing real work that any new system would have to preserve. Every workaround the team had built was treated as a clue to a requirement, not as a bad habit to be stamped out.
The platform Softomate proposed was Odoo, and the reasoning was deliberate rather than a default preference. A dry fruit importer of this size needs inventory, purchasing, sales and accounting to sit in one connected system, and it needs that system to be genuinely adaptable, because the whole point of the engagement was to fit the software to the business rather than the other way round. Odoo's modular structure and its capacity for deep customisation made it the right fit: the standard modules would carry the bulk of the work, and the parts of the business that were genuinely particular could be handled with bespoke development on top, without forking away from a maintainable core. An entirely off-the-shelf product would have forced compromises the owner had already rejected, and a fully custom build from scratch would have been slower, costlier and harder to support. Odoo sat in the sensible middle.
The heart of the build was inventory, configured for the realities of food rather than left in its generic state. Softomate set up batch and lot tracking so that every intake of product carried its batch identity through the system, which is what makes genuine traceability possible. Expiry and best-before dates were captured against those batches, so the system always knew the date profile of what was on the shelf. On top of that, picking was configured to follow FEFO, first expiry first out, so that the stock closest to its best-before date was the stock proposed for picking first. This single change attacked the ageing-stock problem directly: instead of relying on the warehouse manager to remember which pallets were getting old, the system surfaced it automatically and steered the team towards shipping older stock before newer. Allergen and supplier information was tied to the same batch records, so that tracing a specific lot backwards to its import and forwards to its customers became a query rather than a day of detective work.
Purchasing was built to solve the landed-cost blind spot. Softomate configured Odoo's purchasing and landed-cost handling so that the additional costs of importing, the freight, the duty, the insurance and the handling, could be applied to incoming goods and spread across the received quantities. The effect is that the cost held against a pallet of pistachios reflects what it genuinely cost to get into the racking, not just the supplier's invoice line. With real landed cost flowing into the valuation, the margin figures the sales team worked from started to reflect reality, and pricing decisions could be taken on numbers that were actually correct rather than merely comfortable.
The part of this engagement that mattered most to the client, and the part that separates it from a routine software install, was the bespoke work built on top of the standard platform. Two strands ran through it.
The first was custom dashboards. Rather than handing the team Odoo's default reporting and expecting them to adapt, Softomate built dashboards that showed the people in this business exactly what they needed to see, in the terms they already used. The owner got a clear daily picture of stock value, ageing stock and what was selling. The warehouse manager got a view of what was closest to expiry and needed pushing. The purchasing side got a view of stock against lead times and seasonal availability so that ordering decisions could be made with the full picture in front of them. These were not generic charts; they were designed around the actual decisions the team made every day, so that the system answered the questions people were really asking instead of forcing them to dig for the answers.
The second, and the true differentiator, was a set of bespoke custom modules built so that the team could keep working the way it already worked. This was the owner's central condition, and Softomate treated it as a hard requirement rather than a nice-to-have. Where the business had a particular workflow, a specific way of grouping product lines, a particular sequence for handling certain customers, a way of organising goods-in that the team had refined over years, Softomate built that logic into the system rather than asking the team to abandon it. The experienced staff did not have to relearn their jobs to satisfy a generic product. The software was shaped to fit the proven practices of the business, so the knowledge that lived in those practices was preserved and, importantly, encoded into the system where it could outlast any single member of staff. This is how the engagement attacked key-person dependency at its root: by moving the way the business worked out of people's heads and into a system that everyone could see and use.
Data migration was handled as a careful, deliberate exercise rather than a bulk dump. Years of stock, product, supplier and customer information lived in spreadsheets of varying quality, and Softomate worked through it to clean, structure and import it so that the new system started from a trustworthy base rather than carrying the old inconsistencies forward. Product lines were rationalised, supplier records were tidied, and the team was involved throughout so that the data in the system matched the reality in the warehouse on day one. The intention was that the spreadsheets could genuinely be retired, not kept running in parallel as a comfort blanket.
Because the whole point was to keep the team confident and working, training was hands-on and grounded in the staff's own processes, using their real product lines and their real workflows rather than abstract demonstrations. Go-live was phased rather than a single hard switch, so that the business was never exposed to a high-risk big-bang cutover. Softomate brought the core inventory and purchasing functions up first, stabilised them with the team's daily use, then layered in the remaining workflows and the custom dashboards, supporting the staff closely through each step and refining the bespoke modules in response to how the system behaved in real use. The goal at every stage was a team that trusted the system because it reflected how they actually worked, not one that tolerated it because they had been told to.
The headline change was simple to state and significant to live with: the business went from having no reliable picture of its stock to having real-time inventory it could genuinely trust. The question that had been unanswerable, how much of any given product is in the warehouse right now, became something anyone with access could see in seconds, accurate to the actual movement of goods rather than a day or two behind it. Stock accuracy climbed into the high nineties and stayed there, because the system was updated by the act of doing the work rather than by someone remembering to reconcile a sheet afterwards. The sales team could promise quantities with confidence, and the gap between what the records said and what was physically in the racking effectively closed.
Month-end, which under the spreadsheet system had been a multi-day scramble to reconcile stock against accounts, became a routine task. With inventory, purchasing and costing sharing one set of figures, the numbers reconciled because they came from the same source rather than from three sheets that had drifted apart. The owner could close a period and trust the position it reported, and the time the senior team had been losing to month-end firefighting was returned to the business.
The spreadsheets were retired rather than merely supplemented. The master stock sheet, the parallel purchasing sheets and the rekeyed sales records were replaced by one connected system where inventory, purchasing, sales and costing shared the same data. Information was entered once, at the point it happened, and flowed through to everything that needed it, which removed whole categories of duplicate typing. The weekly hours lost to manual rekeying fell sharply, and the time the team had been spending hunting down reconciliation errors fell with them. That recovered capacity went back into work that actually mattered, serving customers and managing stock, rather than into shuffling numbers between disconnected sheets.
Just as important to the owner, the knowledge that had lived in a few people's heads now lived in the system. The way the business organised stock, the purchasing rhythm, the handling of particular customers and the structure of the product range were encoded into Odoo and the bespoke modules, where they were visible and repeatable. The key-person dependency that had quietly worried him eased substantially: when an experienced member of staff was away, the work could continue because the system held the process, not just the person. The business became materially more resilient to a resignation, an illness or a stretch of leave, because its operational memory no longer walked out of the door at five o'clock.
The custom dashboards became part of the daily fabric of the business rather than reports nobody opened. The owner used his stock-value and ageing view to steer decisions, the warehouse manager used the expiry view to push the right stock first, and the purchasing side used the stock-against-lead-time view to order with the full picture in front of them. Because FEFO picking was now driven by the system, dated stock was shipped in the right order far more consistently, and the slow leak of value from product ageing out unnoticed was substantially reduced. The team was no longer relying on one person's memory to know which pallets were getting old; the system surfaced it for everyone.
The bespoke modules delivered exactly what the owner had insisted on at the outset: his experienced team kept working the way it already worked. The staff did not have to abandon hard-won methods to satisfy a generic product, because the software had been shaped around those methods. Adoption was strong precisely because the system felt like a faster, more reliable version of how the business already operated rather than an alien process imposed from outside. That fit is the reason the move off spreadsheets stuck, where previous attempts the owner had considered would have foundered on staff resistance to changing everything at once.
Landed-cost handling gave the business a truer view of margin on its imported lines. With freight, duty and the other import costs flowing into stock valuation, the figures the sales team priced against reflected what product had genuinely cost to land, and pricing decisions could be taken on correct numbers rather than comfortable ones. Batch and allergen traceability moved from near-impossible to routine: tracing a specific lot of nuts backwards to its supplier and forwards to its customers became a query the system could answer, which is exactly the capability a tree-nut importer needs to have ready before it is ever asked for, whether by a customer, a supplier recall or an auditor.
None of these outcomes are presented as precisely measured percentages, and that is deliberate. The owner confirmed the shape and direction of the transformation in clear terms, but the business did not run a controlled before-and-after measurement exercise, so the results here are described as ranges and qualitative changes rather than exact figures. What is not in doubt, on the owner's own account, is the character of the change: from guesswork to trustworthy real-time stock, from spreadsheets and tribal knowledge to one connected system, from a team forced to fit the software to software fitted around the team, and from heavy manual rekeying to a markedly lighter administrative load.
Related services:Odoo ERP Implementation London, Odoo Custom Development London, ERP for Distribution UK and Odoo Inventory and WMS.
This is an anonymised client engagement. Identifying details have been changed for confidentiality and outcome figures are described as ranges rather than exact measured values.
Names withheld to preserve confidentiality.
Work with us
Every project we take on has a measurable outcome. Talk to our London team and we will show you exactly how we would approach your challenge.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy