You promise reliable delivery dates by promising against available-to-promise instead of on-hand, with real lead times in the system and one calculation across sales, purchasing and production. The date then comes from numbers, not from a salesperson's gut.
A customer asks the obvious question: "when will I have it?" Your salesperson looks at a stock screen that says 40 in stock, says "Friday", and sends the order confirmation. On Thursday it turns out 30 of those 40 were already promised to other orders, the rest are the wrong variant, and the replenishment from your supplier lands next week, not this one. So you call the customer back and move the date. They are polite about it the first time. The third time they start asking your competitor the same question.
This is the order-promising problem, and it is a business problem before it is a software problem. The date you put on the confirmation is a promise. If it comes from a number nobody trusts, a salesperson's gut feel, or a stock figure that ignores what is already committed and what is on the way, you will miss it. The fix is not to promise later or pad every date by two weeks. It is to make the promise from real numbers: what is genuinely available to promise, and how long it actually takes to get more. Here is why the dates slip, what it costs you, and how to promise dates you can keep. Underneath sits a choice we push every client to make explicitly: run the system as an enabler, not as an administrative package. When the system is the thing that tells sales what to promise, you are forced to keep stock, lead times and commitments current, and the reward is a date you can defend. A system that only records what already happened can never promise anything.
Why delivery promises slip
The date breaks because the person making the promise is working from the wrong number, or from no shared number at all. A few causes show up again and again.
Stock you can't trust. The figure on screen says 40 on hand, but it does not say how many are already reserved for confirmed orders, how many are sitting in a quality hold, or how many are the wrong size or colour. "On hand" is not "available to sell". Promising against on-hand is promising stock you have already sold to someone else.
No link between sales, purchasing and production. Sales promises a date. Purchasing orders the materials on a separate schedule nobody told sales about. Production slots the job into a plan sales never sees. Three teams, three calendars, and the customer's date depends on all three lining up by accident. When they don't, nobody finds out until it is too late to warn the customer.
Supplier lead times that live in someone's head. The real time to restock a part is "about two weeks, but three around the holidays, and that one vendor is always late". If that knowledge sits in one buyer's memory instead of in the system, the date on the order confirmation is a guess, and it is only right when that one person happens to be in the room.
Promising the whole order on the date of the slowest line. A ten-line order where nine lines ship today and one is on backorder gets one date: the backorder date. Or worse, it gets today's date and nine lines ship while the tenth quietly slips, and the customer notices the gap before you do.
A static date that never updates. The promise is made once at order time and then frozen. A supplier delay, a production reschedule, or a bigger order jumping the queue changes reality, but the confirmation still says Friday. The date was right when it was made and wrong by the time it mattered, and nothing flagged the change.
What it costs you
A missed delivery date is not a small operational hiccup. It is the most visible promise you make to a customer, and breaking it is expensive in ways that do not show up on one invoice.
You lose the reorder, not just the order. A customer who got a date and got the goods on that date comes back without shopping around. A customer you called twice to move the date starts every future order by asking what your real lead time is, and asks two of your competitors the same thing. The cost is not the one late order, it is the margin on every order after it that now goes out to tender.
Your team burns time firefighting instead of selling. Every slipped date turns into phone calls, apologies, expedited shipping you eat the cost of, and a salesperson chasing purchasing for a status nobody can give. That time is not free, and it is time not spent winning the next deal.
You over-promise or over-protect, and both cost you. Promise dates you can't keep and you lose trust. Pad every date by two weeks to be safe and you lose the deals where the customer needed it sooner and your honest-but-padded date sent them elsewhere. Without real numbers you are stuck choosing between looking unreliable and looking slow.
The fix, in numbered steps
You fix order promising by making the date come from data the whole business shares, not from one person's screen. The steps build on each other.
Promise against available-to-promise, not on-hand.
Stop using the raw on-hand figure. The number that matters is what is free to commit after you subtract everything already reserved for other orders and add what is genuinely inbound with a confirmed arrival. In Odoo this is the forecasted quantity: it nets reservations and incoming receipts against on-hand so the figure on the order line is the real one. Promise against that, and you stop selling the same unit twice.
Put real lead times into the system, per product and per supplier.
The two weeks that lives in a buyer's head has to live on the product and the supplier record: the purchase lead time per vendor, the manufacturing lead time per product, the sales lead time you need to pick and ship. Once those are in, the system can add them up into a real delivery date instead of a salesperson guessing. Update them when reality changes, because a lead time that was true last year quietly rots.
Connect sales, purchasing and production so the date is one calculation.
The promise should chain through the whole flow automatically. If the stock is there, the date is pick-and-ship time. If it is not, the date is supplier lead time plus receiving plus shipping, or production lead time plus shipping. Odoo can run replenishment on demand so a confirmed sales order triggers the purchase or the manufacturing order, and the dates connect end to end instead of living on three separate calendars.
Promise each line on its own date, and be clear about partials.
A ten-line order is not one promise, it is ten. Show the lines that ship now and the lines that follow, give each its real date, and decide with the customer whether they want a partial shipment now or the whole order together later. One honest split beats one optimistic date for the lot.
Make the date recalculate when reality changes.
A promise made at order time has to survive contact with a supplier delay or a production reschedule. Use forecasting and scheduling that update the expected dates when inputs change, so a slip shows up as a flag on the order while there is still time to call the customer, not as a surprise on the ship date.
The part that trips people up
A few things catch almost everyone
On-hand is the number everyone reaches for, and it is the wrong one. The salesperson sees "40 in stock" and promises against it because it is the figure on the first screen. The available figure (on-hand minus reserved plus confirmed inbound) is the only one that is safe to promise, and it is usually a click away rather than front and centre. Train the team to read the forecasted or available column, not the on-hand one.
Lead times are not "set once". The whole system is only as honest as the lead-time data behind it, and lead times drift. A vendor that was reliable gets slow, a new product has no history yet, a holiday stretches everything. If nobody owns keeping lead times current, the dates degrade quietly and you are back to guessing without noticing.
Automating replenishment does not mean the date is now safe to ignore. Make-to-order and on-demand replenishment connect the calendars, but they assume the lead times you fed in are right. Garbage lead times in, confidently wrong dates out. The automation makes good data powerful and bad data dangerous.
A reliable date is sometimes a longer date, and that is fine. The goal is not the earliest date, it is the date you hit. A customer who is told "the 18th" and gets it on the 18th trusts you more than a customer who is told "the 11th" three times. Resist the pressure to quote the optimistic date to win the order, because the order you win on a date you miss is the customer you lose.
Edition and setup matter. The forecasting, the lead-time fields, the make-to-order routes and the replenishment are standard Odoo, but they only work together if they are switched on and configured to match how you actually buy, make and ship. A half-configured setup gives you dates that look automated and are still wrong.
Quick checklist
- Sales quotes dates from the available/forecasted figure, never from raw on-hand.
- Purchase lead times are set per supplier, and manufacturing lead times per product, and someone owns keeping them current.
- A confirmed order that needs stock triggers the purchase or production order automatically, so the dates chain end to end.
- Multi-line orders show a date per line and a clear partial-shipment choice, not one date for the slowest line.
- Expected dates recalculate when a supplier or production date moves, and a slip raises a flag in time to warn the customer.
- The team is trained to promise the date you can keep, not the earliest date that wins the order.
FAQ
Why can't I trust the stock number when I promise a delivery date?
Because the on-hand figure is not what is available to sell. On-hand counts everything physically in your warehouse, including units already reserved for other confirmed orders, stock in a quality hold, and the wrong variants. The number you can safely promise against is the available or forecasted quantity: on-hand minus what is already reserved, plus what is genuinely inbound with a confirmed arrival date. Promising against on-hand means promising stock you may have already sold.
How does Odoo calculate a reliable delivery date?
Odoo builds the date from real data instead of a guess. It nets your reservations and confirmed incoming receipts against on-hand to give a forecasted available figure, and it adds the lead times you set per product and per supplier (purchase lead time, manufacturing lead time, sales lead time). If stock is available, the date is your pick-and-ship time. If it is not, a confirmed order can trigger the purchase or manufacturing order automatically and the date becomes supplier or production lead time plus shipping. The date is only as good as the lead-time data behind it.
Should I promise the whole order on one date or per line?
Per line, in almost every case. A multi-line order where most lines are in stock and one is on backorder should not get one date based on the slowest line, and it should not get an optimistic single date that nine lines meet and one quietly misses. Show the customer which lines ship now and which follow, give each its real date, and agree whether they want a partial shipment now or the complete order together later.
Why do my delivery dates keep slipping even though we set them carefully?
Usually because the date is frozen at order time and never updates, or because the lead-time data behind it has drifted. A supplier delay or a production reschedule changes reality, but a static confirmation still shows the old date and nothing flags the change. Use scheduling that recalculates expected dates when inputs move, so a slip shows up as a flag while there is still time to warn the customer, and assign someone to keep lead times current so they do not rot.
Is it better to quote a later date I can keep or an earlier date to win the order?
Quote the date you can keep. The earliest date that wins the order is worthless if you miss it, because a customer you call twice to move the date trusts you less than a competitor and puts your next order out to tender. A reliable date, even a slightly longer one, is what makes a customer reorder without shopping around. Reliability compounds; one missed promise costs you the margin on every order after it.