Building for a Distribution Business Series: #1 The End Game Is the Customer Experience
Building for a Distribution Business Series: #1 The End Game Is the Customer Experience
The article explains how to design a business system by starting with the customer experience you want to create, then working backwards to the data and operational capabilities needed to support it. It offers a practical mental model: plan downwards from customer needs, but build upwards from reliable product, customer and supplier data, using deterministic systems for clear business rules and AI where judgement is less easily reduced to rules. It provides the foundation for understanding why the project’s individual components are being built, and how they are intended to fit together over time.
The article explains how to design a business system by starting with the customer experience you want to create, then working backwards to the data and operational capabilities needed to support it. It offers a practical mental model: plan downwards from customer needs, but build upwards from reliable product, customer and supplier data, using deterministic systems for clear business rules and AI where judgement is less easily reduced to rules. It provides the foundation for understanding why the project’s individual components are being built, and how they are intended to fit together over time.
- Status
- Building
- Started
- March 2026
Audio Overview
ENAudio Overview
THThe End Game Is the Customer Experience: Working Backwards to What You Have to Build
This is the first of several pieces about a system I have been building for a distribution business. It sets out the overall thinking. The pieces that follow deal with the individual parts.
What customer experience means
Customer experience is every touchpoint a customer has with the company. This could mean offline as well as online.
It is also the ultimate goal of the company. You want the customer to have the best possible experience in whichever channel they touch, whether they are placing an order, asking a question or telling you something has gone wrong.
Price matters. But the market is competitive, and at the end of the day the customer chooses the company that addresses their needs with the least friction.
So the question an owner should be asking is this. What are my customer touchpoints, and how can I improve them?
Going through that list with an owner, one stood out: a well written monthly email that is the same for everyone who receives it.
It is the same for everyone because nothing behind it could say what a particular customer might want. The limit is what the company can see about its customers, not the effort that goes in.
Working backwards from the customer
So the question to start from is what you want each of those touchpoints to be. Everything else follows from the answer.
To make any of them better you have to know the customer: what they buy, how much, how often, and whether that pattern is steady or changing. To know what they buy, you have to know what you sell, clearly enough that two records of the same item are recognised as the same item. To promise anything, you have to know where the goods come from and how long they take to arrive. And the three have to be connected, because most questions worth asking draw on more than one of them.
Read from the top, that is a plan. Read from the bottom, it is the order you have to build in.
This is what working from first principles means in practice. Instead of copying how the problem is usually solved, you ask what has to be true and build from that. The difference shows up in what you accept without question. Any existing system contains decisions taken years ago for reasons that made sense at the time. If you start from the system, you keep all of them. If you start from what has to be true, you find out which ones still matter. It is slower, and it can lead to rebuilding things that were working perfectly well, so it is worth applying to the structure, where mistakes are expensive to undo, and being practical about everything else.
Where working backwards ends
At the bottom of it is a small question. What should be brought into stock, and how much should be ordered so that it arrives before we run out.
That is the daily operational problem, and it is where a great deal of an owner's time goes. It is also where working backwards ends, which means it is not a distraction from the more ambitious version. The data you need to answer it well is most of the data you need for everything above it.
Three things a company has to see about itself
What it sells. Not just a list of products, but a way of identifying them that still works when the catalogue is untidy, which it always is. The same item can end up under more than one code. Two items with almost identical names can be different products. Some categories have attributes that others do not have at all. And whatever scheme you choose has to fit the way the staff already record things, because if it does not, they will work around it and the data will stop meaning anything.
Who buys it. Without this you can only estimate demand from what left the warehouse. With it you can see demand directly: which accounts buy an item, how regularly, and whether last month's sales came from one customer or twenty. Those two situations call for completely different decisions, and without customer data they look the same.
Where it comes from. Which supplier, how long they take, and what is already on order. This is what lets you size and combine orders rather than placing them one product at a time.
Most established companies already have a database, and it is rarely the obstacle people expect it to be. The difficulty is that it was built to record what happened, not to decide what to do next. It answers questions within one area well, and struggles as soon as a question spans two.
What that makes possible for the customer
The things they buy regularly are in stock when they want them, because replenishment is sized against what customers actually bought rather than an estimate.
When their usual choice is unavailable, they are offered a sensible alternative instead of an apology.
What arrives in their inbox relates to what they buy, rather than being everything the company happens to be holding.
And one more that is worth aiming at directly. The items a company needs to move and the items a particular customer would be glad to hear about are often the same items. At the moment those are two separate lists, produced by different people, and they frequently pull against each other. They should be one list.
What it makes possible for the owner
Orders can be sized and combined so that the cost of buying makes sense, rather than placed product by product as each one runs low.
More importantly, the owner stops spending his week working out what happened and starts spending it deciding what to do next: new products, new markets, which accounts are worth developing. His team spends less time on it, not more, because nobody was asked to change how they work. And the business can be managed close to the present rather than a fortnight behind it.
That time is what the whole thing is for. Everything underneath exists to produce it.
Plan downwards, build upwards
You plan downwards from the customer and you build upwards from the data. The discipline is making sure that whatever you build to solve today's problem is already shaped to carry the parts you have not built yet.
That is the order of the pieces that follow. Whether the data a business already has can be trusted, and how you find out. A method built from years of experience, set against logic built deliberately, and what you learn from comparing them. The screen that replaced the fortnightly exercise. And then the customer layer, which is where all of this was heading.
What gets built, and what has changed
The build starts with a database that ingests the working data the team already produces. On top of it sits a set of customisable, deterministic systems, built from the well-defined business logic the owner already deploys to manage day-to-day operations. That logic is proven. What AI does is translate it into code.
In the past, digital transformation stopped there. The system handled whatever could be reduced to a rule, and everything else went back to the owner, because the nuance sat in his experience and expertise and nowhere else.
That is what has changed. Now, with AI, those nuances can be dealt with using machine learning. A deterministic system needs a rule for every case it will meet; a probabilistic one does not, and that is what makes it possible to train AI on decision-making that until now depended on that experience. It can gather large amounts of data, analyse it, and take automated steps on non-critical tasks. Where a task requires precision it does not act on its own, but prepares suggestions to support the owner's decision-making.
The subsequent write-ups in the series will explore what the individual deterministic components are and how they are built using AI, and then the journey of training and deploying an AI workforce to take the business further.
The End Game Is the Customer Experience: Working Backwards to What You Have to Build
This is the first of several pieces about a system I have been building for a distribution business. It sets out the overall thinking. The pieces that follow deal with the individual parts.
What customer experience means
Customer experience is every touchpoint a customer has with the company. This could mean offline as well as online.
It is also the ultimate goal of the company. You want the customer to have the best possible experience in whichever channel they touch, whether they are placing an order, asking a question or telling you something has gone wrong.
Price matters. But the market is competitive, and at the end of the day the customer chooses the company that addresses their needs with the least friction.
So the question an owner should be asking is this. What are my customer touchpoints, and how can I improve them?
Going through that list with an owner, one stood out: a well written monthly email that is the same for everyone who receives it.
It is the same for everyone because nothing behind it could say what a particular customer might want. The limit is what the company can see about its customers, not the effort that goes in.
Working backwards from the customer
So the question to start from is what you want each of those touchpoints to be. Everything else follows from the answer.
To make any of them better you have to know the customer: what they buy, how much, how often, and whether that pattern is steady or changing. To know what they buy, you have to know what you sell, clearly enough that two records of the same item are recognised as the same item. To promise anything, you have to know where the goods come from and how long they take to arrive. And the three have to be connected, because most questions worth asking draw on more than one of them.
Read from the top, that is a plan. Read from the bottom, it is the order you have to build in.
This is what working from first principles means in practice. Instead of copying how the problem is usually solved, you ask what has to be true and build from that. The difference shows up in what you accept without question. Any existing system contains decisions taken years ago for reasons that made sense at the time. If you start from the system, you keep all of them. If you start from what has to be true, you find out which ones still matter. It is slower, and it can lead to rebuilding things that were working perfectly well, so it is worth applying to the structure, where mistakes are expensive to undo, and being practical about everything else.
Where working backwards ends
At the bottom of it is a small question. What should be brought into stock, and how much should be ordered so that it arrives before we run out.
That is the daily operational problem, and it is where a great deal of an owner's time goes. It is also where working backwards ends, which means it is not a distraction from the more ambitious version. The data you need to answer it well is most of the data you need for everything above it.
Three things a company has to see about itself
What it sells. Not just a list of products, but a way of identifying them that still works when the catalogue is untidy, which it always is. The same item can end up under more than one code. Two items with almost identical names can be different products. Some categories have attributes that others do not have at all. And whatever scheme you choose has to fit the way the staff already record things, because if it does not, they will work around it and the data will stop meaning anything.
Who buys it. Without this you can only estimate demand from what left the warehouse. With it you can see demand directly: which accounts buy an item, how regularly, and whether last month's sales came from one customer or twenty. Those two situations call for completely different decisions, and without customer data they look the same.
Where it comes from. Which supplier, how long they take, and what is already on order. This is what lets you size and combine orders rather than placing them one product at a time.
Most established companies already have a database, and it is rarely the obstacle people expect it to be. The difficulty is that it was built to record what happened, not to decide what to do next. It answers questions within one area well, and struggles as soon as a question spans two.
What that makes possible for the customer
The things they buy regularly are in stock when they want them, because replenishment is sized against what customers actually bought rather than an estimate.
When their usual choice is unavailable, they are offered a sensible alternative instead of an apology.
What arrives in their inbox relates to what they buy, rather than being everything the company happens to be holding.
And one more that is worth aiming at directly. The items a company needs to move and the items a particular customer would be glad to hear about are often the same items. At the moment those are two separate lists, produced by different people, and they frequently pull against each other. They should be one list.
What it makes possible for the owner
Orders can be sized and combined so that the cost of buying makes sense, rather than placed product by product as each one runs low.
More importantly, the owner stops spending his week working out what happened and starts spending it deciding what to do next: new products, new markets, which accounts are worth developing. His team spends less time on it, not more, because nobody was asked to change how they work. And the business can be managed close to the present rather than a fortnight behind it.
That time is what the whole thing is for. Everything underneath exists to produce it.
Plan downwards, build upwards
You plan downwards from the customer and you build upwards from the data. The discipline is making sure that whatever you build to solve today's problem is already shaped to carry the parts you have not built yet.
That is the order of the pieces that follow. Whether the data a business already has can be trusted, and how you find out. A method built from years of experience, set against logic built deliberately, and what you learn from comparing them. The screen that replaced the fortnightly exercise. And then the customer layer, which is where all of this was heading.
What gets built, and what has changed
The build starts with a database that ingests the working data the team already produces. On top of it sits a set of customisable, deterministic systems, built from the well-defined business logic the owner already deploys to manage day-to-day operations. That logic is proven. What AI does is translate it into code.
In the past, digital transformation stopped there. The system handled whatever could be reduced to a rule, and everything else went back to the owner, because the nuance sat in his experience and expertise and nowhere else.
That is what has changed. Now, with AI, those nuances can be dealt with using machine learning. A deterministic system needs a rule for every case it will meet; a probabilistic one does not, and that is what makes it possible to train AI on decision-making that until now depended on that experience. It can gather large amounts of data, analyse it, and take automated steps on non-critical tasks. Where a task requires precision it does not act on its own, but prepares suggestions to support the owner's decision-making.
The subsequent write-ups in the series will explore what the individual deterministic components are and how they are built using AI, and then the journey of training and deploying an AI workforce to take the business further.