From blind drop?ship commits to OMS ATP checks (API/EDI), SLA?gated, fewer cancellations

Overview

A home goods retailer struggled with frequent stockouts and late cancellations when relying on drop-ship partners. Supplier confirmations were delayed or misaligned with reality, so the Order Management System (OMS) committed orders that vendors could not fulfill. Intelligex implemented an order orchestration layer that checked supplier Available to Promise (ATP) via API or Electronic Data Interchange (EDI) before commitment, enforced confirmation service-level agreements (SLAs), and routed exceptions with clear rules. Customer promises reflected actual capacity, vendor acknowledgments were timely, and customer service handled fewer cancellations and surprises.

Client Profile

• Industry: Home goods and furnishings retail with e-commerce and marketplace drop-ship
• Company size (range): National retailer with a broad assortment and mixed fulfillment methods
• Stage: Established OMS and e-commerce platform with growing drop-ship network
• Department owner: Procurement, Supply Chain & Logistics
• Other stakeholders: E-commerce, Vendor management, Customer service, Finance, IT applications, Distribution centers

The Challenge

Drop-ship partners provided assortment breadth but introduced uncertainty. Vendors confirmed purchase orders by email or via EDI acknowledgments on a delay, and inventory advice did not reflect actual ATP. The OMS committed orders to vendors immediately after checkout, and when a vendor later declined or only partially confirmed, customer service had to cancel or split orders. Promise dates drifted, and buyers lost confidence in vendor reliability because there was no consistent view of confirmations or reasons for misses.

Replacing the OMS or e-commerce platform was not feasible mid-season. Vendors ranged from API-ready partners to small suppliers using batch EDI or email. The retailer needed a lightweight orchestration layer that could sit on top of existing tools, standardize ATP checks and confirmations, enforce SLAs, and provide a clear path for rerouting to alternate suppliers or in-house stock when vendors could not meet the promise. Any solution had to improve signal quality without slowing checkout or overhauling partner integrations.

Why It Was Happening

The core issue was fragmented and stale data. Inventory advice and confirmations arrived on different cadences and in different formats. Some vendors sent EDI acknowledgments that did not align with current ATP, while others replied by email without structured data. The OMS accepted orders without a real-time verification step, and backorder logic varied by category. There was no single state machine that tied vendor ATP, order commitment, and confirmation timing together with clear ownership.

Catalog and master data also played a role. Item identifiers, variants, and pack sizes did not always map cleanly between the retailer and vendors, which produced false availability or partial confirmations. Promise dates were calculated without considering vendor cutoff times or capacity. Customer service saw status after the fact, and phone calls to vendors became the default escalation path.

The Solution

Intelligex delivered an order orchestration layer that mediated between the e-commerce checkout, OMS, and vendor systems. At order capture, the orchestration checked vendor ATP via API or recent EDI advice, gated commitment until a confirmation or reservation was received, and started SLA timers. If a vendor failed to confirm within the agreed window or declined, the system evaluated alternates—other vendors or in-house inventory—and rerouted based on rules and cost. Human-in-the-loop review handled split shipments, substitutions, and high-cost expedites. The approach preserved existing systems and connections while enforcing a consistent confirmation process.

• Integrations: Bi-directional connections with the OMS and e-commerce platform for order capture, promise, and updates; vendor-facing APIs using the OpenAPI Specification; EDI adapters for partners using common transaction sets aligned with X12 guidance; optional use of GS1 EDI conventions where required.
• Canonical data model: Standardized item, vendor, and promise attributes with mapping for vendor SKU, pack, color/size variants, and cutoff times; date-time fields normalized to ISO 8601.
• ATP and confirmation workflows: Real-time API calls for ATP where available; scheduled EDI pulls for inventory advice; soft reservations at checkout that convert to firm commitments upon vendor acknowledgment; SLA timers by vendor and category.
• Routing and fallback: Rules to reroute to alternate vendors or in-house distribution centers when ATP is insufficient or SLAs are breached; configurable priorities and cost thresholds with human approvals for exceptions.
• Validations and guardrails: Checks for mismatched SKUs, units of measure, and discontinued items; prevention of commitment without acknowledgment for sensitive categories; alerts for partial confirmations and substitutions.
• Customer promise and messaging: Updates to the e-commerce promise date once a vendor confirms; proactive notifications for delays; reason codes captured for transparency to customer service.
• Dashboards: Vendor SLA adherence, confirmation latency by category, reroute outcomes, cancellation reasons, and exception aging visible to vendor managers and customer service leaders.
• Permissions and audit: Role-based access for vendor managers, buyers, customer service, and IT; immutable logs of confirmations, overrides, and reroute decisions with reason codes.

Implementation

