How to scope a client integration before promising a fixed price

“Connect the website to our booking system” leaves an important decision open. Does the website send a request for someone to review, or does it confirm a booking immediately?

Your agency needs that answer before committing to the feature or a fixed price. It affects what the visitor is told, what information must move and what happens when the booking service is unavailable.

You can brief this work without designing the technical solution. Describe the business event, then ask the developer to verify what the systems support. Keep unanswered questions visible, with someone responsible for resolving each one.

Describe the outcome before choosing a tool

In this hypothetical example, a visitor requests an appointment through a service business’s website. A member of staff checks availability and confirms it later. The first release does not take payment or reserve a slot automatically.

Once receipt is established, the website should say “Your request has been received”. It should not say “Your booking is confirmed”, because the proposed process has not confirmed a booking.

A brief for this hypothetical example could say:

A visitor submits an appointment request with their name, contact details, requested service and preferred date. Staff must be able to find and process it in the agreed system. Staff confirm the booking separately. Payment, instant availability, rescheduling and cancellation are excluded from the first release.

The client still needs to confirm which data is required and who may access it. Avoid collecting extra information simply because a field is easy to add.

Give open questions an owner and a deadline

The brief should distinguish agreed behaviour from assumptions that need checking. Use the worksheet below to record those decisions before committing to a fixed build price.

For the hypothetical appointment request, the booking system is the proposed authoritative record. The client operations lead needs to confirm that. The developer needs current supplier documentation and suitable test access to check the intended connection.

Commercial access needs checking too. The client must confirm whether its subscription includes the required connection. Record when that answer is needed, rather than leaving it as a general dependency with no owner.

The client operations lead approves the intended behaviour through the agency account lead. Keep that approval route in the brief so the developer knows whose decision settles an open question.

Verify what the connection supports

Ask the developer to check the supplier’s current documentation and test the required behaviour. Record limits or gaps, including anything that depends on a different subscription or another supplier.

A connection that can create a record may still be unable to return the status you need. API access alone does not establish that every action in the client’s request is supported.

If an unresolved question could materially affect the work, commission a bounded investigation. Specify:

• The question the developer needs to answer.

• The documentation and access needed to check it.

• The expected output, such as a tested approach with exclusions and a build estimate.

• Any client decisions needed before the build can be priced.

Keep the investigation separate from a promise to deliver the whole feature. Its scope is to resolve the stated uncertainty.

Agree the failure path before writing the visitor message

For the hypothetical appointment request, decide what happens if the booking system is unavailable when the visitor submits the form.

One possible design is to retain the request safely, tell the visitor it has been received for processing and alert the responsible person. That requires somewhere suitable to retain the request and an agreed process for getting it into the booking system later. A receipt message is only appropriate once receipt has been established.

Another approach is to show a clear failure and offer an agreed contact route. Choose the behaviour with the client before writing the visitor message.

Do not quietly add email as a fallback. It may be workable, but someone must monitor it, handle the information appropriately and reconcile it with the booking system. Name that responsibility in the brief if email is part of the agreed design.

Check repeats and uncertain outcomes separately

A visitor may press submit twice. A connection may also fail to return an answer even though the booking system has created the record.

Ask the developer how the proposed implementation recognises a repeat and how someone checks an uncertain outcome. Repeating the operation without checking can create duplicate requests.

The precise approach depends on the destination system. Agree what staff need to see, who investigates unresolved requests and what evidence helps them do it. Avoid promising that duplicates can never occur.

In the hypothetical example, a request reference could help staff identify one enquiry across the website and booking system. Confirm that both sides can support the proposed reference before relying on it.

Define acceptance before development

Use the intended behaviour to agree the tests. These checks belong to the hypothetical appointment request example:

Use test data and a suitable test environment. Keep the results and any outstanding exceptions with the acceptance record. The client operations lead approves the behaviour through the agency account lead.

Carry the scope into the proposal and handover

Call the feature an appointment request if that is what it does. State that staff confirmation is required and name the work excluded from the first release. Keep those qualifications in the client proposal, where the promise is made.

Agree who handles service changes and failures after launch. A third-party subscription, an expiring credential or a changed API can affect the connection after the build has been accepted.

If the client later asks for live availability and instant confirmation, assess that as additional scope. The original request workflow does not establish that the larger feature is included or supported.

Before committing to a fixed price, resolve material unknowns or commission the bounded investigation needed to answer them. Record the agreed behaviour, exclusions and acceptance checks alongside the price.

I help agencies scope integrations before they commit to a client promise. Bring the requirement to Kyln, including the destination system and the outcome the client expects.