SLAs and Expectations for Partner File Exchange

"We always assumed you guaranteed this." It is half past seven, the payroll file is late, and the sentence has just been said on a call with four people on it. Every partner file exchange already has service expectations. The only question is whether they are written down. If they are not, they still exist in the partner's head and in your business team's assumptions. They also exist in the quiet dependency some downstream system has on a file landing before its morning run. Unwritten expectations have a signature failure mode: they surface for the first time during an incident, at maximum temperature, usually in exactly that sentence.

A service level agreement, an SLA, is nothing more exotic than those expectations written down in terms both sides can test. When did we promise the file? How fast do we answer when something breaks? How much warning before maintenance? Written well, an SLA prevents arguments instead of winning them. That is because the answer to "was this a miss?" becomes a lookup, not a negotiation between two annoyed teams with different memories. Memories, in a dispute, agree remarkably well with whoever is holding them.

This article shows you how to write partner exchange expectations you can actually keep. It covers which terms belong in the document and how to convert vague promises into measurable ones. It shows how to measure what you promised before the partner does. It also covers the incident and maintenance communications that protect trust when (not if) something slips. It is part of our B2B Partner Exchange series. It pairs with the register and timing conventions from running partner exchange as a program. By the end, the half-past-seven call should be a lookup too, and a shorter one.

The Working SLA Is an Operational Document

First, a scope clarification that saves a lot of grief. The contract between your companies may contain service language written by lawyers — penalties, liability, force majeure. That is not what you are writing. The working SLA is the one-or-two-page operational appendix the technical teams on both sides actually use: file names, times, contacts, notice periods. It travels in the onboarding packet, sits beside the partner's register row, and gets read during incidents. Where a legal document exists, the working SLA must agree with it. Where none exists — most mid-sized partner relationships — the working SLA is the record. It is far better than nothing precisely because both sides saw it before they needed it. The contract is for the dispute. The working SLA is for Tuesday.

Two properties make a working SLA worth the paper. Every term is measurable — a stated file, time, timezone, and count that either happened or did not. And every term is kept deliberately modest. You promise what your infrastructure and staffing can honestly deliver on a bad week, not what sounds impressive in a kickoff meeting. An SLA you routinely miss is worse than none at all, because it converts ordinary operations into a record of broken promises. I have signed one of those; we missed it in the first month, and in most months after.

The Terms Worth Writing Down

Eight terms cover nearly every partner exchange relationship. For each, the working SLA states a concrete value; the next section shows what concrete looks like.

• Delivery windows and cutoffs. For each flow, state which file, in which folder, by what time, in which named timezone, on which days. State what happens to a file that arrives after the cutoff (usually: processed next cycle, not lost).
• Freshness. State how recent the data inside the file must be. A file can arrive on time and still carry stale content if the extract ran early or reran from old data. State when the content is generated relative to delivery.
• Endpoint availability. When your server is reachable for partners who connect to you — normally around the clock — and the standing maintenance window that interrupts it.
• Support hours and response times. When humans answer, how fast a report is acknowledged, and how often updates flow until resolution. Acknowledgment and resolution are different promises; only the first is fully yours to control.
• Incident notice. When you will tell the partner something on your side broke that affects them — ideally before they notice.
• Maintenance notice. How much warning precedes planned changes, and through which channel.
• Retry behavior. How long and how often the sending side retries before a human is alerted, so both teams know when silence means "still retrying" versus "given up."
• Escalation contacts. The named people and shared mailboxes on both sides, per severity — the same contacts your register already holds.

One refinement worth adopting early: not every flow deserves the same promises. Grade flows into two or three tiers. These include the payroll file whose lateness costs real money, the routine feed where a day's slip is absorbed, the courtesy extract nobody would notice missing for a week. Attach the strict response and notice terms only to the top tier. Tiering keeps your strongest promises affordable and stops the working SLA from treating every file as an emergency. Treating every file as an emergency is the fastest way to have no file treated as one.

Just as important is what stays out. Do not promise availability theater. A single transfer server cannot honestly offer extreme uptime guarantees, and partners do not need them. They need to know the maintenance window and how outages are announced. Do not promise resolution times for problems whose cause might be on the partner's side. And do not write terms for flows you cannot observe: a promise about something you do not measure is a liability wearing a bow tie.