• Discovery: Mapped the end-to-end flow from checkout to vendor ship confirm; inventoried vendor capabilities (API, EDI, email); cataloged item mapping issues; documented current cutoff rules, SLAs, and backorder logic; identified categories with the most cancellations.
• Design: Defined the event schema for order capture, ATP check, acknowledgment, reroute, and ship notice; modeled the canonical item and vendor attributes; established SLA timers and escalation paths; aligned a shared glossary for statuses and reason codes across procurement, customer service, and vendor management.
• Build: Implemented orchestration services and connectors to the OMS and e-commerce platform; built vendor API endpoints and EDI adapters; configured routing rules, validations, and SLA timers; created dashboards and an exception console.
• Testing/QA: Replayed historical orders and vendor responses in a sandbox; validated ATP checks against vendor systems; ran parallel confirmation flows in observe-only mode; exercised human-in-the-loop decisions for splits, substitutions, and expedites to fine-tune rules.
• Rollout: Onboarded a cohort of high-volume vendors first; kept the legacy path as a fallback; enabled promise gating for selected categories; expanded coverage as SLA adherence and exception rates stabilized.
• Training/hand-off: Scenario-based training for vendor managers and customer service; quick guides for exception handling and reroute approvals; vendor communications outlining API/EDI expectations and SLAs; transitioned operations to supply chain and e-commerce teams with IT on call.

Results

Order commitments began to reflect real availability. Vendors confirmed against current ATP, and the orchestration enforced timing and data quality before promises were exposed to customers. When a vendor could not meet the expectation, reroute rules identified alternates quickly, and customer service saw a clear status and next step instead of discovering the issue after a missed ship date. Cancellations dropped and messaging set realistic delivery expectations.

Vendor relationships became more structured. SLAs were monitored with shared dashboards, exceptions were documented with reason codes, and catalog mapping issues surfaced early. The retailer maintained its existing OMS and e-commerce stack while adding a thin layer that improved signal quality, reduced rework, and enabled faster, better decisions about holds, releases, and alternates.

What Changed for the Team

• Before: Orders were committed to vendors at checkout; After: Commitments were gated by verified ATP and confirmed acknowledgments.
• Before: Vendor confirmations arrived by email or delayed EDI; After: API checks and scheduled EDI pulls created predictable confirmation windows with SLA timers.
• Before: Customer service learned about misses after ship dates; After: A shared console surfaced exceptions early with reason codes and reroute options.
• Before: Catalog mismatches caused false availability; After: Canonical item mappings and validations prevented errors before commitment.
• Before: Rerouting was ad hoc; After: Rules drove alternate sourcing with human approvals for split shipments, substitutions, and cost-sensitive moves.

Key Takeaways

• Gate order commitment on verified vendor ATP and acknowledgments rather than assuming availability.
• Enforce confirmation SLAs and capture reason codes so vendor performance can be managed with facts.
• Preserve existing OMS and commerce tools; layer orchestration and validations to improve signal quality.
• Support both APIs and EDI so partners of different maturities can participate without friction.
• Define reroute logic and human-in-the-loop checkpoints for costly or customer-impacting exceptions.
• Start with high-impact vendors and categories, then expand as mappings and SLAs stabilize.

FAQ

What tools did this integrate with?
The orchestration layer connected to the existing OMS and e-commerce platform for order capture, promise updates, and fulfillment status. Vendor ATP and confirmations flowed via APIs defined with the OpenAPI Specification, and via EDI aligned with X12 and GS1 EDI conventions where required. Distribution center inventory and shipments remained managed in the existing Warehouse Management System (WMS), with signals consumed by the orchestration for reroute decisions.

How did you handle quality control and governance?
We enforced validated state transitions from order capture through acknowledgment and shipment. SLA timers triggered alerts and escalations, and exceptions required reason codes. Sensitive moves—such as substitutions, split shipments, and cost escalations—passed through human-in-the-loop approvals. All changes and decisions were logged immutably with user identity, context, and timestamps for audit and vendor reviews.

How did you roll this out without disruption?
We launched in parallel with the legacy confirmation process for a select group of vendors and categories. The orchestration ran in observe-and-recommend mode while the legacy path executed. Once results matched expectations and vendors adapted to the cadence, we enabled promise gating and expanded coverage. The legacy path remained available as a fallback during the transition.

What about suppliers without APIs or modern EDI?
We supported multiple integration paths. Vendors with APIs used documented endpoints and auth; EDI-capable partners sent inventory advice and acknowledgments on a defined cadence; smaller partners accessed a lightweight portal to confirm availability and lead times. All paths fed the same state machine and SLA timers, so performance and exceptions were measured consistently.

How were customer promises updated in the storefront?
At checkout, the orchestration generated a provisional promise based on vendor cutoffs and recent ATP. Once a vendor acknowledged, the promise was confirmed and written back to the e-commerce platform and OMS. If a vendor declined or missed the SLA, reroute logic updated the order and the storefront received revised dates. Customer service and the customer both saw consistent status messages tied to the same events.