How to choose an automation partner

Look for a partner who documents your process before building, tells you which work should stay manual, builds in systems you own, designs explicit human review points, and states plainly what happens if the engagement ends. Tool expertise matters less than process discipline.

Start with who owns the result

The most consequential question is where the work lives. If processes are built inside accounts, platforms and infrastructure the partner controls, ending the relationship means rebuilding from scratch — and both sides know it. If they are built in systems you own, with documented configuration, you can change partners without changing outcomes.

This is not a trust issue. It is a structural one, and it should be settled in writing before any build begins.

Evaluate the process, not the demo

A demonstration shows what a tool can do under conditions the vendor chose. It tells you very little about how the partner will handle your undocumented exception, your two systems that disagree, or the week the API changes.

Better signals: how they scope, whether they insist on documenting the process before building, whether they test against real cases including failures, and whether they can describe a project that did not work and what they changed afterwards.

Ask what they would not automate

A partner who finds every process suitable is selling, not assessing. Judgment that depends on relationship, decisions with legal or financial consequence, and rules that change too frequently to stabilise should all be identified as unsuitable — and a competent partner will say so unprompted.

The same applies to sequencing. If the recommendation is to automate everything at once, the plan has not been thought through.

Ask how oversight is designed

Any serious proposal should say where people remain in the process: which actions require approval, who is notified when something fails, and what the system is permitted to do without asking. Vagueness here usually means the question has not been answered rather than that the answer is unremarkable.

Ask about maintenance explicitly

Integrations break when either side changes. Establish who monitors, what the response time is, whether repairs are included or billed, and how business-rule changes are handled after launch. An engagement with no maintenance arrangement has an owner by default: you, without warning.

Ask about claims and evidence

Where a partner cites results, ask what was measured, over what period, against what baseline, and whether other changes were happening at the same time. Reputable answers are specific and appropriately qualified. Round numbers with no baseline are marketing.

Exit terms

Before signing: what you keep, what documentation is handed over, how long transition support lasts, and whether any part of the running system depends on the partner's accounts or credentials. A partner confident in their work answers these directly.

How Suora approaches this

Our model — strategy, system, management, outcomes — is described on how it works, and pricing follows scoping rather than preceding it, as set out on the pricing page. If you want to test the questions above against a real conversation, book a consultation.

Frequently asked questions

Does it matter which platforms a partner specialises in?

Less than it appears. Platforms change; process discipline does not. A partner who documents, tests and hands over well will produce a better result on an unfamiliar tool than the reverse.

What is the single most important contractual question?

What happens to the running processes if the engagement ends. If they live in systems the partner owns, ending the relationship means rebuilding.