Vague vs Measurable: Rewriting the Usual Promises

The difference between an expectation and an argument is precision. Here are the six promises that appear in almost every partner relationship, in the vague form they usually take and the measurable form the working SLA should use. Copy the right-hand column's shape for your own flows.

Notice the pattern in every measurable version: a named artifact, a clock with a timezone, a count, and a defined behavior at the boundary. Anyone — including a script — can check each one. That is the test to apply to any term you draft: could a monitoring job evaluate this sentence? If not, keep rewriting. The habit of stating every schedule with a window, cutoff, and timezone should already be your program's convention, set in the standards menu.

Measure What You Promised — Before the Partner Does

An SLA without measurement is a document that only your partner is checking. The operational rule that follows is simple: every written promise gets a corresponding check, armed on the day the promise starts. Walk the SLA line by line and build the promise-to-check map:

• Delivery windows map to expected-file checks. A watcher raises a flag when ALPINE_orders_YYYYMMDD.csv has not appeared by 06:00. That catches the miss at 06:01, hours before a business team asks. The mechanics of these freshness checks — expected files, arrival windows, and the traps around weekends and holidays — are covered in freshness checks and expected files.
• Outbound windows map to job monitoring. Your sending jobs run on schedules, so a job that fails or overruns its window is the promise breaking in real time. Scheduled jobs in Sysax FTP Automation can email on failure, which converts "we missed our window" from a partner's discovery into your morning's first notification. Silent job death is the classic way outbound promises fail — see why jobs fail silently.
• Availability and response promises map to the timestamps in your ticketing and monitoring trail: when the outage started, when the announcement went out, when the report was acknowledged.
• Every promise ultimately maps to the server's own record. A server that logs partner activity to a file or a database — as Sysax Multi Server does — holds the neutral evidence. It records when the file actually arrived, when the partner actually fetched, from which address. When memories differ, the log is the referee both sides accept.

Once the checks exist, the monthly numbers fall out nearly free, per partner, per flow. They show deliveries on time versus late, incidents and their acknowledgment times, maintenance notices sent versus promised. Keep them simple enough to produce without heroics (a fuller treatment of turning transfer logs into recurring reports is in transfer dashboards and reporting). Their main use is the service review below — and the quiet confidence of answering any partner claim with data. Data has settled more partner calls than charm ever will.

Kestrel Payroll found out who was measuring their SLA when Bluewater Bank's service manager arrived at a review with a spreadsheet. The payments file had been promised by six in the morning at a kickoff meeting two years earlier. It had been late one Monday in three for most of a year. The bank had arrival times to the minute, and Kestrel had a feeling that things were mostly fine. Nobody at Kestrel had built the check, because nobody remembered making the promise. The fix took a day. It included an expected-file check at the cutoff and a look at the job history that showed the Monday extract colliding with a weekend maintenance job. It also included a renegotiated window that matched what downstream actually needed. The bank was gracious about it. The spreadsheet was not.

Incident Communication: The Template

SLA misses are survivable; silence is what erodes trust. Partners forgive a late file announced early far more readily than an on-time record punctuated by unexplained gaps. The working rule: when the miss is yours, the partner hears it from you before they notice it themselves. Your expected-file checks make that possible, since you learn of the miss at the cutoff minute. I have never had a partner complain about being told too early.

Do not compose incident notices from a blank page at two in the morning. Keep a template with fixed fields, three messages long:

INITIAL NOTICE  (send as soon as impact is confirmed)
  Subject: [Ref FX-0217] Delay: ALPINE orders file for today
  What happened .... : Our nightly extract failed at Mar 14 02:10; orders file
                       will miss the 06:00 window.
  Who is affected .. : Inbound orders flow only; other flows run normally.
  What we are doing  : Extract rerun in progress.
  What you should do : No action needed; do not resend anything.
  Next update by ... : 08:00, or sooner on material change.
  Contact .......... : partner-exchange@example.com

UPDATE  (repeat at promised interval until resolved)
  Subject: [Ref FX-0217] Update: rerun 80% complete
  Status ........... : On track; revised delivery estimate 09:30.
  Next update by ... : 10:00.

