Carry the promise into delivery

The customer experiences one business even when several people handle the enquiry, proposal and delivery. A promise lost between those activities is still the business’s promise. Handover is therefore part of fulfilling the sale, not an administrative step that can be skipped when the team is small.

Fieldnote’s two partners may both have attended the customer conversation, yet remember different details. One recalls the original brochure request; the other recalls the later decision to prioritise a staff reference. The accepted version of the offer, supported by the decision record, needs to resolve that difference before work begins.

Establish a shared starting point

Create one delivery record linked to the accepted offer. It should identify the intended result, outputs, constraints, customer inputs, review responsibilities and commercial conditions relevant to starting. Preserve the accepted version rather than overwriting it as the project evolves.

The last row matters. If an unresolved inclusion affects the core output, marking it as a risk does not make the work ready. Agree whether to pause, narrow the first stage or obtain a decision. A risk register becomes decorative when it merely records problems everyone then ignores.

Check inputs before consuming the production slot

Customer input can be present but unusable. A folder of old documents may contain conflicting versions; a spreadsheet may lack definitions; an approval email may come from someone without the agreed role. Schedule a proportionate input check before the main delivery effort.

For Harbour Services, Fieldnote compares the package names and inclusions across the supplied documents. It identifies one contradiction and asks the nominated contact to resolve it. The team does not quietly choose a rule that sounds plausible. The customer owns the service decision; Fieldnote owns the quality of its treatment of approved information.

If late inputs affect the schedule, communicate the consequence while alternatives remain available. State what is missing, what work it blocks and the options. “We are waiting on you” assigns blame without helping. “The inspection inclusion is still unconfirmed; we can continue the general sections, but final review needs that decision by Thursday” is actionable.

Distinguish clarification, correction and change

Not every customer request is extra scope. A clarification explains an existing requirement. A correction fixes work that does not meet the agreed requirement. A change alters the requirement or adds work beyond it. The distinction depends on the actual agreement and circumstances, not on whichever label protects the supplier’s margin.

Suppose Fieldnote omitted an inclusion that appeared in the approved input. Correcting that omission is not a new service merely because it takes time. By contrast, adding a new package after the documents were drafted may require a separate scope decision. If the original offer was ambiguous, acknowledge that before presenting a charge.

Use a short change record: requested difference, reason, effect on outputs, time and price, alternatives, and approval. Keep the current work safe while the decision is pending. Do not assume a friendly request authorises a new fee or assume that avoiding a fee requires accepting every request without limit.

Evaluate the consequence before saying yes

In Chapter 5, five extra hours beyond all original allowances reduced the A$3,600 package’s planning contribution from A$960 to A$535. Here those hours might arise from an additional document requested after scope agreement. The team should evaluate both the economic effect and whether the time fits.

Possible choices include an agreed paid extension, replacing an existing output, moving the extra work to a later slot or declining it. A deliberate goodwill inclusion can also be a business choice, but record its cost and reason. Repeated unrecorded goodwill makes later estimates unreliable and can create expectations the business cannot sustain.

Before accepting an extension, check whether it changes the original completion date or the customer’s dependencies. A small writing change may require a new approval cycle. Measuring only the time spent editing would miss the schedule effect.

Make review and completion observable

Tell reviewers what decision is needed at each stage. Early review might confirm structure and factual coverage; final review might check approved wording and errors. Sending every version with “any thoughts?” encourages feedback of uncertain scope and timing.

Consolidated feedback should preserve disagreement rather than hide it. If two customer reviewers request incompatible changes, return the decision to the nominated owner. The supplier should not arbitrate an internal policy disagreement by selecting the most recent email.

At handover, identify the final version, the files supplied, any agreed limitations and the person responsible for putting them into use. Confirm that the recipient can open and locate the files. Archive superseded working versions clearly so staff do not accidentally reuse them. Completion against the agreed scope is an operational milestone; it does not remove applicable legal obligations or rights.

Exercise: perform a handover without your memory

Ask whether a colleague could take over the next delivery step using the record alone. They should be able to identify the accepted scope, current version, next decision and unresolved dependency. Fill only the gaps that affect action; do not expand the record into a diary of every conversation.

Delivery produces evidence that the sales process could not provide: actual effort, real input quality and the usefulness of the result. The next chapter uses that evidence to improve the relationship and the next offer.