Case Study
A UK dry fruit and nut importer feared an off-the-shelf ERP would force its team to abandon the way it already worked. Softomate built bespoke Odoo modules and custom dashboards around the team's own logic, so the system fit the business rather than the reverse, and the staff actually adopted it.
15 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 feared an off-the-shelf ERP would force its team to abandon the way it already worked. Softomate built bespoke Odoo modules and custom dashboards around the team's own logic, so the system fit the business rather than the reverse, and the staff actually adopted it.
The owner of a UK dry fruit and nut importer came to Softomate with a worry that had nothing to do with software features and everything to do with how his people worked. He was not asking whether an ERP could track stock, cost a shipment, or print an invoice. He took for granted that any modern system could do those things. His worry was sharper and, in his experience, far more likely to sink the project: would a new system force his team to throw away the way they already worked, the way that had built the business over fifteen years, and replace it with a rigid set of screens designed by someone who had never imported a single pallet of almonds.
It was a reasonable fear, and it was grounded in things he had seen happen. He had two friends in the wholesale food trade who had bought packaged ERP and packaged food-distribution systems, paid for them, trained their staff on them, and watched the projects stall. In both cases the software had been perfectly capable on paper. The problem was that it expected the business to bend itself into the shape the software wanted. Stock had to be entered the software's way. Pricing had to follow the software's logic. The reports came in the software's format, not the format the owners had relied on for years. In both cases the staff, who were busy and under pressure and had real work to do, quietly went back to their spreadsheets and their notebooks, and the expensive system became a place data went to be ignored.
This importer ran a lean operation. Between ten and twenty-five people depending on the season, a single warehouse and office site, and a turnover in the low single-digit millions. Almonds, cashews, walnuts, pistachios, dried apricots, raisins, dates, figs and a long tail of seasonal lines, bought in bulk from growers and consolidators across several countries, broken down, repacked, and sold on to retailers, caterers, independent shops and a handful of larger accounts. It is a business of fine margins, perishable stock, and timing. A container bought well, landed at the right cost, and sold before quality slipped is the difference between a good month and a written-off batch.
Over those fifteen years the team had developed their own way of thinking about all of it, and crucially their own logic for the parts that mattered most. They had a way of deciding which stock to move first that was not pure first-in-first-out, because a later batch from a better grower sometimes had to go out ahead of an older one. They had a way of building a sell price off the landed cost of a specific shipment plus a margin that varied by customer type and by how the season was running. They had a small set of figures the owner looked at to know whether the business was healthy, and he looked at them in a particular order, in a particular shape, because that was how he had learned to read his own company. None of this was written down in a manual. It lived in the heads of the people who did the work and in a web of spreadsheets that only made full sense to the person who built each one.
That was the real asset, and it was also the real risk. The way they worked was genuinely good. It was the accumulated judgement of a team that knew its trade. But it was fragile, undocumented, and tied to specific people. If a key person was off, parts of the operation slowed because only they knew how a particular spreadsheet really worked or why a price was set the way it was. The owner knew he needed to get this knowledge into a proper system before it walked out of the door. What he refused to do was get it into a system at the cost of changing it into something his team no longer recognised or trusted.
He had looked at the obvious options and come away uneasy. The big-name ERP suites were powerful but clearly built for businesses far larger than his, and every demo he sat through showed him screens and processes that assumed he would adapt to them. The packaged food-distribution products were closer to his world, and they understood batches and expiry and landed cost in general terms, but they understood them in their way, not his. When he asked the inevitable question, can it work the way we already do this, the honest answer was always some version of: not exactly, you would do it our way, and our way is the industry standard. For a team whose entire edge was its own particular judgement, being told to adopt the generic industry standard was not reassuring. It was the exact thing he was afraid of.
So the brief he gave Softomate was unusual, and it was the right one. He did not ask for an ERP. He asked whether it was possible to build a system that learned how his business already worked and then supported that, rather than a system that arrived with its own opinions and expected everyone to fall in line. He wanted his stock logic to be his stock logic. He wanted his pricing to follow his rules. He wanted the owner's daily numbers to appear in the shape he already read them in. He wanted his people to open the system and feel that it had been built for them, because if they felt that, they would use it, and if they felt the opposite, he had already seen twice over exactly how that ends.
Softomate's answer was to treat the build as the opposite of a packaged rollout. Instead of taking a finished product and configuring the business to fit it, the team set out to capture how the business actually worked and then build the software around that. The foundation chosen for this was Odoo, specifically because it is open source and modular. That mattered for one concrete reason: Odoo can be extended with bespoke modules written in Python, its data model and screens can be reshaped, and its dashboards can be composed to show whatever a business needs to see. It was a platform that could be made to fit the importer, rather than a closed product the importer would have to bend toward. The decision was deliberate, and it was explained to the owner in those terms, so he understood from the start that the flexibility was the point.
The first phase was discovery, and it was heavier than a typical software project because the goal was not to gather requirements in the abstract but to document a way of working that had never been written down. Softomate spent time on site with the people who did the work. They sat with the warehouse team as stock came in and went out. They sat with the person who built sell prices and watched how a quote was actually constructed, including the judgement calls that never appeared in any formula. They went through the owner's spreadsheets line by line and asked, repeatedly, not just what does this column do but why do you look at this, and why in this order, and what would worry you if this number moved.
What came out of that was a clear picture of the team's own logic, the logic that any packaged system would have quietly overwritten. Their stock rotation was not plain first-in-first-out; it weighed batch quality and grower against age, and there were rules of thumb the team applied without thinking that had to be made explicit and encoded. Their pricing built upward from the landed cost of a specific shipment, not an average cost, and the margin on top flexed by customer type and by how the season was running. The figures the owner relied on were a specific short list, viewed in a specific arrangement. Softomate wrote all of this down properly, turned the tacit knowledge into a documented specification, and had the team confirm it. That document, the team's own way of working made explicit, became the blueprint for the build. It was a valuable outcome in its own right, because for the first time the business knowledge that had lived only in people's heads existed in a form the company owned.
With the blueprint agreed, Softomate built bespoke custom modules on Odoo that encoded the importer's own processes rather than imposing generic ones. The work was configuration where Odoo could already do what was needed, and genuine custom development in Python where it could not. The principle throughout was that the system bent to the team, never the reverse.
The food-importer specifics were handled, but handled in the way the team already thought about them, which is the part that mattered. Batch and expiry tracking was built so that each intake of stock carried its batch, its source and its best-before information through the whole flow, which is essential for perishable nuts and dried fruit and for traceability if a recall is ever needed. Crucially, the stock movement logic that sat on top of that tracking followed the team's own rotation rules, not a textbook default, so the system suggested moving stock in the order the team would actually have chosen. Landed cost was built into the costing so that freight, duty, insurance and handling were folded into the true cost of each shipment, and that true cost fed the pricing exactly as the team did it by hand. Allergen information for the nut lines was carried through as part of the product data so it was always available for labelling and for customer questions, rather than being kept in a separate list that could fall out of date. None of these were bolted-on generic features. Each was shaped to match the mental model the team already used, so that opening the system felt like a faster version of how they already thought, not a foreign process they had to learn from scratch.
The pricing engine was the clearest example of bespoke work earning its place. A packaged system would have offered a pricing module and expected the importer to price the packaged way. Instead, Softomate built the importer's own pricing rules into a custom module: sell prices derived from the landed cost of the relevant shipment, margins that varied by customer category, and the seasonal adjustments the team applied by feel, now expressed as rules the system could apply consistently. The team's pricing judgement was preserved and made repeatable, so a newer member of staff could produce a quote the same way the most experienced person would, without having to absorb fifteen years of instinct first.
The custom dashboards were built to show exactly the numbers the team and the owner actually wanted, in the shape they were used to reading. This was treated as a core deliverable, not a cosmetic afterthought, because dashboards are where a system either earns a place in someone's daily routine or gets ignored. Softomate took the owner's short list of figures, the ones he had pulled together by hand for years, and built them into a live dashboard that read straight from the running system. Stock value and ageing, margin by line and by customer type, what was moving and what was sitting, the landed cost picture, the handful of indicators he used to judge whether the business was healthy, all arranged the way he already read them rather than the way a generic template would have imposed. The aim was simple and explicit: when the owner opened the dashboard, it should feel like his own familiar view, only now accurate, live and effortless, instead of something he had to rebuild from spreadsheets each time he wanted to look.
Role-appropriate dashboard views were built for the warehouse and the sales side too, each showing the figures relevant to that work and nothing that would clutter it. The principle was consistent across all of them: the dashboard fit the person, the person did not have to learn the dashboard.
Throughout the build the working relationship was iterative and close. Softomate showed the team working modules early and often, watched how they reacted, and adjusted. Where a screen did not match how someone worked, the screen changed. Where a piece of the team's logic had been captured slightly wrong in discovery, it was corrected in the build. Because the foundation was open and modular, these changes were genuinely possible rather than blocked by a vendor's fixed product, which is the difference that let the system end up fitting properly. The team were not handed a finished black box and told to adapt. They watched their own way of working take shape inside the software and helped steer it, which meant that by the time it went live it already felt like theirs.
The clearest outcome was the one the owner had been most afraid of losing: the team actually adopted the system. This is the result that any number of feature lists cannot buy and that the two failed projects he had watched never achieved. Because the system worked the way the staff already worked, they did not fight it. There was no quiet drift back to the old spreadsheets, no parallel set of notebooks kept because people did not trust the screens. The bespoke approach is precisely why it stuck. When software mirrors how people already think, using it feels like a faster version of what they already do, and that is a very different experience from being told to abandon your own judgement and follow someone else's rigid process.
Within weeks rather than months the system had moved from something being rolled out to simply how the work got done. Adoption that fast is unusual for an ERP, and it happened for a single reason. The staff were not learning a foreign way of working on top of their jobs. They were doing their jobs in a tool that had been built to match them. New members of the team could be brought up to speed faster too, because the system now carried the rules and the logic that previously lived only in experienced people's heads. The pricing judgement, the rotation rules, the way the numbers were read, all of it was now in a system the company owned rather than in memory that could leave.
The custom dashboards became part of the daily routine. The owner described the main dashboard as the first thing he checked each morning, because it gave him in seconds the picture of his business that he had previously assembled by hand from several spreadsheets, and it gave it to him in the exact shape he was used to reading. That is a small sentence with a large meaning. For years he had wanted clear, current visibility of his own company, and the only way he had been able to get it was to do the work of building the view himself, which meant in practice he did it less often than he wanted to. Now the view was always there, always current, and always in his language. He got the visibility he had always wanted without having to change a single thing about how the business actually runs.
That phrase captures the heart of the engagement. The owner gained control and clarity without the cost he had feared. The business did not have to remake itself to suit a piece of software. The software was remade to suit the business. The team kept their hard-won way of working, the way that was genuinely good and genuinely theirs, and simply gained a system that supported it, made it consistent, and protected it from being lost.
The food-importer specifics earned their keep quietly, in the way good infrastructure does. Batch and expiry tracking meant the team could see at a glance which stock needed to move and could trace any line back to its source if a customer or a regulator ever asked, which for a perishable food business is a baseline requirement the spreadsheets had only ever met with effort and risk. Landed cost flowing into pricing meant quotes reflected the true cost of each shipment automatically, removing a calculation that had previously depended on the right person remembering to do it right. Allergen data carried with each nut product meant labelling and customer questions could be answered confidently from the system. None of these features were experienced by the team as new processes to learn, because each had been shaped around how they already handled these things. They simply worked, in the background, the way the team expected.
Staff were not fighting the software, and that absence of friction had effects beyond the obvious. Time that would have gone into resisting a system, working around it, or maintaining shadow spreadsheets alongside it simply did not have to be spent. The energy the team had went into the actual work of buying well, moving stock before quality slipped, and serving customers. The owner no longer had the nagging worry that critical knowledge was tied to specific people and could vanish if someone left, because that knowledge now lived in a system the company controlled.
It is worth being honest about what this case study does and does not claim. The benefit here is not a single dramatic number. It is something harder to put a figure on but that anyone who has seen an ERP project fail will recognise as more valuable: a system the people actually use, every day, by choice, because it fits them. The qualitative outcomes were confirmed by the owner. The team adopted the system within weeks rather than resisting it. The dashboards became the first thing the owner checked each morning. The staff were not fighting the software. The business kept running the way it always had, only now with the visibility and consistency it had lacked. Those outcomes are the point, and they are the direct result of choosing to build around the team's way of working rather than forcing the team to change.
The broader lesson the owner drew from it, and the one he has shared with his peers in the trade, is that the usual ERP story has the relationship backwards. The conventional approach asks a business to change itself to fit rigid software, and treats staff resistance as a training problem to be overcome. His experience was that the resistance was not the problem at all. The resistance was a signal that the software did not fit, and the answer was not to push harder against the people but to build the software so it fit in the first place. Because Softomate used the flexibility of an open, modular foundation to encode his team's own logic and show his own numbers his own way, the project succeeded exactly where a packaged system, by his own assessment, would have been rejected by his team and joined the spreadsheets gathering dust.
The system continues to grow with the business. Because it was built on a flexible, modular foundation rather than a fixed product, new lines, new rules, and new figures the owner wants to watch can be added as the business changes, without the team having to start again or bend to a vendor's roadmap. The way of working that the importer spent fifteen years developing is now safe, documented, and supported, and it remains theirs.
This is an anonymised client engagement. Identifying details have been changed for confidentiality and outcomes are described qualitatively.
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