20 questions across five areas. Answer honestly and get your readiness score instantly: no email, no PDF, no waiting. Just the score and a clear view of where your gaps are.
20 questions
5 min to complete
Instant score
No email required
01
Data Quality
Questions 1 – 4
0 / 4
Bad data is the silent killer of integration projects. You can build the most elegant connector in the world and it will fail immediately if the data flowing through it is inconsistent, incomplete, or misformatted.
Q1
Do you have a single source of truth for product and SKU data?
Inconsistent SKU data is the number one cause of mapping failures. If product IDs differ between your OMS and your 3PL, orders cannot be matched automatically.
Q2
Is your customer and order data clean and consistently formatted?
Mixed date formats, address structures and currency codes break automated flows. This is especially common in businesses that have grown through acquisitions or platform migrations.
Q3
Have you audited your data for duplicates or nulls in key fields?
Null order IDs and duplicate records corrupt downstream systems. Run a data quality check before you start building, not after the integration surfaces the problems.
Q4
Do both systems agree on field names and data types?
'order_id' in one system and 'OrderNumber' in another isn't just a naming issue. It requires a mapping rule that needs documenting, testing, and maintaining.
02
API & Technology
Questions 5 – 8
0 / 4
The technical readiness questions are ones most teams assume they can answer. In our experience they often cannot, not in the detail that matters. "Yes we have an API" and "yes our API supports the operations this integration needs at the volume we require" are very different answers.
Q5
Does every system you want to connect have a published API or EDI specification?
No published spec means custom connector work. Budget at least double the time and expect surprises. Ask for the documentation before the project starts, not during.
Q6
Are API credentials and sandbox environments available to your team right now?
Waiting on vendor access is one of the most common causes of project delay. Some vendors take 2–4 weeks to provision sandbox access. Get this sorted before kickoff.
Q7
Have you confirmed API rate limits won't block your peak order volume?
Some APIs throttle at 100 calls per minute. If you're processing 5,000 orders per hour at peak, the maths doesn't work. Know your ceiling before you build to it.
Q8
Is there a webhook or event-based option, or only polling?
Polling every 60 seconds versus real-time event triggers changes the architecture, infrastructure cost, and latency of your integration. It needs to be a design decision, not a discovery.
03
ERP Readiness
Questions 9 – 12
0 / 4
ERP integrations deserve their own category because ERP systems carry complexity that other platforms don't. They're often older, often customised, and often have an internal owner who is the single point of failure for the whole project.
Q9
Is your ERP on a supported version with integration modules enabled?
Legacy ERP versions often lack the endpoints modern integrations need. This is a discovery conversation that should happen in week one, not week eight.
Q10
Do you have a named internal ERP champion who can answer mapping questions?
Integration projects without a dedicated ERP owner always stall. Someone needs to be the decision-maker on ERP-side questions. Make it explicit before you start.
Q11
Are your chart of accounts and cost centres finalised?
Finance integrations built on an interim account structure need to be rebuilt when that structure changes. It happens more often than anyone wants to admit.
Q12
Have you documented which ERP fields are mandatory versus optional?
Sending optional fields as blank values can trigger validation errors that kill the entire transaction. Know the ERP's rules before you start mapping against them.
04
Team & Ownership
Questions 13 – 16
0 / 4
If you only read one section, read this one. The majority of integration projects that go over budget or miss their go-live date do so because of team and ownership failures — not technical ones.
Q13
Is there a named project owner with authority to make scope decisions?
No single owner means everyone owns it, which means no one owns it. Scope decisions made by committee during a build project are how timelines double.
Q14
Does your team have bandwidth to support UAT and go-live activities?
Integration go-lives require 3–5 days of ops team availability. If your team is at capacity, either push the timeline or reduce the scope. Don't try to do both simultaneously.
Q15
Have stakeholders across ops, finance and IT signed off on the scope?
Late-stage "can we also add..." requests are the single biggest budget risk in integration work. Get sign-off in writing before the build starts, not after the first demo.
Q16
Is there a process for handling integration errors post go-live?
Every integration fails occasionally. The question isn't whether it will. It is who gets the alert and who fixes it when it does. Define this before go-live, not after the first incident.
05
Process & Scope
Questions 17 – 20
0 / 4
The process questions are often the most uncomfortable, because they require honest answers about whether the current workflow is actually ready to be automated. Automation doesn't fix a bad process — it accelerates it.
Q17
Have you mapped the current manual process end-to-end before automating it?
Automating a broken process creates a faster broken process. Walk the current workflow before you build the new one. You will always find something that changes the spec.
Q18
Are edge cases documented, including returns, partial shipments and cancellations?
Edge cases represent about 20% of order volume but 80% of integration complexity. Handle them in the design phase, not as emergency patches after go-live.
Q19
Do you have a fallback process if the integration goes down?
A documented manual fallback turns a potential 2-hour crisis into a 20-minute managed incident. Document it before go-live, distribute it to the team, and test it at least once.
Q20
Have you defined what "done" looks like, with measurable success criteria?
Without defined success criteria, projects drift. The integration is never formally complete, scope creep accelerates, and nobody can declare victory. Define the finish line before you start running.