Business focus

Make the hard choice before the promise grows.

A new request can change a deadline, the work and who must look after it. Make that choice explicit while the customer still has useful options.
Illustration of a focused service offer built around clear aligned capabilities

“Can we add booking?” is more than a button.

Imagine a service website approaching launch. The pages are ready, the enquiry form works and the customer now wants visitors to book appointments directly.

The request makes sense. The decision still needs care: who controls availability, what confirms a booking and who handles a failed notification?

This is an illustrative example. The calendar is the visible feature; the connected work underneath is what the team must understand before it promises delivery.

A calendar above connected layers of people, notifications and mechanisms, beside a simple webpage model.

Find out what the customer needs to change.

Start with the problem behind the request. Perhaps staff spend too long arranging appointments by email. Perhaps customers abandon the enquiry because they cannot see the next available date.

Those are different problems. A better enquiry process may address one; live availability may be necessary for the other. Choose the work after the need is clear.

  • Before booking: who maintains the services, durations and available times?
  • When someone books: what makes the slot confirmed, and what does the customer receive?
  • When plans change: who handles cancellations, mistakes or a missing confirmation?
  • After launch: who tests changes and responds when the booking route fails?

Use the answers to describe the actual addition. The size of the button tells you very little about the responsibility behind it.

Choose a path the team can explain.

Expand the project

Add the work when it is important enough to change the plan. Agree what must be investigated, built and tested, who will do it and how the launch changes. A revised promise should be specific enough to check.

Keep the planned launch

Launch the agreed website and consider booking separately if the existing enquiry route still meets the immediate need. State what customers can do at launch and when the later decision will be reviewed.

Bring in a specialist

Use another specialist when the addition needs expertise the team does not have. Agree who coordinates the connection and resolves problems across it. A referral or subcontract does not explain those responsibilities by itself.

If none of these paths fits the customer’s needs and the team’s capacity, decline the addition. An unworkable commitment does not become a useful service because it appears in the proposal.

Give the customer a decision, with its consequences.

An explanation should name the work, the effect on the existing plan and the available choice. Keep the language direct. The customer should not need to translate a list of technical tasks into a business decision.

The reply alongside is an example, not a message sent to a customer.

“The agreed launch gives visitors a working enquiry form. Live booking also needs availability rules, confirmations and a tested way to handle changes.

We can keep that launch and assess booking as a separate addition. If live booking is essential for launch, we need to agree the requirements and revise the delivery plan first.

Which outcome matters most: opening the enquiry route on the agreed date, or launching only when direct booking is ready?”

If you have already said yes, correct the plan early.

A hard choice is sometimes admitting that the existing plan will not work. Describe the new fact rather than defending the earlier estimate. Be clear about what is complete, what remains uncertain and which promise is affected.

  1. Show the issue. For the booking example, the missing work might be deciding who maintains availability or testing how changed appointments reach staff.
  2. Explain the effect. Identify the work that must change and the delivery commitment it affects. Separate a confirmed problem from an estimate that still needs checking.
  3. Offer workable choices. Discuss reducing the first release, changing the schedule or involving the required specialist. Do not present an option the team cannot support.
  4. Record the decision. Update the agreed work and responsibilities so the team and customer are acting on the same plan.

If the decision is to stop, agree the handover of completed work, access and outstanding actions. The customer still needs a usable way forward.

Make focus visible in the work you accept.

For an agency, focus is tested when a useful-looking request arrives beside work it already knows well. Search visibility, link building, WordPress repairs and site performance can lead to related requests. A related request still needs its own clear result and responsible person.

For a customer, ask a prospective partner to work through one actual addition. What would it change? What would they need to learn first? Who would maintain it? Their answers are more useful than a claim that they can do everything.

Growth can be a good choice when the capability and capacity are there. The decision should remain deliberate. Make the promise the team can explain, deliver and support.