Surfacing Integration Touchpoints: Catalog Every Source, Broker and Consumer Before You Design
- 26/10/2026
- Posted by: A Gable
- Categories: Core SE Mechanics, Discovery & Qualification
Integration is where good demos meet reality. Your product may handle the workflow perfectly, but in the prospect’s environment it has to receive data from somewhere, publish events to something, and feed systems that other teams depend on. When one of those connections is discovered after the proposal, the scope grows, the timeline slips, and the confidence you built in the demo erodes.
Surfacing integration touchpoints is the discovery skill of cataloging the upstream data sources, event brokers and downstream consumers that must interoperate with the solution. It is not integration design; it is the inventory that makes design, sizing and pricing honest.
The problem it solves
- The need: unknown integrations create late scope changes, under-priced proposals and implementation risk.
- Who faces it: SEs scoping solutions that sit inside an existing technology landscape, and the architects and implementation teams who follow.
- Stage: technical discovery, before solution design, sizing and the commercial proposal.
- Decision it supports: what the integration scope is, which interfaces are standard and which are custom, and where the risk lies.
- Success looks like: a touchpoint catalog the prospect’s architect has reviewed, with direction, method and owner for each connection.
Three directions to cover
- Upstream sources: where the data your solution needs is created. Ask which system is the source of truth for each key entity.
- Brokers and middleware: how data moves today: message queues, event streams, integration platforms, file transfers, scheduled jobs.
- Downstream consumers: which systems, reports or teams depend on the data your solution will produce or change.
Downstream consumers are the most often missed. A change that looks local can break a report that finance relies on every month.
What to record for each touchpoint
- System and owner: what it is and which team is responsible for it.
- Direction: into the solution, out of it, or both.
- Method: API, event, file, database link, or manual.
- Frequency and volume: real time, hourly, nightly; how much data.
- Constraints: security, residency, change-freeze windows, version limits.
- Status: standard connector, configuration, custom work, or unknown.
Questions that surface hidden touchpoints
- “If this system were switched off for a day, what else would stop?”
- “Who receives a file or report from this process?”
- “Which integrations does your team maintain that nobody else knows about?”
- “What changed the last time an integration broke, and who noticed first?”
Adjusting to the situation
- Frontline users who fear automation: they often know the manual “integrations”: the exports and re-keying steps. Ask them, respectfully, what they move by hand.
- A competitive displacement against an entrenched incumbent: years of use mean many systems depend on the incumbent. Catalog its consumers before proposing a cutover.
- A regulated or air-gapped environment: record which connections cross a boundary and what approvals they need.
- A multi-region rollout: touchpoints may differ by region and by legacy version; catalog per region.
- A merger of two stacks: mark which touchpoints must be duplicated, merged or retired.
- An executive briefing on consolidation: summarise the count, the custom ones and the risk, not every interface.
Common mistakes
- Saying “we have an API for that” before knowing what is on the other side.
- Cataloging only systems your product connects to natively.
- Leaving status as “assumed standard” without checking versions and limits.
How you know it worked
- The prospect’s architect reviewed the catalog and added to it.
- Every custom or unknown touchpoint is reflected in sizing, timeline or risk notes.
- No new integration appears for the first time during implementation.
Where this skill sits in the deal
Upstream: current-state workflow mapping shows the handoffs, and uncovering unofficial tool dependencies reveals the informal connections. Parallel: non-functional requirements set the volume and latency each touchpoint must meet. Downstream: the catalog feeds ecosystem integration strategy, interactive whiteboarding of the target architecture, and scoping and sizing.
Practice it before the live call
Integration discovery follows the same logic whatever product you sell: part of the 80% of Solution Engineering. SE Ignite teaches it as a free, tech-agnostic micro-skill so you can build the habit of asking about downstream consumers before a proposal goes out.