Sales Promised the Date. Can Epicor Show Whether Operations Can Actually Deliver It?
A customer promise is reliable only when demand, material, capacity, lead time and current execution are considered together. Epicor order promise should become an operational commitment, not a sales-only date.
The short answer
A customer delivery date should be treated as an operational commitment, not only a sales entry. Epicor can support a more reliable promise when the date is considered together with material availability, supplier timing, constrained capacity, routing duration, current job load and known execution risks.
The promise does not need to be perfect. It needs to be based on explicit assumptions that can be reviewed when conditions change.
How this connects to the pillar
The broader plan-to-profit model is covered in Epicor Has the Orders. Can Management See Which Ones Will Actually Make Money?. Customer promise is the first operational commitment in that chain.
A requested date and a capable date are different
The customer may request a date that matters commercially.
Operations still needs to determine whether the date can be executed under current conditions.
If the same field is used to represent both the customer request and the operationally supported commitment, teams can lose the distinction.
Management should know which date represents the customer need, which date reflects current capability and who owns the conversation when the two differ.
Start with the critical path
Not every component or operation deserves the same attention.
Identify what can actually determine completion:
- long-lead material;
- constrained resources;
- outside processing;
- engineering release;
- quality requirements;
- specialist labour;
- customer-supplied information;
- shipping constraints.
A promise is more reliable when the critical path is understood explicitly.
Material availability must include timing
“On hand” is not the same as available for this order.
Material may be allocated to another job, held for quality, stored at another location or required by earlier demand.
Likewise, an open purchase order is not the same as material ready to issue.
Promise logic should consider when the required material is expected to become usable for the job.
Capacity should be checked where it matters
A plant may appear to have enough total capacity while one operation is overloaded.
If the order depends on that resource, aggregate availability is misleading.
The capable date should therefore reflect constrained operations rather than general plant busyness.
This is especially important when several high-priority jobs compete for the same resource.
Use realistic lead-time assumptions
Lead times often become stale.
Supplier performance changes. Setup time changes. Routing assumptions were created for a different product mix. Internal queues expand.
If order promise depends on fixed assumptions that nobody reviews, the date can look precise while being operationally weak.
Review the assumptions associated with repeated late orders.
Separate normal promise from expedite promise
Some customers will request dates that require exceptional effort.
That may be commercially justified.
The important point is to distinguish a normal capable promise from a date that depends on overtime, premium freight, supplier expediting or priority displacement.
Exceptional promises should make the cost and operational consequence visible.
Otherwise premium execution becomes hidden inside normal service expectations.
Recheck the promise when key assumptions move
A promise is not a one-time calculation.
If a critical supplier date changes, a constrained machine fails or another urgent job displaces the order, the original assumptions have changed.
Define which events should trigger review.
That gives sales and customer service an earlier opportunity to manage expectations rather than discovering the problem on the due date.
Avoid promising from local spreadsheets
Sales teams often build side tools when the ERP date is not trusted.
That can create an independent promise process using assumptions that operations does not share.
The better solution is to identify why the Epicor planning evidence is not supporting the decision.
Maybe lead times are weak. Maybe capacity data is too broad. Maybe material status is unclear.
Fixing those inputs is more sustainable than maintaining a second promise model.
Measure promise reliability by cause
On-time delivery is useful, but it does not explain why a promise failed.
Classify misses by cause:
- material delay;
- constrained capacity;
- customer change;
- engineering delay;
- quality issue;
- internal priority change;
- unrealistic original promise;
- shipment/logistics issue.
This helps management improve the promise process rather than treating every late order as an execution failure.
Use promise accuracy in commercial decisions
Some customers or product families may repeatedly require execution outside normal assumptions.
That information can support better pricing, lead-time policy, capacity investment or contract discussion.
Order-promise data therefore belongs in commercial review as well as operations.
A difficult promise is not automatically a bad order, but its cost should be visible.
What management should measure
Useful indicators include:
- orders promised without critical-material coverage;
- orders dependent on overloaded resources;
- promise changes after order acceptance;
- late orders by root cause;
- expedited orders;
- premium freight linked to promise gaps;
- customer-request date versus capable date;
- repeated promise misses by product family;
- lead-time assumptions associated with misses.
The goal is not zero promise changes. It is earlier visibility and more honest commitment.
ACC context
ACC supports Epicor planning and operational improvement with a focus on connecting ERP information to real execution decisions. A reliable order promise is strongest when the date reflects the same material, capacity and process evidence that operations will later use to deliver it. Explore ACC’s Epicor capabilities.
Operational review point
Select ten recent orders that missed their original promise.
Reconstruct what was known when the date was committed.
Was critical material covered? Was the bottleneck loaded? Were lead times current? Did a later exception genuinely change the situation?
Separate weak original promises from later execution disruption.
That distinction shows where the improvement belongs.
Define who owns a promise change
When the capable date moves, the business should know who can change the customer commitment and who must be informed.
Planning may identify the risk, but sales or customer service may own the external conversation. Purchasing may own a supplier recovery action. Operations may propose an alternative sequence.
Clear ownership prevents several teams from maintaining different versions of the expected date.
Protect promise history
Do not overwrite the old date so completely that management loses the history of how the commitment changed.
The exact system design will vary, but the business should be able to distinguish the original request, original commitment and later approved changes.
That history is valuable for customer-performance review and for understanding whether recurring lateness comes from weak initial promise or later disruption.
Review promise rules by product family
Different products may need different promise logic.
Make-to-stock, configure-to-order and highly engineered work can have very different dependencies.
A single generic lead-time rule may be convenient but inaccurate.
Segmenting promise logic by meaningful operating model can improve reliability without requiring every order to be treated as unique.
Use confidence bands instead of false precision
Some orders have predictable lead times and stable materials. Others depend on engineering release, volatile suppliers or shared constrained resources.
Management can reflect that difference by treating promise confidence as part of the decision.
A date with strong material and capacity evidence can be communicated differently from a date that depends on several unresolved assumptions.
The exact method does not need to be statistical. A simple controlled risk classification can help sales understand when a promise needs operational review.
Review early orders that finished comfortably
Promise improvement should not focus only on late orders.
Orders that consistently finish much earlier than promised may reveal overly conservative lead times, hidden buffers or underused capacity.
If the business always promises later than necessary, customer competitiveness may suffer.
Review both misses and excessive early completion so the promise model becomes more accurate rather than simply safer.
Make promise ownership visible in escalation meetings
When an at-risk order is discussed, show both the customer-facing owner and the operational recovery owner. That prevents a common gap where sales assumes operations will recover the date while operations assumes sales will renegotiate it.
The two actions can run in parallel: improve the execution plan and prepare an honest customer conversation.
Use repeated promise misses to improve segmentation
If one product family, route or customer type repeatedly misses dates, the promise model may be too generic.
Segment the evidence before adding more buffer to every order.
A focused rule for the difficult segment can improve service without making the whole business promise more conservatively.
Frequently asked questions
Should sales be allowed to enter requested dates?
Yes. Keep the customer requirement visible, but distinguish it from the operationally supported commitment where needed.
Is capable-to-promise only a system calculation?
No. The calculation is only as useful as the material, capacity, lead-time and process assumptions behind it.
Should an expedited date be accepted if the customer is important?
That is a commercial decision. The operational premium should be visible so management can make the decision consciously.
How often should promised dates be reviewed?
Review when critical assumptions change materially and use exception reporting to focus attention on at-risk orders.