What is the single most useful question to ask?

Show me the documentation now. It is more revealing than any question you can phrase, because it converts assurances into something you can verify in twenty minutes. Public, complete documentation with a clear object list, stated rate limits and a change log tells you the vendor takes integration seriously and that other people are successfully building against it. Documentation available only to customers, or only under a partner agreement, tells you something too, and neither answer requires you to interpret a salesperson’s enthusiasm.

The vendor says they can build whatever we need. Is that reassuring?

Usually not, for two reasons. Custom development promised during a sales process tends to be quoted optimistically, delivered late and supported reluctantly, and it makes you dependent on a single vendor’s roadmap for something central to your operations. It also means you become the only customer using that capability, which is precisely the code most likely to break in a future upgrade and least likely to be noticed. A product where the capability already exists, is documented, and is used by many customers is a substantially safer position than a promise.

How much should integration capability weigh in a selection decision?

More than most evaluations give it, particularly for systems in the middle of your operations such as an ERP, an inventory system or a point of sale. Features can often be worked around and interface limitations usually cannot, because they constrain what any amount of money can achieve. A practical approach is to treat integration capability as a scored criterion with real weight rather than a pass or fail checkbox, and to disqualify any product that cannot support a flow you know you need on day one. Being confident about that disqualification is exactly what the assessment gives you.

What if the product we want has a weak interface?

Then decide with your eyes open rather than assuming it will be solved later. Sometimes the right answer is still to buy it, because it is dramatically better at the job and the integration cost is affordable, and in that case cost the workaround properly and budget for it. Sometimes there is a middle path: a scheduled file exchange instead of real time, or a narrower integration scope. And sometimes the honest conclusion is that the workarounds cost more over three years than the difference in licence fee, which is worth knowing before you sign rather than discovering during the first project.

Should we ask about data export even if we love the product?

Especially then, because that is when you have the least inclination to and the most leverage. Enthusiasm at signing is not a prediction about year four, and businesses change in ways that make products unsuitable for reasons nobody could foresee. Ask what a complete export includes, whether attachments and historical records are part of it, the format, the time and the cost, and get it in the contract. It costs nothing to ask while you are still a prospect, and it is the term most likely to be refused once you are a customer.

Does this apply to small businesses buying inexpensive software?

It applies proportionately, and the scaled down version is worth ten minutes. Check that documentation exists and is public, that you can create credentials without contacting support, that there is some way to export your data, and that the plan you are buying includes the access rather than requiring an upgrade. Those four checks catch most of the problems and cost almost nothing. The full assessment is worth it for a system your operations will depend on, and a ten minute version is worth it for almost anything you will put customer or financial data into.

Can you assess a vendor for us if you are not building the integration?

Yes, and we do it regularly as a standalone piece of work. You get a written comparison of the shortlisted products against the flows you actually need, a note of which vendor assurances should go into the contract, and a plain recommendation. Where the conclusion is that a product is well supported enough for a standard connector, or that no integration work is needed at all, that is the finding you receive. Our usefulness here depends on the assessment being honest, so it is not a lead in to a build.

For anyone about to sign a software contract

The Integration Questions to Ask Before You Sign, Not After

Every system you buy eventually has to talk to another one. That conversation is dramatically cheaper if the product was chosen with it in mind, and close to impossible if the vendor’s answer to a question about their interface was yes when the honest answer was partly.

A demo tells you almost nothing about whether a product will integrate well. This page is the list of questions we ask on behalf of clients evaluating software, what a good answer sounds like, what a worrying one sounds like, and which of these belong in the contract rather than in an email from a salesperson. It takes an hour to work through and it routinely changes which product a business buys.

Get a Vendor Assessed (03) 9003 0111

Realistic ROI

Yes has degrees

Almost every product says it has an interface

The useful question is which objects, which directions, and how fast

Read only is common

And is often not mentioned unless asked

A system you can read but not write into shapes every later design

Before signing

Is when you have negotiating power

Afterwards, every one of these becomes a request rather than a term

Exit terms

Are the question nobody asks at the start

And the one that matters most when a product stops suiting you

Four Reasons This Hour Is Worth More Than the Demo

Integration capability is close to impossible to assess after purchase and close to impossible to change. These four are why.

Every vendor says yes, and yes covers a lot of ground

Almost no product will admit to having no interface. What varies enormously is what that interface actually reaches. A system may expose customers and invoices and not products. It may allow you to read orders and not create them. It may cover ninety percent of what is in the user interface and omit the one field your process depends on. The question that produces useful information is not whether there is an interface but which specific objects and fields it covers, in which direction, and whether the vendor will show you the documentation now rather than after purchase.

