What should an automation proposal include? A buyer scorecard
Review scope, acceptance evidence, ownership, monitoring, and ongoing costs. Download a buyer scorecard and test template that make unresolved gaps visible.
Published by DWKD. This buyer guide and editable scorecard use synthetic acceptance examples. They are not client results, a supplier certification, or a promised engagement scope.
An automation proposal should let you answer four questions: what will change, how will we know it works, who will own it, and what will it cost to operate? A list of platforms and a delivery date cannot answer those questions by itself.
Use this guide when you have a specific proposal to review. Download the automation proposal buyer scorecard for an editable evidence checklist and acceptance-test template. The goal is a decision you can explain, with unresolved items visible before work begins.
Define a boundary that both sides can inspect
Replace “automate customer onboarding” with a named trigger, eligible records, actions, destination, and end state. For example: after a request is approved in a specified queue, create one work item in the delivery system, assign it using an agreed rule, and return a reference to the original request.
Then identify what is excluded: unapproved requests, historical cleanup, undocumented systems, ambiguous matches, or customer-facing messages that still need review. Ask what happens to those cases. An exclusion without a manual route can leave an operational hole.
The proposal should identify the source of truth, required fields, who supplies access, and assumptions about data quality and volume. If those facts are unknown, make the investigation a defined deliverable with a decision point. Do not treat an unexplored integration as a confirmed dependency.
Connect deliverables to acceptance evidence
“Workflow delivered” is less useful than a list of artifacts and observable checks: editable source or workflow export, configuration record, tested connections, runbook, monitoring setup, and acceptance results. Name a buyer-side approver and the environment in which each check will run.
- Requirement: one approved request creates one correctly assigned work item.
- Test: submit a known request, then replay it.
- Evidence: compare the request, run records, and actual destination items.
- Decision: accept, request a correction, or defer with an owner and reason.
Use a representative test set, including inconvenient inputs. Define expected outcomes before the demonstration. Ask for results you can inspect, not just a screen recording of the easiest case. Agree how defects differ from new requirements and how changes affect scope, cost, and acceptance.
Ask to see failure and recovery
A missing response does not necessarily mean an action failed. AWS explains why safe retries require attention to idempotency: repeating a request must not unintentionally repeat its effect. Ask the supplier to demonstrate the behavior of your destination system rather than promising universal “exactly once” execution.
| Case | Expected outcome to agree | Evidence to inspect |
|---|---|---|
| Valid request | One item, correct owner, reference returned | Source request and destination record |
| Same request replayed | No second item or repeated notification | Destination count and replay record |
| Required identifier absent | No destination change; visible review item | Review queue entry and reason |
| Destination stores item but reply is lost | Reconcile before retrying a possibly completed action | Stored item, recovery decision, and final state |
| Permission revoked | No broader access attempt; work remains recoverable | Access error, alert, and retained work reference |
| Operator stops the workflow | Defined handling of queued and in-flight work | Stop procedure and reconciliation checklist |
These are starting cases, not a complete safety standard. Your proposal must resolve what “stop” means when an action is already underway and who may replay work. The DWKD recovery demonstration makes duplicate and failure behavior inspectable using synthetic data; a production integration still needs its own tests.
Make ownership operational
Ask whose organization controls the accounts, workflow definitions, connections, documentation, and relevant data. Identify the permission needed for each action and separate build access from routine operating access. Decide who can change, approve, disable, and recover the workflow.
Require a handoff that another authorized operator can follow: where configuration lives, how credentials are renewed, how exports are obtained, and what happens when the original builder leaves. Do not accept a critical integration whose only known owner is an individual’s unreviewed personal connection.
Platform details matter. Microsoft’s cloud-flow ownership documentation connects ownership to management, permissions, troubleshooting, and licensing, and distinguishes transfer paths. Ask the supplier to verify the chosen platform’s actual transfer process. A general promise that you “own everything” does not perform that transfer.
Specify monitoring, response, and the exception queue
Define what the owner will watch: expected inputs received, outputs reconciled, failed runs, aging exceptions, connection health, and usage cost. Identify who receives each alert, during which coverage hours, and what happens when that person is unavailable. Do not assume a support subscription means round-the-clock response.
Ask how silent failures are detected, including a workflow that stops receiving expected inputs. Microsoft documents that Power Automate per-run failure emails do not cover every failure. An email notification feature is therefore not a complete monitoring plan.
Agree where run evidence is stored, who may inspect it, and which sensitive fields should be excluded. Decide retention and deletion requirements explicitly. The runbook should explain how to diagnose, stop, repair, and reconcile work, plus when to call for help.
Compare total operating cost under more than one volume
Separate discovery and implementation from recurring licenses, premium connectors, API usage, storage, monitoring, maintenance, and support. Where AI is used, include the model usage assumptions and who authorizes additional spend. Include buyer staff time spent reviewing exceptions and managing the system.
Request an expected-volume estimate and a higher-volume scenario, with the source and date of any vendor pricing. Clarify billing ownership, included usage, overages, support boundaries, change requests, and the effort needed to exit or migrate. These are questions to resolve in the proposal, not universal prices.
Compare that total with an evidenced baseline. The first-automation workbook separates useful capacity from cash savings and includes exceptions and maintenance. A proposal should not count every minute freed as immediate payroll savings.
If AI is included, require a reason and an evaluation
Ask which decision needs model judgment and why a rule or existing feature is insufficient. Define acceptable outputs, uncertain cases, human approval points, and the actions the system is permitted to take. Evaluate examples beyond the ones used to build the prompt.
The DWKD answer-evaluation demonstration shows an inspectable offline evaluation structure. It does not prove a model is accurate or suitable for your process. A supplier’s evaluation should reflect your actual task, permissions, and consequences.
Use the scorecard to expose gaps, not award a badge
Mark each item missing, partial, evidenced, or not applicable. For “evidenced,” record the artifact, reviewer, and date. For “not applicable,” explain why. Keep open questions assigned to a person and a decision date.
Do not average away a critical gap. Unclear access, an unowned exception queue, untested duplicate effects, or no workable handoff can block acceptance even if most boxes are filled. A completed checklist is a record of your review, not a guarantee of safety or delivery.
For help turning an unclear proposal into testable requirements, explore DWKD AI and automation consulting or Work with Kenny. Start with the outcome, the scope you are considering, and the decisions that remain unresolved.