A website integration brief explains what should move between your website and another tool, what should happen to it, and who takes over when something needs attention. Writing those decisions down gives your developer and your team the same definition of a working connection.
Our custom website work includes integrations. Before choosing how to connect two systems, we recommend defining one complete handoff in plain language. A list of app names alone leaves too many business decisions unanswered.
Start with one event and one useful result
Describe the moment that starts the handoff and the record your team needs at the other end. Keep the first version narrow enough that someone can explain when it has succeeded.
For example, a hypothetical service business might write: When a visitor sends a project request, create a new inquiry in our customer management tool and assign it to the intake team. That sentence identifies the starting event, the destination and the next owner. It does not yet promise an appointment, a quote or a reply.
Also name what stays outside this connection. If scheduling and customer emails are separate work, say so. This keeps an integration brief from quietly becoming a plan for the entire sales process.
Map the information your team actually needs
For every piece of information that moves, identify its source, its destination and the rule for an empty or unexpected value. Field labels can look similar while meaning different things to the people using them.
- Contact name: which website entry becomes which destination field?
- Service requested: which website choices correspond to the destination's categories?
- Project description: where does the visitor's original wording belong?
- Inquiry owner: is assignment fixed, chosen by service, or reviewed by a person?
- Source reference: what identifies this particular request if staff need to investigate it later?
Only include information needed for the stated workflow. Use invented sample records when discussing the mapping, and keep passwords and access keys out of the brief. The person implementing the connection should arrange access through an appropriate secure channel.
Decide which system owns each update
Creating a record and keeping two records synchronized are different requirements. State whether information travels one way or both ways. If staff edit an inquiry after it arrives, decide whether any later website event may replace that edit.
We suggest naming the authoritative system for each value that can change. For instance, the website might supply the original request while the customer management tool owns the assigned staff member and current status. Write those boundaries explicitly so a later transfer cannot silently undo someone's work.
Separate repeated delivery from a new request
Define what counts as the same event being delivered again and what counts as a genuinely new request. A visitor making a second inquiry should not automatically disappear just because their email address already exists.
Ask the developer how the connection will recognize an event already handled. Then define the business outcome: repeated delivery of that event should not create another inquiry, while a separate request from the same person should follow the agreed new-request rule. Any decision about merging customer records belongs in the brief too.
Give exceptions a destination and an owner
A connection needs a plan for information it cannot place. Specify where the unresolved item is recorded, who can see it, and what action that person should take. A vague instruction to notify the team leaves responsibility unclear.
- Missing information: hold the request for review or reject it with a clear reason, according to the agreed rule.
- Unrecognized service choice: route it to a named person or queue instead of guessing a category.
- Destination unavailable: define whether the transfer will be retried and who checks unresolved items.
- Connection restored: confirm which pending requests arrived before anyone resends them manually.
Choose a way for staff to distinguish an item that never arrived from one that arrived without a confirmation. That distinction matters when deciding whether to try again. Keep any customer-facing status consistent with what the system has actually completed.
Agree on evidence that the handoff works
Finish the brief with a few example outcomes that the business owner and developer can review together. These are acceptance decisions for the connection, not a general website launch checklist.
- 1A normal sample request creates the expected destination record with the agreed values and owner.
- 2Delivery of the same sample event again does not create another inquiry.
- 3A separate request from the same sample contact follows the documented rule.
- 4An unsupported value reaches the agreed exception queue without a guessed replacement.
- 5A temporary destination failure remains visible, and recovery does not create duplicate records.
Record who will approve these outcomes and who will own the connection after handover. Include where the mapping and exception instructions will live, so the next person does not have to reconstruct them from messages.
Bring a concrete brief to the conversation
A useful first brief can be short: one event, one destination, a field map, ownership rules, repeat handling, an exception owner and sample outcomes. Unknowns are fine when they are named and assigned to someone to resolve.
If your website needs to connect with the tools your team already uses, explore our custom website design and development service. Bring the handoff you want to improve and a sample of the record your team needs. We can use that as the starting point for a scope conversation.