Definition

Available-to-Promise (ATP)

Available-to-Promise is the calculation an ERP performs to tell a sales rep how much of a specific item it can commit to a new order without breaking existing commitments. Live ATP is the difference between a useful CRM and a brochure.

Last updated

Definition

Available-to-Promise (ATP) is the calculation an ERP runs to determine how much of a specific item it can commit to a new sales order at a specific date without violating existing commitments. ATP accounts for on-hand inventory, inbound purchase orders, allocated outbound orders, safety stock policies, and lead times.

The output is a single number per item per ship-from warehouse per date: "we can promise N units by this date."

Why it matters operationally

When a B2B sales rep is on a call and asked "can you ship 200 of these by Friday," the right answer depends on:

  • How many units are on the shelf in the warehouse the customer ships from.
  • How many of those are already allocated to other open orders.
  • Whether a purchase order is inbound from the manufacturer with units arriving before Friday.
  • Whether the item has a safety stock policy that holds back units from being promised.
  • Whether the supplier's lead time is reliable.

Only the ERP knows this. The CRM's job is to surface it accurately.

What gets ATP wrong

The default Salesforce + Boomi pattern syncs inventory snapshots into a Salesforce custom object every 15-60 minutes. ATP is then "calculated" in Salesforce against the synced numbers. This produces three failure modes:

  1. Stale on-hand. The synced inventory is 30 minutes old; in a fast-moving warehouse this is wrong by dozens of units.
  2. Missing allocations. Other orders placed in the last sync window are not reflected.
  3. No real ATP logic. Salesforce's custom-object math approximates ATP poorly because the actual policy (safety stock, drop-ship vs branch-stock, substitute item logic) lives in the ERP.

The result is sales reps either over-commit (and apologize later) or under-commit (and lose orders to a competitor whose CRM had the right number).

What live ATP looks like

In an ERP-native CRM, the rep types the quantity in the quote line. The CRM calls the ERP's ATP function with the item, the ship-from warehouse, the requested ship date, and the customer. The ERP returns the real ATP number with the real warehouse allocation logic. The rep sees the truthful answer immediately.

In Factory Labs, this is how every quote works. There is no inventory snapshot in the CRM; ATP is a live ERP call. See /integrations for the per-ERP gateway details.

Trade-offs

  • ERP dependency. If the ERP is down, ATP is unavailable. (Mitigation: short-TTL gateway cache gives a "last known good" fallback.)
  • ATP call cost. Some ERPs charge per API call. Most modern ERPs do not, but a few legacy systems with metered APIs require careful batching.
  • Complex ATP scenarios. Multi-warehouse fulfillment, drop-ship from supplier, substitute items: these are ERP-specific and the gateway has to translate the CRM's quote shape into the ERP's ATP request correctly.
  • ERP Gateway. The CRM service that calls ATP and other ERP functions live.
  • ERP-Native CRM. The architectural pattern that makes live ATP practical.
  • Drop-Ship Order. A related ERP pattern that affects ATP calculation.

Further reading