Limits decide what designs are possible

How many calls you may make per minute and per day, whether there is a bulk facility for large operations, and what happens when you exceed a limit, together determine whether real time synchronisation is achievable or whether you will be designing around a nightly batch. Vendors rarely volunteer this and it is usually documented somewhere. A product with generous limits and a bulk facility can support designs that a product with tight limits and no bulk option simply cannot, however much you are willing to spend on the integration.

Access to your own data is sometimes a paid extra

It is increasingly common for interface access to sit on a higher pricing tier, to carry a per call charge, or to require a partner arrangement with its own fee and approval process. None of that is unreasonable in itself, and all of it changes your total cost. Establish before signing whether the tier you are buying includes the access you will need, what it costs to move up, and whether the price of that access is contractually protected or can be changed at renewal once you depend on it.

Getting your data out is a question for day one

Every product eventually stops suiting a business, and the moment you want to leave is the worst possible time to discover that a full export is a professional services engagement, that historical records come out in a form nobody can use, or that attachments and documents are not included at all. Ask what a complete export contains, in what format, how long it takes and what it costs, and get the answer written into the contract. A vendor confident in their product will not object to the question.

The Questions, and What a Good Answer Sounds Like

Six areas. Ask them of every product on your shortlist and compare the answers side by side rather than one at a time.

Object by object

Coverage and direction

Which objects can be read, which can be created and changed, and which cannot be reached at all. Ask for the documentation now, not after signing, and check your specific requirements against it rather than accepting a general assurance. A good answer is public documentation you can read yourself with an object list you can verify. A worrying answer is that documentation is available to customers, or that a particular need can certainly be accommodated without any reference to how.

Numbers, not adjectives

Limits and bulk operations

Calls per minute and per day, whether limits are per account or per user, whether there is a bulk or asynchronous facility for large operations, and what happens when a limit is hit. A good answer is specific numbers in published documentation and a described behaviour on exceeding them. A worrying answer is that limits are generous, or that they have never been a problem for anyone, which usually means nobody has asked while running at your volume.

Push or poll

Events and freshness

Whether the system can notify you when something changes or whether you must poll for it, and if it notifies, whether delivery is retried on failure and whether events can arrive twice or out of order. This determines how fresh your data can be and how much polling traffic your limits must absorb. A good answer describes the events available, the retry behaviour and how to detect duplicates. A worrying answer is that notifications exist without any detail about reliability.

Testable

Sandbox and support

Whether a test environment is available, whether it costs extra, whether it can hold a copy of real data, and who answers a technical question during a build. Without a sandbox, every test happens in production, which is a genuine constraint on anything financial. A good answer is a free or low cost test environment and a named technical support path. A worrying answer is that you can test in a trial account, which is not the same thing and will not survive the build.

Notice period

Versioning and deprecation

How interface changes are communicated, how much notice is given before something is withdrawn, whether old versions are supported in parallel, and where the change log lives. This is what determines whether an upgrade is a scheduled task or an emergency. A good answer is a published policy with a stated notice period and a visible history of changes. A worrying answer is that changes are announced by email, which means the notice reaches whoever set up the account three years ago.

In the contract

Access, security and exit

Whether you can create a dedicated service account rather than using a staff login, how permissions are scoped, how credentials are rotated, where data is stored geographically, and what a complete export contains on exit. Australian businesses handling personal information also need to know the storage location and the sub-processors involved to meet their obligations under the Privacy Act 1988. The good answers here belong in the contract rather than an email, because these are exactly the terms that become difficult to obtain once you are committed.

What to Ask, and How to Read the Answer

Task	Traditional	What Good Looks Like	Notes
Do you have an API	Yes	Which objects, which directions	Ask for the documentation before signing and check your actual requirements against it.
Are there rate limits	They are generous	Published numbers and behaviour	Generous is not a number. Ask what happens on exceeding, and whether bulk exists.
Can we get notified of changes	We have webhooks	Events listed, retries described	Ask about duplicate and out of order delivery. Both are normal and both need handling.
Is there a test environment	You can use a trial	A real sandbox, with data	Testing financial flows in production is a constraint you will regret accepting.
How do you handle changes	We notify customers	Published policy and notice period	Ask where the change log is and whether old versions run in parallel.
Does API access cost extra	Not usually	Named tier and protected price	Check whether the price of access can rise at renewal once you depend on it.
Can we use a service account	Just use an admin login	Scoped account, rotatable	A staff login as integration credentials fails the day that person leaves.
How do we get our data out	That would be professional services	Defined export, in the contract	Ask what it includes, the format, the time and the cost. Then put it in writing.

