Walmart publishes a 408-page routing guide that every supplier must follow. The thresholds are defined: 90% on-time delivery, 95% in-full. Scorecards track compliance, and the evidence requirements are explicit. When shipments miss the mark, automatic 3% cost-of-goods chargebacks follow. Every supplier trading with Walmart operates under a thoroughly documented accountability structure with clear standards, defined cadence, and named consequences.
Most organizations, by contrast, have no comparable structure for holding their own integration vendors accountable. They have a service level agreement (SLA), and they assume that is enough. It is not.
An SLA defines what happens when a vendor fails. It sets a performance standard and specifies the consequences when the vendor drops below it. What it does not define is
What good performance looks like day to day
Who the right escalation contacts are on both sides
What evidence the vendor should produce to prove the relationship is working
What the handoff looks like when the contract ends
Those are precisely the gaps where vendor relationships deteriorate. Usually not in formal breach events, but in the slow accumulation of unaddressed issues, unclear ownership, and missed evidence that never surfaces in a legal review.
The document that fills those gaps is an accountability protocol, and this article provides a practical framework for writing one. The framework covers electronic data interchange (EDI) managed services, managed connectivity, retailer onboarding, analytics, and master data services, and it applies to any vendor in the category.
The 3-Layer Model: Contract, SLA, and Accountability Protocol
Most vendor relationships operate with 2 of these 3 layers.
Layer | Purpose | Owned by | Referenced when |
Contract | Legal foundation: rights, obligations, payment terms, indemnification, termination | Procurement and legal | At renewal; in formal dispute |
SLA | Performance floor: Minimum acceptable standards, breach conditions, financial remedies | Procurement and legal, alongside contract | When a performance issue escalates to formal dispute |
Accountability Protocol | Operational ceiling: Cadence, evidence standards, escalation triggers, what good looks like | The operational owner of the integration | Continuously, reviewed monthly and quarterly |
Contracts and SLAs are written by procurement and legal teams who typically lack the operational context to define the standards that matter day to day. The protocol is written by the person who owns the integration relationship: the Director of Supply Chain Technology, the Head of Enterprise Applications, or whoever is dealing with the vendor when transactions start failing at 2:00 a.m. before a peak compliance window.
The protocol is not a substitute for the contract or the SLA. It sits alongside them. Its job is to give the contract operational teeth it does not have on its own.
The 7 Components of a Vendor Accountability Protocol
Each component addresses a specific gap that SLAs leave open.
Component | Purpose | What good looks like | Common red flag |
Roles and ownership | Named contacts at operational, account, and escalation levels on both sides | Named individuals with defined response time expectations per tier | "We don't actually know who the right person at the vendor is for X" |
Performance standards beyond the SLA | What success looks like, not just what failure looks like | Transaction-level success rates, compliance window protection, error thresholds tied to retailer requirements | The SLA measures system uptime; no one measures transaction-level success |
Cadence and artifacts | Defined rhythm for operational reviews and the artifacts produced at each | Monthly operational reviews with named metrics; quarterly business reviews with a defined agenda | Reviews happen informally, only when there is a problem |
Escalation paths and triggers | Explicit thresholds for when a routine issue becomes an escalation, and when escalation becomes renegotiation | Written trigger definitions that neither side can dispute | Escalations happen based on frustration, not criteria |
Evidence standards | What proof the vendor produces; what the customer produces to verify | Transaction logs, exception reports, compliance trend data from the vendor; chargeback trend and scorecard impact from the customer | Accountability relies on one side's self-reported metrics |
Change management | How the protocol adapts when conditions change | Explicit revisit triggers: retailer spec changes, volume shifts, new business units | The protocol was written at contract start and has not been touched since |
Exit and continuity | Transition timeline, data portability terms, operational continuity during handoff | 90-day notice period; full data export in standard format within 30 days of notice; a written transition plan | Exit terms were negotiated during contract and nobody has looked at them since |
Component 1: Roles and Ownership
The accountability protocol names people, not positions. Every integration vendor relationship needs a named operational contact for day-to-day issues, a named account manager for escalations that require commercial authority, and a named executive sponsor for remediation and renegotiation conversations. The customer side needs the same structure.
The red flag here is easy to miss on the surface: when something goes wrong, you discover you have been talking to a general support queue rather than a named account team. Named contacts with defined response time expectations by tier give the relationship actual structure, in which account issues are acknowledged within 4 hours during business hours, and escalations are acknowledged within 2 hours. That specificity is the difference between accountability and hope.
Component 2: Performance Standards Beyond the SLA
This is where most protocols do the most work. A 99.9% system uptime commitment means the vendor's infrastructure is up. It says nothing about whether transactions are actually succeeding, whether errors are being caught before they become chargebacks, or whether the system holds during the windows that matter most.
For an EDI managed service relationship, the protocol should define:
Transaction-level success rate (not system uptime): 99.5% or above, measured against actual transactions, not server availability
Error rate: below 1% across all transaction sets
Functional acknowledgment (FA) response time for EDI 997s: within 2 hours during business hours
Peak window protection: zero unplanned outages in the 72-hour window before a trading partner's must-arrive-by date (MABD) or compliance measurement period
Advance ship notice (ASN) accuracy: consistent with the retailer's stated threshold. For example, Walmart's on-time in-full (OTIF) program enforces a 98% threshold; Amazon's varies by program.
These standards should be set with the vendor's input. The goal is not to negotiate an impossible commitment. The goal is to make sure both sides agree on what success looks like before the relationship starts. A vendor that resists transaction-level success rate measurement is telling you something important about how they think about accountability.
Component 3: Cadence and Artifacts
A protocol without rhythm is a filing exercise. The cadence defines when both sides look at the evidence, discuss what is working, and address what is not.
Monthly operational reviews should cover:
Transaction success rates for the period
Top recurring error types and their resolution status
Open escalations and current state
Any upcoming retailer specification changes that will require protocol updates.
These reviews can run 30 minutes if the artifacts arrive in advance.
Quarterly business reviews go deeper:
Compliance trend by retailer over the prior quarter
Analysis of any chargeback impact tied to vendor performance
A review of whether the performance standards in the protocol still match the customer's operational context
A forward look at retailer changes expected in the next 90 days
Both meetings require a defined artifact set. The vendor produces transaction dashboards, exception reports, and compliance trend data. The customer produces chargeback trend analysis and operational team feedback. If either side arrives without their artifacts, the review does not happen. That standard needs to be written into the protocol.
Component 4: Escalation Paths and Triggers
Most escalation processes are implicit. Something goes wrong, the operational team grows frustrated, and eventually a call happens. By then, trust has already eroded and the vendor is managing a relationship problem rather than a technical one.
The protocol defines the thresholds that trigger each level:
Routine issue: A single transaction failure or data error. Resolved by the operational team within the standard response time.
Escalation: 3 or more failures to a single trading partner within a 24-hour period, or a single failure that triggers measurable chargeback risk. Requires named account manager acknowledgment within 2 hours.
Remediation: Recurring failures across multiple trading partners over 2 or more consecutive reporting periods, or any compliance impact at a Tier 1 retailer. Requires a documented root cause analysis and a written remediation plan within 5 business days.
Renegotiation: Remediation plan implemented without measurable improvement; material change in the vendor's service model or ownership; or contract renewal approaching while unresolved issues remain open.
Neither side should be surprised when the conversation moves from one level to the next. Defined triggers make that transition predictable, and predictability protects both parties.
Component 5: Evidence Standards
Accountability based on self-reported metrics is not accountability. The protocol defines what evidence the vendor produces and what the customer produces, and both sets are required before any performance review is considered valid.
Producer | Document / Report | Notes |
Vendor | Transaction logs | Accessible on demand (not summary dashboards alone) |
Vendor | Exception reports | With root cause categorization |
Vendor | Compliance trend data | By trading partner and retailer |
Vendor | System change / outage documentation | Covers any changes or outages during the reporting period |
Customer | Chargeback trend data | Tied to vendor-managed transaction sets |
Customer | Retailer scorecard impact | From any affected trading relationships |
Customer | Operational team feedback | From teams who work directly with the vendor's outputs |
When evidence conflicts, the protocol specifies which source controls and how the discrepancy gets resolved. If the vendor's transaction log shows a successful transmission but the retailer's scorecard shows a compliance miss, the protocol determines which account is authoritative and what the resolution process looks like. This clause is rarely invoked. Its presence changes how both sides approach the evidence they produce.
Component 6: Change Management
Retailer specifications change. Volume grows. New business units come online. Each of these events is a protocol trigger: a prompt to review the performance standards, escalation thresholds, and evidence requirements and update them as conditions warrant.
A static protocol is a dead protocol. The accountability document should specify at minimum:
An annual full review of all 7 components
A triggered review for any retailer spec change that affects the vendor's work
A triggered review for any volume change greater than 20% in either direction
The output of each review is a dated revision to the protocol, not a conversation. One practical note worth flagging is that changes to the protocol do not require renegotiating the contract. They require both sides to agree on updated operating standards, which is a much lower bar.
Component 7: Exit and Continuity
This component matters most precisely when you hope you will never use it. Exit terms that were not defined clearly at the start become bargaining power for the vendor at the worst possible moment: mid-transition, when operational continuity is at risk.
The protocol should define:
A 90-day notice period (a reasonable standard for most EDI managed service relationships)
A full data export in standard format within 30 days of notice
Portability scope covering all historical transaction logs
Trading partner configuration data
Compliance records
An operational continuity commitment during the transition window
The transition plan should exist as a named document, not a verbal assurance. If the vendor can't produce a documented transition plan as part of initial onboarding, that is a meaningful early signal about how the exit will actually go. The Netguru managed services SLA guide covers exit and transition provisions worth benchmarking against in the broader managed services category.
What This Looks Like in Practice
A $200M consumer goods supplier with thirty-two active trading partners, including 6 Tier 1 retailers, uses a fully managed EDI service for all trading partner connectivity, compliance monitoring, and ASN management.
For example, under the SLA alone, a vendor may commit to 99.9% system uptime and a 4-hour response time for critical incidents. Nothing else.
Under a full accountability protocol, the relationship looks like this:
Roles: Named operational contact (response within 4 hours), named account manager (escalation acknowledgment within 2 hours), named VP-level escalation contact for remediation conversations. The customer mirrors this structure at each tier.
Performance standards: 99.5% transaction-level success rate; error rate below 1%; EDI 997 FA responses within 2 hours during business hours; zero unplanned outages in the 72-hour window before Walmart's MABD.
Cadence: Monthly 30-minute operational review (vendor produces dashboard and exception report; customer produces chargeback trend); quarterly 90-minute business review (both sides produce full artifact sets; compliance trend reviewed by retailer).
Escalation triggers: 3 failures to any single trading partner within 24 hours triggers account manager acknowledgment within 2 hours; any compliance miss at a Tier 1 retailer triggers a remediation conversation within 5 business days.
Evidence: Transaction logs accessible on demand; monthly compliance trend reports by trading partner; customer produces Walmart scorecard impact and Amazon compliance data at each quarterly review.
Change management: Annual full protocol review; triggered review for any Walmart routing guide update or volume shift above 20%.
Exit: 90-day notice; full data export in standard EDI format within 30 days; documented transition plan reviewed annually by both parties.
Realistic Standards for EDI and Integration Vendors
What "good" looks like in a fully managed EDI service relationship:
Transaction success rate: 99.5% at the transaction level over any rolling 30-day period
Error rate: Below 1% across all transaction sets; recurring error types escalated with root cause documentation, not just remediation acknowledgment
EDI 997 FA response time: Within 2 hours during business hours; within 4 hours after hours for Tier 1 trading partners
Incident response for Tier 1 failures: Acknowledgment within 1 hour; remediation timeline communicated within 4 hours
Quarterly business review attendance: Named account manager present; dashboard current within 48 hours of the review date
Retailer spec change lead time: Vendor communicates known specification changes at least 30 days before the effective date, with an implementation plan included
These standards reflect a fully managed service model. A self-service model shifts more operational responsibility to the customer, which changes what the protocol should hold the vendor to. The protocol should reflect the actual service model in place, not a generic template that assumes full delegation when the vendor is only providing tooling.
Getting the Protocol Adopted Internally
The accountability protocol is operationally owned, but procurement and legal need to be aligned from the start. The framing that works: the protocol strengthens what the contract already says. It does not replace any existing document or renegotiate the SLA. It gives the contract's performance language operational teeth by defining what evidence gets produced, who reviews it, and what happens when the numbers fall short.
Procurement teams that spent real effort negotiating SLA language are generally receptive to a document that makes that language enforceable in practice. The resistance to anticipate is the concern that a new document creates new obligations. The protocol creates none. It defines how existing obligations get measured and reviewed.
Legal teams care about two things: that the protocol does not contradict the contract, and that it does not create unapproved commitments. Both concerns are easily addressed by positioning the protocol as an operational working agreement that operates within the contract's commercial terms.
For a CIO running a vendor audit of inherited integration relationships, the accountability protocol is the right output of that audit. The audit surfaces what exists. The protocol defines what should exist going forward.
A Note on Applying This Framework to SPS Commerce
This framework applies to every vendor in the supplier integration category. That includes SPS Commerce.
Customers who write accountability protocols and apply them to SPS Fulfillment relationships will find things that work well and, like any vendor evaluated rigorously, things worth discussing and improving.
SPS Fulfillment is built around the operating model that performs against protocols like this one: named account structure, operational review cadence, compliance monitoring with retailer-level visibility, and documented transition processes. We publish this framework because we believe customers should hold their integration vendors to a higher standard than most SLAs require. We welcome being evaluated by it.
The Standard Worth Setting
Customers who write rigorous accountability protocols raise the bar for every vendor in the category. Through discipline: knowing what good looks like, measuring against it consistently, and making the standards explicit enough that both sides can act on them.
Vendors that perform against rigorous protocols keep the relationship. Vendors that do not either improve or lose it. A well-governed vendor relationship is not one where the customer is armed to fight. It is one where neither side has to. The protocol is the document that makes that possible.
Write it, apply it to every integration vendor in the portfolio, review it annually, and apply it to SPS Commerce too. The framework only works as well as you are willing to apply it everywhere.
