How to choose an automation agency

Make the comparison fair with one brief

Describe the work as a business event. A service enquiry arrives, someone checks the area and capacity, a response is prepared and an existing customer record may need updating. Name the start and the accepted finish. Listing ten apps without that boundary invites ten different interpretations of the job.

Supply synthetic or appropriately redacted examples of a complete item, a missing field and a changed request. State the current volume and which application is authoritative for each important fact. Ask each provider to explain what information is still missing before quoting.

Give the same facts to everyone. If one proposal assumes clean records and another includes historical cleanup, the total prices do not describe equivalent work. Separate discovery, build, migration and ongoing operation so you can see where the difference comes from.

Ask for evidence at the point where the system acts

Request a demonstration that follows one record through to a saved outcome. Which source supports the field? Who approved the action? How do you know the destination accepted it? A successful-looking canvas is less useful than an output your team can check.

Then change something. Send the same event again, remove a required value or revise an already accepted brief. You are looking for a clear held state and a safe recovery path. An agency does not need to solve an unknown API live on a call, but it should recognise what must be investigated.

Treat client proof separately from capability examples. Ask whether a displayed system is fictional, a prototype or approved client work. For a performance claim, ask for the baseline, measurement period and what changed. Private client material is not something a responsible provider should reveal on demand.

Put these answers beside each quote

A useful proposal makes uncertainty visible. It identifies supported operations, plan or permission dependencies, exclusions and the assumptions that could move the price. A supplier who names an unresolved dependency is giving you a decision, not necessarily offering a weaker build.

Ask for an acceptance checklist your process owner can use. The delivery definition should cover both complete outputs and intentionally held work. A system that refuses an unsafe action can be behaving correctly; your tests need to distinguish that from a silent failure.

Check access and handover while you still have choices

We build in your accounts and hand over workflows, documentation, exports and a recorded walkthrough. Use that as a concrete comparison point. Confirm that another competent operator can obtain the necessary access without depending on a personal account controlled by the original builder.

Ask where data travels. An Australian hosting option does not answer where connected applications, AI providers, backups or support access are located. A provider should be able to describe the intended data path and identify decisions requiring your organisation's own review.

Licence and edition choices also matter. n8n documents different self-hosted editions. Operating your own deployment needs the relevant hosting skills. If a proposal relies on self-hosting, ask who will patch, back up, restore and monitor it. Do not accept a free-edition label as a complete operating plan.

Read the care scope before accepting the build

Support needs to cover failed runs, empty results and expected work that never started. The written scope should name alert recipients, who checks the business outcome and what someone can do manually while a dependency is unavailable.

Separate a repair from a new requirement. An API changing can require maintenance; your business adding a new service line can require fresh scope. Ask how these decisions are estimated and approved. Do not infer unlimited changes or a response guarantee from the word support.

Finally, ask for a short summary of unresolved risks and the next decision. You should leave a proposal review understanding what you are buying, what remains uncertain and what evidence would settle it. A clear smaller engagement is usually easier to accept and operate than an ambitious promise with missing boundaries.

Put three hypothetical proposals on the same worksheet

Imagine you need an accepted service request to create a delivery task and an accounts draft. The input sometimes arrives without a site address, returning customers may have an existing record and a revised request can change the agreed date. Give those three conditions to every provider. They define what the business needs more clearly than asking for an automation between a form, a CRM and an accounting app.

Proposal A describes the successful path only. It creates a new record for every form submission and leaves data cleanup, duplicate handling and operator instructions with your team. That could suit a controlled internal trial with clean inputs. It would be a different purchase from a process expected to receive unfiltered customer requests immediately. Ask the supplier to name that boundary in the quote.

Proposal B includes matching, a missing-information queue, an approval before accounts preparation and a check of the saved result. It supplies a shared test packet, operating notes and a recorded walkthrough. Its larger scope may explain a higher fee. You still need to ask which application plans and permissions it assumes and who is responsible for resolving held work after launch.