Mistakes Made During Software Selection

The assessment was done by people who will not integrate it

Software selection is usually run by the department that will use the product, and integration capability is not something they can reasonably assess. The result is a product chosen on features that then costs several times the expected amount to connect, or cannot be connected in the way the business needs at all. Include someone who understands integration in the evaluation, give them the shortlist and an hour with each vendor, and treat their findings as a scoring criterion rather than a footnote.

Salesperson assurances were never written down

A verbal yes during a demo is worth very little six months later when the person has moved on and the capability turns out to be on a roadmap. Anything you are relying on should be in the contract or at minimum in an email that forms part of it: the objects covered, the tier that includes access, the notice period for changes, the availability of a test environment, and the terms of a data export. Vendors who are confident will agree readily, and reluctance to put an assurance in writing is itself informative.

The pilot only tested the user interface

A proof of concept that exercises the screens tells you whether people like the product and nothing about whether it will integrate. Where the integration is important, make a small technical trial part of the evaluation: connect to the test environment, read and write the objects you actually need, and see how the documentation, the errors and the support hold up. A day of this frequently eliminates a shortlisted product, and always for a better reason than any demo would have given you.

Nobody asked where the data is stored

For Australian businesses handling personal information, knowing which country a system stores data in, and which other providers it passes information to, is part of meeting obligations under the Privacy Act 1988 and the Australian Privacy Principles. Overseas storage is not prohibited and it does carry specific requirements. Ask early, get the answer in writing, and ask the same question about any sub-processor the vendor relies on, because that detail is rarely volunteered and is difficult to establish afterwards.

Exit was never discussed

The natural time to negotiate data portability is before you sign, when the vendor wants your business, and the natural time to need it is years later when the relationship is ending. Ask what a complete export contains, whether it includes attachments and historical records, in what format, how long it takes and what it costs. Get it into the contract. Without that, an unsuitable product becomes one you cannot leave without an expensive extraction project, which materially weakens your position at every renewal.

The cheapest product had the weakest interface

There is a consistent pattern where the lowest licence cost pairs with the most limited integration capability, and the difference is recovered several times over in integration work, manual workarounds and the processes that never get automated. Compare on total cost including the expected integration effort rather than on licence price. A product costing more per year with a well documented, generously limited interface is frequently the cheaper choice within eighteen months, and demonstrably so if you cost the alternative honestly.

How Yes AI Helps With Software Selection

We sit in the vendor call and ask the awkward questions

One hour per shortlisted product, working through the list, with the vendor’s technical people rather than only the salesperson. You get a written comparison of what each product can actually do, scored against the flows you will need rather than against a generic checklist.

A technical trial where it matters

For significant decisions we connect to each vendor’s test environment and try to do the specific things your business needs, then report on how the documentation, the errors and the support held up. It is a day of work that regularly removes a product from a shortlist for a substantive reason.

The terms you should get in the contract

A short list of the assurances worth writing into the agreement: objects covered, tier including access, price protection on that access, notice period for interface changes, test environment availability, data storage location and export terms. Handed over for your procurement people to use.

Advice that is not tied to a build

We will tell you when a product is well supported enough that a standard connector will cover you, and when the honest recommendation is a different product entirely. We would rather you buy the right system than buy the wrong one and pay us to work around it for three years.

Assessing Integration Capability Before You Commit

Five steps that fit inside a normal software selection process and add about a week to it.

Write down the flows this system will need

Which data has to move in and out, in which direction, how fresh it needs to be and at what volume. This is what turns a general assessment into a specific one, because a product can be excellent in general and unable to do the one thing you need.

Read the documentation before the demo

Public documentation tells you more in twenty minutes than an hour of presentation. Check your objects and directions against it, note what is missing, and take those gaps into the vendor conversation as specific questions rather than general ones.

Put the questions to their technical people

Coverage, limits, events, sandbox, versioning, access model, data location and export. Ask for numbers rather than adjectives, and note which answers the vendor will put in writing and which they will not. The pattern of what they decline is informative on its own.

Run a small technical trial

Connect to the test environment and attempt the actual things you need, not a generic sample. Assess the documentation, the error messages and the support responsiveness while you are still a prospect, which is when a vendor is at their most helpful.

Get the assurances into the contract

Objects and access tier, price protection on that access, notice period for interface changes, test environment, data storage location and sub-processors, and the terms of a complete data export on exit. Negotiated now, while you still have the leverage to ask.

FAQ

Ask the Awkward Questions While They Still Want Your Business

Book a vendor assessment. We join the calls, test the interfaces against what you actually need, and hand you a written comparison plus the terms worth getting into the contract. Yours whether or not we build anything.