Direct answer: For every system the proposed site must use, name its business owner, exact customer task, access method, test environment, required permission, acceptance event, and fallback when it fails. Mark each dependency ready, blocked, or requiring discovery. A product name in a brief does not tell an agency whether it can be connected within the quoted scope.
Consider “our website must connect to the CRM and booking calendar.” That sentence leaves open whether the site should create a lead, book an appointment, avoid duplicates, assign an owner, or send a confirmation. It also hides who controls the accounts and whether a safe test is possible.
Send a dependency sheet, not credentials
One row per integration is enough to start. Use this as a fill-in brief:
System and account owner: booking calendar; operations manager.
Customer task: choose a service and available time from the service page.
Data in / result out: service ID, time, contact details → confirmed booking ID and customer message.
Access route: operations owner can invite the implementation team or authorize the required integration scope.
Test state: sandbox/test calendar available by the agreed date; synthetic appointments only.
Failure behavior: show a clear retry or staff-contact route, and do not claim a booking was confirmed without its ID.
Evidence of acceptance: screen, calendar entry, customer confirmation, and staff notification show the same service and time.
Status: ready / blocked / requires discovery; named person and next decision.
Repeat that for the CRM, payment service, email delivery, analytics, inventory, and any other system actually needed. The fields are a proposed scoping artifact, not a claim that every provider supports the same integration. A reviewer should be able to see which promise depends on an external vendor, account, license, approval, or API behavior.
Be specific about permission and test mode
For a payment example, Stripe's sandbox documentation provides test transactions that do not move funds. Its key-handling guidance says secret keys belong in server-side secret management and should be shared through that system, not pasted into email, chat, or a proposal. The brief needs the person who can grant the right access, not the key value.
For a calendar integration, Google's Calendar API scope guide shows that permissions range from availability-only to editing events. The team should choose only the needed scope and test the real task; “Calendar access” is too vague. For analytics, Google's GA4 roles guidance distinguishes Viewer, Analyst, Editor, and Administrator. Confirm who can read the existing setup and who may change it. These examples show why access is a design and ownership decision, not a box to tick at the end.
Turn unknowns into proposal language
Mark a dependency ready when the owner, test environment, supported route, and acceptance check are known. Mark it blocked when an account, contract, approval, or owner is missing. Mark it requires discovery when the provider capability or data mapping has not been tested. A proposal can then state the assumption and a decision date. It should not promise a full integration and quietly treat the unknown as free scope.
At handover, the business should know which accounts and integrations it owns, who handles future failures, and which access can be revoked. The website handover inventory covers the end of the project; this sheet makes dependencies visible before the quote. The form-delivery test is one acceptance example for a specific integration, while the web-designer hiring questions cover broader supplier fit.
ARCHV's website service includes proposal-defined scope. CMS, commerce, booking, CRM, and other connections need a separate fit review. Attach the dependency sheet to a website estimate so the quote can name what is known, what must be tested, and who supplies each input.