Why one delivery date is harder than it looks
Calculate a customer delivery date by adding customer lead time to the confirmation date, then checking that supplier, production, buffer and courier times fit. They do not care that the timber arrived late or that your maker is booked for two weeks. They want to know when the parcel will be on their doorstep, and they will hold you to whatever you say.
Most small shops answer that question from memory. Someone says "about three weeks" because that is what the last few orders took. Sometimes that works. Often it does not, because the estimate skips a step, quietly assumes stock is already on the shelf, or leaves no room for the delay that always seems to happen.
A better method is to split the promise into the inputs that create it, then add them up in the right order. Accurate forecasting matters here. Odoo's documentation on lead times makes the point directly: "Accurately forecasting delivery dates is vital for fulfilling customer expectations."
This post walks through a simple method built on four lead time inputs. You can run it on paper, in a spreadsheet, or inside the inventory or order system you already use. The arithmetic is not hard. The discipline of writing each input down, and keeping it up to date, is what makes the date reliable.
The four lead time inputs
The method uses four inputs. They are a practical way of splitting the problem, not a formal standard, so rename them to suit your shop. What matters is that each one does a separate job, so you can see which part is causing a late order.
1. Supplier lead time. The number of days between placing an order for materials or stock and having it in your hands. If you make the item yourself from bought-in parts, this is the wait for those parts. If you resell finished goods, it is the wait for your wholesaler or distributor. If you already hold the stock, this input is zero, and the method still works.
2. Production lead time. The number of days it takes to make the item once the materials are in the building. This is your working time. Include drying, curing, setup, and any time the job spends waiting behind other work, because the customer experiences all of it.
3. Security buffer. Extra days added to cover the delays you know will happen some of the time: a late courier pickup, a piece that needs reworking, a machine that needs a part. It is a deliberate safety margin, and it should be written as its own number so you can see how much margin you are carrying.
4. Customer lead time. The total number of days from order confirmation to delivery that you are willing to promise, including courier time. This is the figure you show the customer, and it is the one that sets the delivery date. Odoo's guidance is to set the customer lead time on each product form, by navigating to the products page, which keeps the figure with the item it describes.
Notice that the first three inputs describe the work your shop does, while the fourth describes the promise. The method works because it checks the first against the second. If the work will not fit inside the promise, you have a problem to solve before the customer ever sees a date.
Step one: fix the start date
Every calculation needs a starting point. The clock should start on the day the order is confirmed. It should not start on the day the enquiry arrived, and it should not start on the day you first sent a price. Once the customer has committed and you have the details you need, the order is confirmed, and that is the day the calculation begins.
Odoo's documentation uses a clear starting point of this kind in its example. It describes a sales order for a scented candle: "A SO containing a Coconut-scented candle is confirmed on July 11th."
Write the confirmation date at the top of your sheet, and check it against the order record rather than your memory. Every other date is built from it.
Decide one rule for the start date and use it every time. Whether a deposit counts as confirmation is your choice. Inconsistency is the problem, because two identical orders then get different promises.
Step two: get a first answer from the customer lead time
Once you have the start date and the customer lead time, you have a first answer. It is the simplest possible date: confirmation date plus customer lead time. Odoo gives a delivery date based on its lead time inputs. Its documentation says: "Based on the lead time inputs, Odoo suggests a delivery date in 15 days, on July 26th."
Counting fifteen days forward from July 11th gives July 26th, which is the date the example shows. You can do the same count on your own orders. Use a calendar that shows the days clearly, and check whether any closed days fall inside the window before you commit to a date.
Treat this first answer as a check, not yet as a promise. It tells you what the customer lead time implies on its own, and nothing about whether your shop can deliver it. The other three inputs, together with courier time, answer that. If your supplier, production, buffer, and courier times add up to more than the customer lead time, the first answer is wrong, and you need to either change the promise or change the process.
Step three: work backward to find the start date
Working backward answers a different question: when must I start making or buying this item so that the customer receives it on time? It is the calculation you use when the delivery date is fixed and you need to know the last safe day to begin.
Odoo's documentation models this with manufacturing orders, and its example gives the inputs first: "The manufacturing lead time is 7 days, and manufacturing security lead time is 3 days." The example then sets out the dates it works towards. The planned production date is given as: "In this example, the planned date on the MO is August 5th." The latest start is given as: "So, the latest date to start the MO to meet the commitment date is August 1st." The shipment that the commitment refers to is: "A product’s scheduled shipment date on the DO is August 15th."
Those lines name several checkpoints, and it helps to keep them separate on your own sheet. There is the date the item must ship, the latest day you can start production and still hit that date, and the planned date you actually put in the diary. The planned date and the latest start date are different days in Odoo's example, so record both.
Step four: set the security buffer honestly
A buffer leaves room for delays before they change the promised date. Keeping it separate lets you see how much margin you are carrying and whether that margin is enough.
To set the buffer, look at your last ten or twenty jobs. Find the ones that ran late, and measure how late they ran. Set the buffer to cover the usual slip, not the rare disaster. A buffer that is too large makes every quote look slow, and you will lose work to shops that promise less. A buffer that is too small makes every late delivery an apology. The right figure sits between those two, and it is something you should review every few months.
If you cannot tell real work from margin, you cannot tell whether to shorten the estimate or keep the buffer when a job runs faster than usual.
A worked example, from start to promise
Odoo's documentation gives two separate illustrations, one for the first answer and one for backward planning. Keep them apart, because they describe different orders.
For a separate illustrative order, confirm the order on July 11th. Use an illustrative customer lead time of fifteen calendar days, giving a promised delivery date of July 26th.
Now check whether the work fits. For a made-to-order item, you would add your supplier lead time, your production lead time, and your security buffer. For this illustrative order, use 3 days for supply, 7 days for production, 3 days for the buffer and 2 days for the courier: 3 + 7 + 3 + 2 = 15 days, so delivery on July 26th fits the customer lead time exactly. If the supplier time, production time, buffer and courier time together exceed the promised window, the date needs to change. If they do not, the calculation fits, though a delay beyond the buffer could still change the arrival date.
Here is the same idea written as a single line you can copy into a sheet:
Latest safe start = confirmation date + customer lead time − (supplier lead time + production lead time + security buffer + courier time)
If the result is earlier than the confirmation date, the promise cannot be met in the time you have given. Either the customer lead time is too short, or one of the inputs is too long. Those are the only two things you can change, and they usually lead to different conversations with the customer.
This line is a sum you can check, not a rule taken from any documentation. The numbers that matter are the ones you measure in your own shop.
Working forward when you quote
Working forward is the calculation you use when you quote. You start from the confirmation date, add the chain of inputs in order, and see what date comes out.
A simple way to do this is to write the chain as a series of dates across one row of a spreadsheet. Column one is the confirmation date. Column two is the date the supplier stock arrives, which is the confirmation date plus the supplier lead time. Column three is the planned finish, which adds the production lead time. Column four is the arrival date after adding the buffer and courier time, and column five is the promised date: confirmation date plus customer lead time. Each column is a checkpoint, and you can see at a glance where the time goes.
Working forward has one trap. The supplier date is only as good as the supplier lead time behind it. Check that input against the most recent order, not the number you wrote down a year ago.
Multi-item orders
Many orders have more than one item, and each item may have its own chain. The date you promise for the whole order must work for every item, which means the slowest chain sets the date. Calculate each item separately, then take the latest result as the order's delivery date.
This matters most when one item is in stock and another is made to order. It is tempting to promise the date for the in-stock item, because it is ready early, but the customer will receive the whole order at once, or they will want to know when the rest arrives. Be clear about which it is. If you ship in parts, quote each part on its own line with its own date, and say so in the confirmation.
For a mixed order, keep each line's chain in the same sheet. The slowest line is the one to look at first if you want to shorten the promise.
Calendars, working days, and closures
Lead times are counted in days, but it is not always clear which days. Decide whether your numbers are calendar days or working days, and write that down next to each input. A supplier who counts working days and a courier who counts calendar days will give you two very different dates from the same figures.
Closures matter too. Add known closures to your calendar, and check for public holidays each time you calculate a date. A date that falls on a closed day is not a real promise.
If you change the calendar convention, review every open order, because its dates may need to change.
Where to keep the four inputs
The inputs are only useful if they are in one place and easy to find. The supplier and production inputs can sit alongside the customer lead time, depending on how your system is built.
Record the date each input was last checked, and keep a short log of changes. When a customer asks why the date moved, you want to be able to say that the supplier lead time changed on a particular date, rather than guessing. The log also helps you spot patterns. If one input keeps drifting, you have found the input that needs attention.
If you use a spreadsheet, label each input with its unit, so nobody has to guess whether a bare number means days.
Common mistakes to avoid
Several errors come up again and again when shops first try this method.
Using the best case as the plan. The fastest time a job has ever taken is not your typical time. Plan with the usual time, and let the buffer cover the rest.
Leaving out the buffer. Without a buffer, delays leave less room to keep the promised date.
Forgetting closures and weekends. A date that falls on a Sunday or a public holiday may not be the date anyone works on.
Changing an input without updating open orders. If you lengthen a supplier lead time, every open order built on the old figure is now at risk. Review them, and contact the affected customers early rather than late.
Test the method against real orders
The best way to check the method is to run it against orders you have already delivered. Pick the last ten or twenty, and work out what date the method would have given for each one at the time of confirmation. Then compare that date with the date the order actually arrived.
If the method gives a date that was too early, look at which input was too optimistic. If the method gives a date that was too late, look at whether the buffer is too large, or whether one input is out of date. Change one input at a time, then test again. Changing all four at once makes it impossible to tell which change helped.
Over a few months, this turns the method from a guess into a record. You will know your real production time, your real supplier time, and the buffer you actually need.
A short checklist
Before you send a delivery date to a customer, check these points:
- The confirmation date is correct and matches the order record.
- The customer lead time is the figure on the product, and it is the total you are willing to promise.
- The supplier lead time reflects the most recent order, and it counts from when you place the order.
- The production lead time is your usual time, not your best time.
- The security buffer is written separately and sized to the slips you actually see.
- The chain of supplier, production, buffer, and courier time fits inside the customer lead time.
- Closures and public holidays have been counted.
- For multi-item orders, the latest line sets the promised date.
If every point holds, send the date with confidence. If one fails, fix it first. A date you can keep is worth more to a customer than a date that sounds better and arrives late.
Final thought
Use delivered orders to keep improving the inputs behind your next quote. Over time, the date you promise will become a date you can keep, and that is what customers remember.