How to prepare a systems integration project brief

Describe the handoff that needs to work

Identify the event that starts the process, the person or team waiting for the result, and the system where the result must appear. For example, an approved work order might need to appear in a field team’s scheduling application. State the current manual steps and what must happen next. This example illustrates a planning approach; it is not a claim about a particular Cloudtek project.

Name the source of truth

List each system and its owner. For every important record, identify which application controls the authoritative value. If two applications can change a customer address or job status, decide how conflicts should be resolved. Include the identifiers used to match records across systems. Similar-looking names are not a reliable matching rule.

Check the available interfaces and access

Record whether each system exposes an API, supported import or export, webhook, or another approved interface. Ask its owner about permissions, test environments, request limits, and change policies. Include cloud and on-premises access requirements. Missing documentation or unavailable access is an estimation dependency, not a detail to leave until implementation.

Define timing and failure handling

Describe how quickly information needs to arrive and whether updates are scheduled or event-driven. Ask what happens if a request fails, a record is duplicated, a required field is missing, or a destination is unavailable. Agree who sees exceptions and how they are investigated. The appropriate retry and reconciliation approach depends on the systems and the business consequences of a repeated or missing action.

Test the destination, not just the request

Write acceptance examples that check the final business state. An HTTP response alone does not show that the right record exists with the right values and permissions. Include normal, incomplete, duplicate, and failed inputs. For a migration, also agree how source and destination records will be reconciled and which team accepts discrepancies.

Plan ownership after release

Specify who monitors the integration, manages access, and responds when a connected application changes. Include documentation, deployment responsibilities, and support arrangements in the scope discussion. A working connection needs an owner after the original implementation team hands it over.

Bring these seven items to the first conversation

Prepare the business handoff; source and destination systems; owners and available interfaces; example fields and identifiers; required timing; failure and exception examples; and acceptance and ongoing ownership expectations. List unknowns explicitly. Leave credentials and customer records out of the initial email, then agree an appropriate way to share detailed material.

Explore the next step

Use these questions to prepare your project enquiry. Leave out credentials and sensitive customer data.

Discuss your project brief