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.

Figure 1Handover checks before the production slot starts

• Do: Agreed scopematches the accepted offer version
• Do: Source inputscomplete enough for the first task
• Do: Responsibilitydrafter, reviewer and customer contact know their roles
• Do: Decisionsapprovers available during review
• Do: Scheduledependencies fit the current calendar
• Do: Start conditionsacceptance and initial payment verified
• Ask: Open riskthe disputed inclusion: resolve or exclude

Start with a short kick-off

A thirty-minute kick-off conversation at the start of delivery saves far more time than it takes. It is not a repeat of the sales discussion. Its job is to confirm the starting point with the people who will actually take part.

Figure 2A thirty-minute kick-off

1. 1Confirm the accepted scopeoutputs, exclusions, version
2. 2Walk through the inputswhat has arrived, what is missing
3. 3Name the roleswho drafts, who reviews, who approves
4. 4Agree the datesreview windows and the final handover
5. 5Agree how updates will be sentchannel and rhythm

For Harbour Services, the kick-off includes the nominated contact who will consolidate feedback, and ideally the owner for the few minutes needed to confirm that the disputed inclusion will be decided by a set date. Hearing the dates and roles together, and agreeing them aloud, makes them far more likely to hold than the same information sent in an email.

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.

Look after the customer’s information during the work

Delivery often means handling the customer’s internal documents: draft service rules, pricing notes, staff instructions and sometimes examples of customer correspondence. Treat them with care. Keep them in one place with access limited to the people working on the job, avoid copying them into personal email or unmanaged devices, and do not reuse any part of them in another customer’s work.

Ask the customer to remove personal details from examples before sending them, and remove any that arrive anyway once they have served their purpose. If an external reviewer is involved, share only what that person needs, as agreed in the offer. At the end of the job, return or delete the working material according to the agreed approach and confirm that you have done so. These steps are rarely noticed when they are done well, and they matter a great deal to a customer if they are not.

Report progress on a predictable rhythm

Customers worry less when they know when they will next hear from the business. A short update on an agreed day, weekly for a job of this size, works better than occasional long reports or silence followed by a finished draft.

Keep each update to four points: what was done since the last update, what will be done next, anything the customer needs to do and by when, and any risk to the agreed dates. When nothing has changed, say so briefly; a two-line message that confirms the plan still holds is useful in itself. Updates sent this way also form a record of the job, which helps later if a question arises about when something was requested or supplied.

Check the work before the customer sees it

Each draft should pass an internal check before it reaches a reviewer. For Fieldnote’s documents, the check is short and specific:

Figure 3Internal check before a draft goes to the customer

• Avoid: Every inclusion matches the approved service rules
• Avoid: Package names are used the same way throughout
• Avoid: Each document fits its agreed length and purpose
• Avoid: Plain language: no internal jargon or undefined terms
• Avoid: Spelling, numbers and contact details checked
• Do: x Open questions for the customer listed separately

The person who drafted the work is the worst person to check it, because they read what they meant rather than what they wrote. Where two people are available, the other one checks. Where only one is, leaving a day between drafting and checking helps. Listing open questions separately, rather than burying them in the draft, lets the reviewer answer them directly instead of discovering them by chance.

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.

Figure 4What kind of request is this?

?Where did the difference come from?

Unclear wordingClarificationexplain or adjust within scope

Supplier error against approved inputCorrectionfix it; it was part of the promise

New requirementChangeassess time, price and dates before agreeing

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.

Figure 5The price of an unpaid yes

Original packageA$960 contribution

After five unpaid extra hoursA$535 contribution

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.

Watch the hours against the estimate as you go

The estimate from Chapter 5 is most useful during delivery, not only after it. Compare the hours used with the progress made at natural points in the job, and act early if they diverge.

This is an illustration. The estimate allowed 24 hours. Halfway through the drafting stage, Fieldnote has used 12 hours but has drafted only about a third of the material, because the source documents needed more reconciling than expected. At that rate, the job will take well over the estimate. Spotting this at the halfway point leaves options: raise the input problem with the customer, narrow a section by agreement, or accept the overrun as a known cost and record why. Discovering it at the end leaves only the last option, and no lesson for the next estimate.

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.

Hand over so the customer can keep it current

A document package is only useful while it stays accurate. Services change, prices move and new staff join. If the customer cannot update the material themselves, it will drift out of date, and the original problem will return.

Fieldnote’s handover therefore includes more than the final files. It supplies the documents in a format the customer can edit, a short note explaining where each piece of information came from, and a list of the things most likely to change, such as package names and inclusions, with the places in each document where they appear. The handover discussion walks the nominated contact through making one small update, so that they have done it once with support.

None of this was an extra service; it was part of the agreed handover. Writing it into the scope from the start, as Chapter 6 recommended, means it is planned and priced rather than squeezed in at the end. It also makes the customer more independent, which may seem to reduce repeat work but in practice builds the kind of trust that brings customers back for the work they genuinely cannot do themselves.

Close the job clearly

A job without a clear ending tends to linger. Small requests keep arriving, the final invoice waits, and neither side is sure whether the work is finished. A short closing message prevents this.

The message confirms that the agreed outputs have been delivered, lists the final versions, notes any agreed limitations or open items, confirms that the final invoice has been issued or paid, and explains how to request further work if needed. It also mentions the agreed review point from the next chapter, if there is one.

Internally, closing the job means updating the pipeline record to its final state, recording the actual hours and any incidents, and archiving the working files with the final versions clearly marked. Those few minutes produce the evidence the review needs, and they make sure the job does not reappear months later as an unexplained entry in the delivery calendar.

When something goes wrong, say so early

Mistakes happen in delivery: a section built on an outdated rule, a missed review date, a file sent to the wrong person. How the business responds matters more to the customer than the mistake itself.

Tell the customer promptly, in plain terms, what happened, what it affects and what will be done about it. Avoid both minimising (“a small hiccup”) and over-dramatising. If the mistake was the business’s, fix it at the business’s cost, as the correction category above describes. If it arose from a customer input, explain that without blame and agree the next step.

Record the incident and its cause in the delivery record. A single mistake is an event; the same kind of mistake on two jobs is a process to change. Fieldnote’s habit of noting the cause of each correction is what lets the next chapter’s review turn delivery experience into a better offer.

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.