Declaring an emergency — Adapting an aviation concept for contract negotiations

A software-vendor client was on the verge of making a big sale to a potential marquee customer. The negotiations hit a snag, though, over the issue of customer-support response times.

The customer’s procurement people wanted the vendor to make a firm commitment that it would fix any bugs in the software within a certain amount of time — and that amount of time might be unrealistic in some situations.

We broke the impasse by reaching beyond the boundaries of software support. More about how we did so after the jump.

Borrowing a concept from the aviation world

If a pilot declares an emergency:

… Skies are cleared, runways are made available, fire and rescue equipment is mobilized, search and rescue teams are alerted. The pilots of the aircraft in trouble are given complete freedom to work on the problem and choose the best course of action, and everyone else follows. It is quite impressive to observe how much everyone works together to save an airplane in trouble.

A pilot declaring an emergency is always given the benefit of the doubt. Nobody questions whether he has a good reason or not to declare an emergency. If the pilot feels he needs to declare, then he does so. There will be plenty of time to analyze his actions later on, but until he’s safely on the ground, he does what he wants, and everyone assumes that he has a good reason to declare an emergency.

With that in mind, we revised the draft contract so that:

• The vendor gave the home- and cell-phone numbers of its chief sales officer (CSO) to the customer’s CFO.
• If the customer’s CFO — and only the CFO — personally called the vendor’s CSO to declare an emergency, then the vendor would go into all-hands-on-deck mode, and the vendor’s CSO would personally make progress reports to the customer’s CFO, on a twice-daily or even hourly basis if requested.

That did the trick; the companies signed the revised contract. (As it turned out, the vendor’s product worked fine, and the customer never did have to declare an emergency.)

The incentives align

We didn’t think of it at the time, but in hindsight it seems clear that this arrangement provided some useful incentives for performance by all concerned:

• It was impossible to contractually specify a problem-resolution deadline in advance, because there was no way to know how serious the customer’s business problem would be, nor how intractable the technical problem might be.
• The senior executives were busy people and wouldn’t want to spend their scarce time on non-emergencies of this kind.
• The front-line troops of each company would not want their senior executives to get involved with a non-emergency problem right away: The senior executives would inevitably be at least mildly annoyed at being dragged in, and might question why their people hadn’t been able to resolve the problem on their own.
• The customer’s CFO probably would not want to be perceived as the boy who cried wolf.
• The vendor’s CSO would not want his personal reputation to be damaged by non-performance on the vendor’s part.
• If a real emergency did arise, the senior executives’ personal attention would keep all hands focused on promptly identifying and resolving the problem.

Meta-lesson: If you can’t agree on an outcome, try agreeing on a process

This was just one example of a type of situation that’s fairly common in contract negotiations: The parties don’t really know what they should “carve in stone” in the contract language. This could occur because the parties don’t know (or disagree about) what’s feasible. It could also occur if one or both parties doesn’t know what it might want in an actual event.

In that type of situation, often illustrates the principle that if the parties can’t come to agreement about a desired outcome, perhaps they can agree instead on a reasonable process for getting through the situation.