Partner Integration Plan
The document every partner-built Splash integration ran on. Pre-build agreement, design and build, and delivery, so both companies scoped the same thing and shipped something support could handle.
The integration questionnaire was the first version of this idea: get the partner and the product team to agree on the problem before anyone writes code. At Splash I rebuilt it for a platform where partners build against our API, and the plan grew a middle and an end.
Pre-build is the agreement. Who the partner’s users are, what problem the integration solves for them, the use cases in plain language, the user journey through both products, and a scope written at the level of “get a list of attendees so that…” instead of endpoints. Nothing gets built until both sides sign off on this section. Every expensive integration failure I’ve seen was a scoping mismatch that surfaced after the build.
Design and build is the engineering: assumptions and prerequisites, the proposed solution with the authentication flow drawn out, the API inventory and data-flow diagram, success criteria with the testing method, and an explicit out-of-scope list so the things a customer will assume are handled are either handled or named.
Delivery is the part most plans skip. What changed from the original scope and why, a recorded demo including setup, the final endpoint inventory, a getting-started guide a customer can follow, the goals the partner will measure, and the collateral marketing needs to tell anyone it exists. Skip those and support learns about the integration from a ticket.