Choose an automation consultant by asking each candidate to work from one real workflow and show how they will scope, test, secure, support, and hand off the result. Tool logos and polished demos reveal very little about how the system will behave with your data and exceptions. A written proposal should make the business outcome, acceptance criteria, access, failure plan, ownership, and exit clear before you sign.
Do you need an automation consultant yet?
You may need an automation consultant when a recurring problem crosses systems, includes important exceptions, or needs someone to own the path from diagnosis to a working production process. You may not need one when a supported feature inside one tool solves the problem safely.
Start with the shape of the work. A native CRM rule may be enough to assign a lead. A documented import may be enough for a monthly transfer. A consultant becomes more useful when customer data moves across several tools, a failure can delay service or billing, the team cannot agree where a record is authoritative, or previous attempts have become difficult to maintain.
The process also needs enough stability to examine. If the team changes the steps every week, the first job is usually to clarify the workflow. That clarification may become a small paid audit, but it should not be disguised as a commitment to a large build.
When not to hire an automation consultant yet
Wait when no one owns the process, the problem has no recent example, the expected benefit is too small to justify maintenance, or a supported feature you already pay for has not been evaluated. Stabilize the work first when every case follows a different path. Sensitive customer, employee, health, or financial data may also require legal, privacy, or security review before a consultant receives access.
The guide What Should a Small Business Automate First? helps separate a suitable first workflow from a vague request to “automate the business.”
What should you prepare before talking to candidates?
Prepare one recent example from trigger to completion, including the tools, people, decisions, delays, corrections, and exceptions involved. You do not need to write a technical specification before the first conversation.
Bring the original request, form, email, record, or document if you can share it safely. Show where someone copies information, waits for approval, makes a judgment, or repairs an error. Then describe the outcome that matters: a customer request reaches the right owner, an approved record appears once in the accounting system, or a draft is ready for human review.
Record a small baseline during a useful observation period. Count occurrences, active handling time, corrections, unmatched cases, and downstream delays. The purpose is not to manufacture a return-on-investment claim. It is to give every candidate the same starting point and to expose new work created by the proposed solution.
A credible candidate should help refine this material. Be cautious if someone names a platform, architecture, or large scope before seeing how the task works today. My own approach starts by tracing the task, its tools, exceptions, and manual handoffs before choosing what to simplify, automate, or keep human.
What evidence should you ask each candidate to provide?
Ask for an observable artifact or demonstration behind every important promise. “Reliable,” “secure,” and “easy to maintain” are intentions until the proposal explains how you will verify them.
| Candidate promise | Evidence to request | What the proposal should name |
|---|---|---|
| "We understand the workflow" | A current-state map based on a real case, including decisions and exceptions | Trigger, owner, systems, inputs, outputs, exceptions, and what remains human |
| "The scope is clear" | A result you can accept or reject, plus explicit exclusions | Deliverables, boundaries, assumptions, dependencies, and change process |
| "Your data is protected" | An access plan and a list of data used during build and support | Client-owned accounts, permissions, test data, retention, revocation, and incident contact |
| "The automation is tested" | Representative scenarios and recorded results | Normal cases, missing data, duplicates, failures, retries, and acceptance criteria |
| "You can operate it" | Documentation, a runbook, and a handoff session | Monitoring, alerts, exception owner, manual fallback, training, and support period |
| "You are not locked in" | A practical exit walkthrough | Ownership of accounts, code and configurations, exports, credentials, documentation, and transition help |
Acceptance criteria are observable conditions for approving the work. For a CRM-to-accounting handoff, they might state that one approved customer creates one draft, required fields are validated, an existing customer is updated rather than duplicated, and a failed transfer reaches a named person. They should describe behavior, not merely say that the integration is “complete.”
Case studies help only when their scope and evidence are clear. Ask what the consultant actually did, which result was measured, over what period, and what remains confidential. A portfolio can demonstrate relevant types of work without proving a savings claim. My public work follows that boundary: it shows the intervention and functional change, while avoiding numbers that were not measured.
How do you compare proposals with different scopes?
Compare proposals by normalizing the work into the same decision fields. A low quote for a connector setup is not comparable with a proposal that includes process mapping, data cleanup, testing, documentation, launch support, and maintenance.
| Decision field | Question for every proposal |
|---|---|
| Business outcome | What observable work changes when the project is accepted? |
| Included workflow | Which trigger, records, rules, systems, and users are in scope? |
| Exclusions and assumptions | Which exceptions, migrations, licenses, and team tasks are outside the price? |
| Acceptance | Who tests which scenarios, and what happens when a criterion fails? |
| Access and data | Which accounts and data are used, who owns them, and when is access removed? |
| Launch and fallback | How is the change introduced, monitored, paused, or reversed? |
| Support and maintenance | Who responds to failures and vendor changes after launch, on what terms? |
| Total cost | Which build fees, software charges, usage costs, support, and internal time recur? |
| Ownership and exit | What can your business operate or transfer when the relationship ends? |
This comparison also reveals different services hiding under the same title. One candidate may sell a diagnosis and roadmap. Another may configure a standard platform. Another may build and maintain a custom connection. None is automatically the right category. The proposal should match the problem you need solved now.
Avoid turning the table into a score that hides a critical failure. A candidate with a strong portfolio but no acceptable data-access plan is not balanced out by extra points elsewhere. Mark nonnegotiable requirements separately from preferences, then compare the remaining tradeoffs.
How should access and data be handled?
System access should be limited, documented, and controlled by your business wherever the tools allow it. The consultant should explain what they need during discovery, build, testing, launch, and support, because those stages do not always require the same permissions.
The Federal Trade Commission's guidance on service providers recommends checking how a provider will secure data, putting security expectations and monitoring methods in the contract, and verifying compliance. The FTC's examples also show why testing actual behavior matters before release. A contractual promise does not replace verification.
CISA provides a vendor-assessment guide for small and medium-sized businesses, including situations where a provider receives logical access to systems or data. NIST's small-business vendor page likewise points owners toward selection, contract, and relationship-management questions. These resources are security frameworks, not endorsements of a particular consultant or substitutes for advice on your legal obligations.
In practical terms, prefer client-owned accounts, named users, multifactor authentication, and the least privilege each task requires. Use a test environment or minimized data set when feasible. Record which credentials, API keys, shared folders, logs, and subprocessors are involved. The exit plan should include revoking access and rotating credentials that may have been exposed.
What should the first engagement look like?
The first engagement should reduce uncertainty and leave a useful result even if you do not expand the relationship. Choose a focused diagnosis when the problem is unclear, or a limited production workflow when the outcome and boundaries are already understood.
A verifiable first engagement
- Real workflowA recent case exposes the actual steps, systems, decisions, and exceptions.
- Written scopeThe outcome, boundaries, assumptions, price, and change process are explicit.
- Controlled accessAccounts, data, permissions, retention, and revocation are agreed before access.
- Acceptance testsRepresentative cases verify normal work, failures, retries, and exceptions.
- Handoff and supportDocumentation, monitoring, fallback, ownership, and exit are assigned.
- Trace a recent case. Confirm the current steps, systems, owners, decisions, exceptions, and manual recovery.
- Write the result and boundaries. Name the output, exclusions, dependencies, price, timeline, and change process.
- Define access before granting it. Decide which accounts, data, environments, permissions, and retention periods are needed.
- Agree on acceptance scenarios. Include normal work, missing or conflicting data, a duplicate event, a system failure, and a safe retry when they apply.
- Run with a fallback. Start in a test, draft, or parallel mode when the tools and risk justify it. Keep a manual path for current work.
- Accept the behavior, not the demo. Review records, logs, exceptions, permissions, and the result produced from representative cases.
- Complete the handoff. Store documentation in a client-controlled location, assign monitoring and support, and confirm how access and ownership change at exit.
A small first scope is useful only if it exercises the parts that matter. A polished prototype with sample data may test the interface while avoiding identity matching, permissions, exceptions, or recovery. The pilot should be narrow enough to manage and real enough to expose those responsibilities.
What to remember
- Start with one real workflow and an observable business outcome.
- Ask for evidence behind claims about scope, security, testing, maintenance, and ownership.
- Normalize competing proposals before comparing price.
- Keep accounts under business control, limit access, and define revocation and incident responsibilities in writing.
- Use acceptance criteria, a manual fallback, documentation, and an exit plan before expanding the engagement.
I sell this kind of work, so apply the same questions to me. If you have a recurring workflow, the tools it crosses, and a proposal you are trying to evaluate, bring them to a free 30-minute call. We can determine whether you need a supported feature, a focused audit, or a build with a clear acceptance test.
Frequently asked questions
Match the provider to the scope and risk. A platform specialist fits a workflow that clearly belongs inside one product, an agency can supply multiple roles for a broader program, and an independent consultant can provide direct continuity between diagnosis and implementation. Compare the named people, responsibilities, support, and exit rather than the category alone.
Prefer business-owned accounts and named, limited access when the platforms support them. Avoid sharing a primary administrator login. The proposal should state who creates accounts, who pays subscriptions, what permissions are granted, and how access is revoked at the end.
It should name the business outcome, included workflow, exclusions, assumptions, deliverables, acceptance criteria, access, data handling, launch plan, fallback, documentation, support, recurring costs, ownership, and change process. A proposal can be concise, but those decisions should not remain implicit.
A paid audit can be useful when the problem spans several processes or the right first scope is unclear. Define its deliverables before buying it, such as a current-state map, prioritized options, risks, cost ranges, and a build-ready scope. The audit should remain useful if another provider performs the implementation.
Written by Antoine mazu. Antoine helps small service businesses understand and improve their workflows with solutions tailored to their needs, with or without AI. He combines product thinking with hands-on technical execution from Bayonne, France.
Sources accessed September 18, 2026: FTC, Stick with Security, CISA, Assisting SMBs Assess Vendors and Suppliers, NIST, Choosing a Vendor/Service Provider, Antoine mazu's approach, and Antoine mazu's work.