Proposal C starts with a paid investigation because the required update operation has not been established in your account. Its deliverable is a verified capability finding, a process map and priced options. It is not yet a fixed production build. If that dependency determines whether the project can work at all, the investigation may be the most useful next purchase. Compare its fee and deliverable with that decision, not with a completed system.

Do not score these proposals as good, better and best without considering your team. If you already have an experienced operator who will own data quality and recovery, a smaller build may be enough. If nobody owns those jobs, their absence is a gap rather than a saving. Resolve the missing responsibility before asking a provider to match another supplier's total.

Ask for an acceptance packet before the final invoice

An acceptance packet connects the written scope to the behaviour you can inspect. It should contain a test reference, the input used, the expected output and the actual result. Add the source version or approved rule where it affects the outcome. A screenshot of a green workflow run is supporting evidence; it does not establish that the right customer record was updated with the right value.

Use a normal request first. The output should contain the agreed fields, the current scope and the owner of the next step. Then submit the same event again in the test environment. The expected outcome may be no new record and a clear duplicate-event note. That is a successful test even though it does not produce a second task. Make the difference between no extra action and lost work explicit.

Next, change a material field after an approval. A revised date or added site should reopen the decisions it affects. Check which earlier approvals remain valid and which do not. A design that discards every useful fact can create unnecessary work. A design that reuses all earlier approval can make an unsupported commitment. The provider should be able to explain its choice against the actual process rules.

Finally, inspect an unavailable dependency. Does the system know the write failed, or did it lose the response and leave an uncertain outcome? Who checks the destination before retrying? Ask your intended operator to follow the recovery instruction using the test record. If they cannot tell what has already happened, the procedure needs more work before that operator is expected to recover a real incident.

Keep an unresolved-issues list with an owner and decision for each item. An excluded operation should not quietly become a promise to fix everything after launch. Equally, a minor visual issue should not obscure a material missing permission or unsafe retry. Agree which issues block acceptance, which belong to a later change and which are a documented limitation your business accepts.

Compare the working relationship and the exit path

Ask who will join discovery and who will make technical decisions during delivery. A small project may have one person covering several roles, which can work well when those responsibilities are clear. What matters is whether your process questions reach someone who can resolve them and whether important decisions are written down rather than left in a passing call.

Agree how changes are proposed. Your team may learn something useful during testing, but a new business rule or extra application can change the effort. A good change request explains the proposed behaviour, why it is needed, the effect on cost and timing and what happens if you leave it for later. That lets you choose deliberately instead of discovering extra scope in an invoice.

Check the exit path while everyone is cooperating. Can you access the accounts, retrieve the workflows and find the current operating notes? Who holds the credentials needed to restore the system? Which vendor subscriptions are yours to maintain? A recorded walkthrough helps, but it should point to documentation and owned accounts rather than substitute for them.

Use the answers to make a short selection note. State why the chosen provider fits the process, what your team must still supply and which uncertainties remain. That note is more useful than a long scorecard whose numbers disguise subjective judgement. It also gives you a clear basis for the kickoff conversation and later acceptance review.

Make a reference conversation specific to your risks

If a provider can arrange an approved client reference, use the conversation to test the working relationship and operating handover. Ask what the client had to prepare, which decisions took longer than expected and whether their team could use the documentation afterwards. A reference is more informative when the process has similar approval or recovery needs, even if the businesses are in different industries.

Ask how the supplier handled a change or an exception. Did the client understand the options and cost before work continued? Was it clear who owned the problem? Could another operator follow the recovery instructions? These questions are more useful than asking whether the client liked the provider. They connect the reference to the risks you will need to manage in your own engagement.

Respect the limits of what the client has agreed to share. You do not need access to private customer records, prompts or a complete production workflow to understand whether the delivery process was sound. An approved description of scope, evidence and responsibility can be enough. If no relevant reference is available, account for that uncertainty through a smaller first engagement and clearer acceptance evidence.

Keep the reference alongside the proposal rather than allowing it to replace the proposal. A strong experience on one project does not establish that your required application operation exists or that your team has settled its own rules. Verify the dependencies of your build and keep the written delivery boundary specific to the work you are buying.