How to use it
- 01
Bring the right people
Sit down with someone who knows each system, usually one from operations and one from finance or IT. The questionnaire is short, and most of its value comes from the two of them hearing each other's answers.
- 02
Settle which system is right
For every kind of record, agree which system wins when they disagree. Write the answer even if it feels obvious. Integrations that skip this step produce records that overwrite each other.
- 03
Check how each is reached
Ask the supplier of each system whether a documented interface exists and on which plan. If the answer is exports only, the integration is still possible, and it will be slower and built differently.
- 04
Describe failure
Say what happens today when data goes wrong and who should be told in future. An integration with no agreed owner for its errors will fail quietly, which is worse than failing loudly.
What integration discovery has to establish
An integration is simple to describe and easy to underestimate. These are the facts that separate a reliable estimate from a hopeful one, and each maps to a part of the questionnaire.
| Part | What it settles | Why it matters |
|---|---|---|
| Purpose | What the connection makes possible | Keeps the scope to what the business needs |
| Records and direction | What moves, and which way | Defines every mapping that has to be written |
| Authority | Which system is right for each record | Prevents the two systems from overwriting each other |
| Volume and speed | How much, how fast | Chooses between live events and scheduled batches |
| Access | Interfaces, exports and test environments | Often decides the approach and the cost by itself |
| Failure | Who is told, and how much delay is tolerable | Sets the monitoring and retry design |
| Sensitivity | The kinds of data involved | Brings security and legal requirements in early |
A worked example
An outdoor retailer connecting its store to its ERP
The example is an invented retailer whose web orders are retyped every morning. Load it to read the full document. Two of its answers would change an engineer's estimate straight away.
- Access to the ERPExports and imports only, with an interface module that may cost extra. The integration can still be built, on a schedule instead of live, unless the module is bought.
- SpeedStock changes must arrive within minutes, and delays cost money within the hour. That requirement conflicts with an export-only ERP, and the conflict is now visible before any work starts.
- What was triedA plug-in that ignored product variants. This tells the engineer that variants are central to the catalogue and must be handled properly in the mapping.
The useful outcome is a decision the retailer has to make with its ERP supplier: pay for the interface module, or accept stock updates on a schedule. No proposal would be reliable without it.
What this tool does not do
The questionnaire gathers facts. Turning them into a design is the engineer's job, and some things can only be learned by looking at the systems.
- It does not verify what a system's interface can do. That takes its documentation and a test account.
- It covers one pair of systems. A chain of three or more needs one document per connection.
- It does not choose between a connector product and custom work. Both can be judged against the answers.
- The answers are saved on your own device only, and can be cleared with one press.
What to do with the finished document
Send the document to whoever will propose the integration, along with the names of both systems' suppliers. If that is us, we reply with what we would verify first and how we would approach the connection. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
Who should fill in the questionnaire?
Two or three people together: someone who uses each system daily and, where possible, someone technical. No single person usually knows both which records matter and how the systems can be reached. Completing it together takes less than an hour and often settles disagreements that would otherwise surface halfway through the project.
What if we do not know how a system can be reached?
Choose the option that says so and ask the supplier. It is a normal position to be in. The supplier's answer, including which plan or licence includes the interface, is among the most important facts in the whole document, because it can change the cost of the integration more than anything else.
Do we need real-time integration?
Only if the business loses something when data arrives late. Stock for a busy online store may need to move within minutes. Invoices passed to accounting rarely do. Real-time designs cost more to build and to monitor, so it is worth being honest. Our comparison of real-time and scheduled data sync covers the trade.
Should we try a ready-made connector first?
Often, yes. If a maintained connector exists for your two systems and your data is standard, it is the quickest route, and the questionnaire will help you test it against your needs. Where a connector has already been tried and failed, the reason belongs in the document. See custom integration versus an existing connector for how to judge.