Most people who have signed a software contract know the response-time SLA as a vendor obligation. The support desk answers a Sev-1 ticket within four hours or credits your account. The clock runs against the supplier because the supplier controls the thing being measured. On the applied-research engagement we ran with a major operator in Oman, we put the same clock on the other side of the table. A 96-hour client-approval deadline went into the contract as a client obligation, and it sat next to a milestone-tranche invoicing schedule. Together they answered a question that quietly sinks a lot of R&D work: what happens to the vendor when progress depends on a decision the vendor cannot make?
Who actually holds up the work
On a support contract the vendor holds the inputs. It has the runbooks, the servers, the on-call rota, so it makes sense to measure the vendor's response time. Research on a client's proprietary data inverts that ownership. We could not label a single borehole image without the client's raw picks. We could not validate a fracture model without the client's expert interpreter agreeing the depth-matching tolerances. We could not deploy anything without access to the client's platform and VPN. In one Phase-3 integration plan a client task simply reads "Pending" against the line that let us start building at all.
When the party who owns the inputs is also the party whose sign-off gates the next phase, the vendor is the one exposed to delay. We do the work, hand over a phase deliverable, and then wait. If that wait is unbounded, an engagement that looks like a 20-month schedule on paper can run far longer, and the vendor carries the cost of the idle team with no contractual recourse. The fix is not to hope the client is fast. It is to write the client's response time into the agreement the same way a support contract writes the vendor's.
The 96-hour clause
So the proposal set a 96-hour client-approval SLA. Once we delivered a milestone artifact, the client had 96 hours to review and either sign off or come back with specific objections. The obligation was symmetrical in spirit to a vendor SLA and opposite in direction: the response-time clock ran against the party who owed the response.
This is not a penalty for its own sake. It exists because approval is on the critical path and approval is not ours to give. A vendor can commit to shipping a deliverable on a date because the vendor controls the work. It cannot commit to a downstream schedule if an unbounded review sits between every phase and the next. The 96-hour cap put a ceiling on the one variable we did not control, which is the only way to make the rest of the schedule mean anything.
Money moves in tranches, and tranches need gates
The second mechanism was milestone-tranche invoicing. The founding scope-and-cost memo split the fee into phase-gated tranches rather than a single lump or a flat monthly retainer. The first tranche was $130,000 payable upfront, framed as 28 percent mobilisation to stand up infrastructure and clean data before any modelling. The next was $104,000 at Month 5, and the one after that $104,000 at Month 10, each tied to a phase deliverable rather than a calendar date alone.
Tranche invoicing and the approval SLA are two halves of the same design. Each tranche invoices when a phase clears its gate, and a gate clears when the client signs off. That coupling is what gives the 96-hour clock teeth. Without the SLA, a tranche could sit unreleased indefinitely behind a review nobody was obliged to finish, so the mobilisation-heavy front load would be the last money we reliably saw. With the SLA, every gate has a maximum dwell time, so the cadence of deliverable, sign-off, and tranche stays bounded. The upfront 28 percent covered the sunk mobilisation cost precisely because the downstream tranches were the part exposed to sign-off risk, and the SLA is what kept that risk finite.
Why unbounded review compounds
The reason a review cap matters more than it first appears is that the delay does not happen once. It happens at every gate, and it accumulates. If the client takes hours past the cap at each of the sign-off gates that feed the tranches, the total overrun is the per-gate excess multiplied by the number of gates:
The instrument below makes that arithmetic draggable. It plots the three tranche gates on a planned schedule and lets you set the review time the client takes at each one. Below the 96-hour cap the schedule holds and the tranches invoice on their planned months. Push the review time past the cap and the excess compounds across the gates into the orange slip band, sliding the finish to the right. Toggle the SLA off and the same review time runs unbounded, which is the state the contract clause exists to make impossible.
The orange band is the whole argument. It is not a measured delay from this engagement; the per-gate hours and the conversion to months are illustrative, drawn to show the mechanism. The sourced facts are the ones the band sits on: a 96-hour SLA, three tranches of $130,000, $104,000, and $104,000, and a 28 percent mobilisation front load. What the picture shows is why the number 96 was chosen at all. The cap is not about any single review being slow. It is about small overruns at every gate summing into a schedule the vendor never agreed to absorb.
The two clauses worth keeping
Two things generalise past this one contract. First, a response-time SLA belongs on whichever party controls the input being waited on, and in research on a client's data that is usually the client. Copying the vendor-side default into an R&D agreement leaves the vendor holding a risk the vendor cannot manage. Second, an approval deadline is inert unless something depends on it. Bolting the 96-hour clock onto milestone-tranche invoicing gave it a consequence, because a missed gate now stalled a payment and a phase, not just a status field. The clause and the cadence only worked as a pair.
None of this substitutes for a client who wants the work to succeed, and no contract term forces a genuinely blocked review to resolve. What the two mechanisms bought was a bounded worst case: a schedule whose slip was capped by a number both sides had signed, rather than open-ended exposure to a decision we did not own.
Limitations
The schedule-slip arithmetic in the instrument is illustrative. The per-gate review hours, the number of gates used for the compounding, and the conversion from overrun hours to months of slip are chosen to show the mechanism, not to report a measured delay from the engagement. The sourced figures are the 96-hour client-approval SLA, the three tranche amounts ($130,000 upfront, $104,000 at Month 5, $104,000 at Month 10), and the 28 percent mobilisation share; the planned-versus-actual finish is a construction on top of those, not an audited outcome. Contract terms here are described in anonymised aggregate and are specific to this engagement's structure and governing law.
References
[1] Engagement proposal, the client-approval service-level term (96-hour approval window). Internal engagement archive.
[2] Founding scope-and-cost memo, milestone-tranche invoicing schedule and mobilisation share. Internal engagement archive.
