# Partner Integration Plan — Template

Used at Splash for every partner-built integration. Copy it, fill in each section, and keep it updated through delivery. Sections in the Pre-Build phase must be agreed on by both companies before any build starts.

## Pre-Build

### Description of Partner Product
Provide a high-level description of the partner product. Include ICP, users, the data used, and what it enables them to do.

### Integration Value (Problem and Solution)
Describe the problem users are facing and how the integration will be a solution to that problem. Include the roles of the users and how the partner product and Splash fit together in the solution.

### Integration Use Cases
List the use cases this integration will support and describe them.

### User Journey
Include the user journey of interacting with the integration and both products.

### High-Level Scoping of the Integration
Describe the high-level scope: which general data will be used, where it will be surfaced, and how it enables the use cases above. It does not need specific endpoints and values. Ex: "Get a list of attendees so that…"

## Design and Build

### Assumptions and Prerequisites
Assumptions made in the design and the prerequisites for the integration: required tools, data that must be shared, settings that must be configured.

### Proposed Solution and Diagrams
The technical solution and design: data design, wireframes, links to Figma or a diagramming tool. Specifically: the authentication flow, what endpoints and data are sent via the API, and the user experience in both systems.

### API/Feature Inventory and Data Flow
Relevant documentation of tools/APIs used. The API calls used on each system. A diagram of the data flow between systems.

### Success Criteria
The results expected with a properly working integration, the testing methods prior to launch, and the metrics or monitoring used post-launch.

### Scope
- **Out of scope** — what the integration will not do, including features that may be assumed but are explicitly excluded, and what is roadmapped for later.
- **Concerns and risks**
- **Security** — authentication, data, or design concerns.

### Sandbox Details
Where it will be tested; any instance where Splash can view or demo it.

## Post-Build / Delivery

### Changes from Initial Scoping
Any changes required during the build, with reasons. If the data flow or user experience changed, include updated diagrams and screenshots.

### Demonstration
Video demonstrations, screenshots of the user experience, test and demo environments, including a demonstration of the setup required and an example of success.

### Final API/Feature Inventory and Data Flow
All API endpoints used from Splash and a completed diagram of the data flow.

### Getting Started
How a customer sets it up: prerequisites such as feature flags, product tiers, or necessary configuration.

### Integration Goals
Goals, objectives, key results, or success criteria you plan to measure.

### Collateral
Documentation generated for the release that marketing can use; links on the marketing site or integration marketplace.