RESOLUTION  (closes the reference)
  Subject: [Ref FX-0217] Resolved: orders file delivered 09:12
  Outcome .......... : File delivered and verified complete.
  Cause (brief) .... : Database maintenance overran into the extract window.
  Prevention ....... : Extract start moved later; monitoring added on the
                       maintenance job.
  Logged as ........ : SLA miss for Mar 14 (will appear in monthly numbers).

Four habits make the template work. Give every incident a reference the partner can quote. Always name the next update time — a promised silence is calm, an unpromised one is alarming. Tell the partner explicitly whether they need to act, because their operators are deciding whether to resend, rerun, or wait. And log the miss against your own SLA numbers in the resolution note. Self-reported misses build more credibility than a spotless record the partner does not believe. Nobody believes a spotless record. Nobody should.

Maintenance and Planned Change

Planned work gets the courtesy incident response cannot: notice. The working SLA states the standing maintenance window. Pick a quiet one from your flow schedules — the register tells you when partners actually connect. The SLA also states the notice period for anything outside that window, in words both sides can count. That means five business days for routine windows, several weeks for anything requiring partner-side work.

A useful maintenance notice answers four questions in four lines. These are when (window with timezone), what (which endpoints or flows are affected and how), whether the partner must do anything, and what happens if the work rolls back. The changes that deserve the longest runway are the ones that touch the partner's stored configuration. These include endpoint names, ports, protocols, and above all host keys and certificates. Their software has pinned those host keys and certificates and will loudly distrust them when changed without warning. Changes to that stored configuration are migrations in miniature. The full communication playbook — notice sequencing, test windows (run them as described in partner test windows), the partner who never answers — is in partner communications for a migration.

Expectations Run Both Ways

A working SLA that only binds your side is a complaint form. The same document states what you expect of the partner, in the same measurable shapes. Their files must be delivered by their cutoffs and pickups collected within the window. A pickup pattern where the partner fetches means their lateness looks like your miss to their business team — write the fetch-by time down. Their contacts must be kept current. State their incident notices to you when their side breaks, and their response time when your quarantine bounces a malformed file back to them.

Bilateral terms change the tone of the relationship. Service conversations stop being complaint sessions and become two teams reading one scorecard. And when a partner chronically misses their side, the evidence comes from the same logs and checks as your own numbers. Think of the file that is late three Mondays out of four. The shared evidence keeps the conversation factual and short. Chronic misses, in either direction, are a signal to renegotiate the term rather than to keep recording the miss. Sometimes the honest fix is admitting the 06:00 cutoff was always fantasy and moving it to 07:00. That costs nothing if downstream can absorb the change and was already absorbing it informally. Most cutoffs were chosen by someone who has since left the meeting.

Run a Light Service Review

Expectations decay without a rhythm, so put one on the calendar: a short service review per significant partner. Quarterly is a common cadence, annually for low-volume relationships. Walk the numbers together: deliveries against windows, incidents and response times, maintenance notices given, upcoming changes on either side. Fifteen minutes when things are healthy. The review is also where the working SLA gets amended, because both sides are looking at the same evidence and the same document. Partners without a review rhythm drift: contacts go stale, informal workarounds ossify, and the SLA becomes one more document describing a system that no longer exists.

Bring three things and nothing else: the one-page numbers, the list of misses in both directions with their references, and any change either side has coming. Skip the reviews that would review nothing. A partner with a clean quarter gets an email with the numbers and an offer to meet, which most will decline gratefully. The rhythm's value is that it exists and everyone knows it exists. A missed cutoff in week two is easier to raise when both sides know the numbers surface in week thirteen regardless. Week thirteen is an excellent motivator and a terrible surprise.

Promise Less, Keep More

The craft of partner SLAs is restraint: a short list of terms, each measurable by a job or a log line. Each is modest enough to keep on a bad week. They are backed by checks that tell you about misses before partners do. A three-message incident template trades silence for reference numbers. Honest self-reported numbers and a light review rhythm keep the document alive. Write less, promise better, and measure everything you sign. The half-past-seven call still happens; it is just shorter, with one set of numbers.

The expectations you write here get set at the very start of each relationship. The SLA summary rides in the onboarding packet from the partner onboarding runbook. Those expectations end cleanly too: retiring a partner's promises and their monitoring is part of offboarding partners without breakage. The register that anchors every term to a partner and a contact is built in running partner exchange as a program.

Frequently Asked Questions