Begin with the bottleneck, not a model
Common candidates include copying approved information between systems, sorting routine inbound requests, preparing predictable reports, and flagging missing records. Less suitable first projects include unstructured decisions with no accountable owner, sensitive actions without approval gates, or processes that nobody agrees how to perform.
Ten readiness questions
For each question, answer Yes, Partly or No. This is a working discussion checklist, not a validated diagnostic score.
- Purpose: can someone define the task's expected output in one sentence?
- Repetition: does it happen often enough for improvement to matter?
- Inputs: are the inputs accessible, permitted and consistently structured?
- Rules: can the decision logic be described or bounded?
- Exceptions: do we know when to stop and ask a human?
- Ownership: is one person accountable for accepting the result?
- Permissions: are data, vendor access and consent requirements clear?
- Evidence: can we record success, failure and recovery without exposing sensitive information?
- Economics: can we estimate labor saved or value created after operating costs?
- Fallback: can the old workflow take over if automation stops?
Choose a bounded pilot
Pick a task with strong answers across most criteria. If ownership or authorized access is missing, address that before building. Treat unclear exceptions as a design problem—not a reason to make the automation guess.
For a first pilot, define what is in scope, what is prohibited, and what evidence will be reviewed. Example: automatically classify approved incoming service requests for human review, but do not send outbound communications or change customer account settings.
Measure the right baseline
| Before pilot | During pilot | Decision at review |
|---|---|---|
| Current time per task | Automation time plus human review | Was net time saved? |
| Manual error and rework | Incorrect classifications and recoveries | Was quality improved? |
| Cost per completion | API, support and operational usage | Is the economic case credible? |
| Customer wait time | Observed response and resolution | Did the customer experience improve? |
A suggested 30-day sequence
- Week 1: baseline, map rules and define acceptance tests.
- Week 2: sandbox or shadow-mode implementation with no unrestricted external actions.
- Week 3: review exceptions, tune rules, validate logs and demonstrate fallback.
- Week 4: review evidence and choose to stop, continue in scope or propose an approved expansion.
An automation isn't ready because it can run. It's ready when it can be trusted, supervised and recovered.
Helpful next steps
Use HDP's public Automation Priority Scorer for a structured first look, or browse the Tasks Marketplace for narrower reliability and diagnostic offers. A complete Business OS becomes more interesting after you know which handoffs need to be connected.
Editorial guide from HDPJoin. The examples are illustrative and not representations of results for actual customers. Capabilities, terms, permissions and deployment readiness are evaluated separately for each HDP offer.
Keep exploring
Browse other practical guides · Find your next step · Follow future topics