What a sales promise looks like from Delivery

PromiseGuard: What is the first thing Delivery wants to know about a new deal?

Head of Delivery: What exactly has been promised and which assumptions were used to make the date. The problem is often not the ambition. It is that the dependencies are invisible.

PromiseGuard: Which commitments create the most pain?

Head of Delivery: Compressed implementation, bespoke integration, customer-dependent milestones and service levels that start before the environment is stable.

PromiseGuard: Why are these hard to see pre-signature?

Head of Delivery: Because each piece sits with a different owner. Sales owns the date, solutioning owns the design, security owns a dependency, the customer owns data readiness. The project only sees the combined reality later.

PromiseGuard: What would make a timeline believable?

Head of Delivery: Named dependencies, owners, evidence and a clear position on what happens when a customer-controlled dependency moves.

PromiseGuard: What is a good repair?

Head of Delivery: Usually not a dramatic change. Phase the implementation, separate custom work, start the SLA after stabilisation, or make a customer dependency explicit.

PromiseGuard: Would Delivery want veto power?

Head of Delivery: No. We want the decision to reflect delivery reality. Sometimes the business should deliberately accept a hard commitment. But it should be a deliberate choice, not an accidental one.

PromiseGuard: What should the record preserve?

Head of Delivery: The version of the promise we agreed was feasible and the assumptions behind it. If those change, the decision should change too.