Most automation backlogs are not backlogs. They are wish lists with better table formatting.
An automation pilot intake template fixes that. It forces every idea through the same questions before anyone burns a sprint wiring together a fragile demo nobody will own.
Short answer
Use an automation pilot intake template to capture the business problem, current workflow, volume, manual effort, systems, data inputs, decision points, exceptions, risks, owner, success metric, and expected ROI for every automation idea. Then score each candidate on value, feasibility, risk control, process clarity, and adoption readiness. The first pilot should be boring, frequent, measurable, and safe enough to run with human review.
If you only do one thing: collect the intake, run the numbers in a workflow automation ROI calculator, and pick the highest-value workflow that can ship in 2 to 6 weeks.
The copy-ready automation pilot intake template
Use this as a form, spreadsheet, Notion database, Airtable base, or CRM object. Do not over-design it. The point is to make weak automation ideas expose themselves quickly.
| Field | Question | Format | Why it matters |
|---|---|---|---|
| Workflow name | What process should be automated? | Short text | Creates a clear label for the pilot backlog. |
| Business owner | Who owns the outcome? | Person | Automation without an owner becomes technical debt with a calendar invite. |
| Current trigger | What starts the workflow? | Short text | Defines when the automation should run. |
| Current output | What should exist when the workflow is done? | Short text | Clarifies the business result, not just the task. |
| Pain type | What is the main problem? | Select: slow, manual, error-prone, expensive, risky, hard to scale | Separates real pain from tool curiosity. |
| Business consequence | What happens if this stays manual? | Paragraph | Connects the work to money, time, revenue, risk, or customer experience. |
| Monthly volume | How many cases happen per month? | Number | Repetition determines whether automation has leverage. |
| Time per case | How many minutes does one case take today? | Number | Required for ROI and capacity savings. |
| People involved | Which teams touch the process? | Multi-select | Shows handoffs, approvals, and adoption surface area. |
| Systems involved | Which tools does the workflow touch? | Multi-select | Exposes integration work early. |
| Data inputs | What documents, records, messages, or fields are required? | Checklist | Determines whether the workflow is ready for AI or basic automation. |
| Decision points | What judgment does a human make today? | Paragraph | Identifies where AI can classify, extract, summarize, route, draft, or recommend. |
| Exceptions | What cases break the happy path? | Paragraph | Exceptions usually decide the implementation architecture. |
| Risk level | What can go wrong if automation is wrong? | Select: low, medium, high | Determines whether the first version can act, draft, or only suggest. |
| Human review point | Where should a person approve or correct the output? | Short text | Keeps the first pilot safe and auditable. |
| Success metric | What number proves the pilot worked? | Short text | Prevents “it feels better” reporting. |
| Baseline | What is the current number for that metric? | Number/text | Without a baseline, ROI is fan fiction. |
| Target | What improvement would make the pilot worth scaling? | Number/text | Creates a go/no-go threshold. |
| Implementation window | Can a useful version ship in 2 to 6 weeks? | Yes/no | Keeps pilots narrow enough to reach production. |
| Adoption owner | Who will train users, collect feedback, and maintain the workflow? | Person | Prevents post-launch abandonment. |
The intake questions to put in your form
1. What workflow are you proposing?
Describe the process in one paragraph. Include the trigger, current owner, current output, and the team that depends on it.
Bad answer: “Automate onboarding.”
Good answer: “When a new vendor submits onboarding documents, operations checks the W-9, banking details, contract status, insurance certificate, and internal approval record before finance can create the vendor in the ERP.”
2. Why does this matter now?
Ask the requester to choose the primary pain:
- Too slow.
- Too manual.
- Too error-prone.
- Too expensive.
- Too hard to scale.
- Too risky.
- Too dependent on one person.
Then ask for the business consequence. “It takes time” is not enough. “Vendor onboarding delays project kickoff by 5 business days” is useful.
3. How often does it happen?
Capture cases per week or month, seasonal spikes, and expected growth. A workflow that happens 400 times a month with moderate pain is usually a better first pilot than a dramatic executive workflow that happens twice a quarter.
4. How much manual effort does one case require?
Estimate minutes per case and total monthly hours. If nobody knows, sample 10 recent cases and use the median. Guessing is allowed for intake; pretending the guess is a measurement is where teams get into trouble.
5. Which systems are involved?
List every system touched by the workflow:
- Email or shared inboxes.
- Slack or Microsoft Teams.
- Spreadsheets.
- CRM.
- ERP.
- HRIS or ATS.
- Ticketing tools.
- Cloud storage.
- Databases.
- Vendor portals.
- Internal admin tools.
This is where many no-code pilots quietly die. If the workflow needs data from three systems and an approval in a fourth, the intake should reveal that before someone promises “a quick Zap.”
6. What data or documents are required?
Examples include invoices, contracts, resumes, support tickets, call notes, order records, PDFs, emails, CSV exports, screenshots, CRM fields, or ERP records.
For document-heavy candidates, pair this intake with the invoice OCR implementation checklist before letting automation update anything downstream.
7. What decisions does a human make today?
This question identifies whether the candidate needs basic workflow automation or AI-assisted automation.
Look for decisions such as:
- Classify the request.
- Extract fields from a document.
- Summarize a thread.
- Match a record to the right account, candidate, invoice, or vendor.
- Route work to the right owner.
- Draft a response.
- Flag risk.
- Recommend approval or rejection.
If the task is purely “move this field from A to B,” traditional automation may be enough. If the task requires interpretation, AI may be useful, but only with review, evaluation, and exception handling.
8. What exceptions happen?
Ask for the weird cases. Duplicate records. Missing documents. Conflicting dates. Unclear approvals. Customers using the wrong form. Vendors sending photos of PDFs because apparently civilization has limits.
Exceptions determine the build pattern:
| Exception pattern | Better first design |
|---|---|
| Rare and low-risk | Automate the happy path; route exceptions to a queue. |
| Common but easy to detect | Add validation and missing-info follow-up. |
| Common and judgment-heavy | Use AI to summarize and recommend, with human approval. |
| High-risk or irreversible | Keep automation in suggestion mode until controls are proven. |
9. What should automation be allowed to do?
Pick the first safe permission level:
| Permission level | What automation can do | Good for |
|---|---|---|
| Suggest | Recommend the next action | High-risk decisions, early testing |
| Draft | Prepare a message, record, or document for review | Email, contracts, support, onboarding |
| Route | Send work to the right person or queue | Intake, triage, approvals |
| Update | Change low-risk records | CRM cleanup, status fields, internal trackers |
| Trigger after approval | Take an external action once a human approves | Payments, customer comms, legal or finance workflows |
For first pilots, “suggest, draft, or route” usually beats “act autonomously and hope legal never asks.”
10. What metric proves success?
Good success metrics include:
- Hours saved per month.
- Cycle time reduced.
- Error rate reduced.
- Backlog reduced.
- Response time improved.
- Revenue captured.
- Risk reduced.
- Manual handoffs removed.
- SLA compliance improved.
Pair the intake with the workflow automation ROI calculator so the team can compare candidates on actual economics, not vibes in a steering committee deck.
Automation pilot scoring model
After intake, score each candidate from 1 to 5 across six dimensions.
| Dimension | 1 looks like | 5 looks like |
|---|---|---|
| Value | Nice-to-have convenience | Meaningful time, revenue, cost, customer, or risk impact |
| Volume | Rare edge case | Frequent, repeated work with enough volume to matter |
| Feasibility | Data inaccessible, systems closed, process unclear | Data available, integrations possible, process understood |
| Process clarity | Nobody can explain the current workflow | Steps, owners, inputs, outputs, and exceptions are known |
| Risk control | Wrong output creates serious damage with no review point | Human review and rollback are easy to design |
| Adoption readiness | No owner, users indifferent or hostile | Clear owner, annoyed users, obvious pull from the team |
Use this weighted score for prioritization:
| Dimension | Weight |
|---|---|
| Value | 25% |
| Feasibility | 20% |
| Volume | 15% |
| Risk control | 15% |
| Adoption readiness | 15% |
| Process clarity | 10% |
A candidate scoring 4.0 or higher is worth deeper scoping. A candidate under 3.0 should usually wait unless it supports a strategic initiative.
Example: completed intake for a strong first pilot
| Field | Example answer |
|---|---|
| Workflow name | Vendor onboarding document review |
| Business owner | Head of Operations |
| Trigger | Vendor submits onboarding packet by email or form |
| Output | Vendor record ready for finance approval |
| Pain type | Slow, manual, error-prone |
| Business consequence | Project kickoff is delayed when vendor setup takes more than 5 business days |
| Monthly volume | 120 requests |
| Time per case | 12 minutes |
| Systems involved | Gmail, Google Drive, vendor tracker, ERP |
| Data inputs | W-9, banking form, insurance certificate, contract record, approval email |
| Human decision | Confirm documents are present, match vendor name, flag missing or conflicting fields |
| Exceptions | Missing insurance certificate, mismatched legal name, duplicate vendor record |
| Risk level | Medium |
| Human review point | Operations approves extracted fields before finance creates vendor |
| Success metric | Reduce review time by 50% and cut missing-document follow-ups by 30% |
| Implementation window | 4 weeks |
| Adoption owner | Operations manager |
This is a good pilot because it is frequent, measurable, annoying, document-heavy, and controllable. The first version can extract, check, summarize, and route. It does not need to autonomously create vendors or approve bank details on day one.
What weak automation candidates look like
Say no, or at least “not yet,” when the intake reveals one of these patterns:
| Red flag | Why it is a problem | Better next step |
|---|---|---|
| No business owner | Nobody will adopt or maintain it | Assign ownership before scoping |
| No measurable baseline | ROI cannot be proven | Sample recent cases and establish current state |
| Low volume and low risk | Not enough leverage | Batch with related workflows or deprioritize |
| High risk with no review point | Bad first pilot | Redesign as suggestion-only or choose another workflow |
| Process changes weekly | Automation will chase chaos | Stabilize the process first |
| Data lives in inaccessible systems | Integration work may dominate value | Confirm access and export options before scoring |
| Users do not want it | Adoption risk is higher than build risk | Interview users and identify the actual pain |
This is where operations leaders need taste. The flashiest automation idea is often not the best first pilot. The best first pilot is usually a boring workflow everyone hates and nobody will miss doing manually.
Backlog fields for a real automation pipeline
Once the intake form is live, store candidates in a backlog with these fields:
| Backlog field | Type | Notes |
|---|---|---|
| Status | Select | New, needs info, scored, shortlisted, scoped, in build, live, rejected |
| Department | Select | Ops, finance, legal, HR, marketing, sales, customer success |
| Workflow owner | Person | Business accountable owner |
| Technical owner | Person | Integration/security owner |
| Value score | Number | 1 to 5 |
| Feasibility score | Number | 1 to 5 |
| Risk score | Number | 1 to 5, where 5 means easy to control |
| Adoption score | Number | 1 to 5 |
| Weighted score | Formula | Use scoring model above |
| Lead magnet tag | Select | Template, scorecard, ROI calculator, checklist, case study |
| CTA path | Select | Worksheet download, audit, 15-minute consultation, OpenClaw deployment discussion |
| Backlink asset angle | Text | Template, calculator, checklist, matrix, benchmark, teardown |
| Outreach notes | Text | Who might link to this asset and why |
Those last four fields are not just marketing garnish. If the pilot intake template becomes a public resource, it can also support backlinks from operator communities, automation roundups, AI adoption guides, and workflow improvement newsletters.
Lead magnet angle: turn the template into a downloadable asset
This article should point to a downloadable “Automation Pilot Intake Template” with three tabs:
- Intake form: the fields and questions above.
- Scoring sheet: weighted score, priority tier, and go/no-go decision.
- Pilot brief: one-page implementation brief for shortlisted workflows.
The form should ask for work email, company size, department, and primary workflow pain. The follow-up nurture should offer a 15-minute consult for teams with high-volume, high-value candidates.
Suggested conversion events:
lead_magnet_viewedlead_magnet_submittedblog_cta_clickedconsultation_clicked
Capture the post slug, CTA type, offer name, page URL, and source/medium.
Red Brick Labs POV
Do not start with the workflow that feels most “AI.” Start with the workflow that has the cleanest path to production value.
For most operations teams, that means a workflow with:
- Clear volume.
- Accessible data.
- Painful manual review.
- Low-risk human approval.
- A measurable before-and-after number.
- A business owner who wants the fix badly enough to change the process.
Red Brick Labs would use this intake to build a ranked pilot backlog, choose one workflow, design the human-in-the-loop path, and ship the first production version in weeks. Then we would use the results to decide what to automate next.
Sources and implementation notes
The template above is Red Brick Labs' operational version, but it lines up with common planning guidance from workflow automation and AI risk resources:
- Microsoft Power Automate planning guidance emphasizes starting from manual and repetitive processes before automating.
- Zapier's workflow automation overview is useful for basic automation language and trigger/action framing.
- NIST AI Risk Management Framework is useful background for risk, review, measurement, and governance language when AI is involved.
- Business process mapping techniques can help teams document the current workflow before intake scoring.
- Best tools for process mapping can help teams choose a mapping tool if the process is too fuzzy to automate yet.
Want help choosing the first pilot?
If your team has 10 automation ideas and no clean way to pick the first one, Red Brick Labs can help you turn this intake into a scored pipeline, validate the ROI, and ship the first production pilot.
Book a 15-minute automation pilot consult.
Build your first automation pilot pipeline: Red Brick Labs can help your team turn this intake template into a scored automation pipeline, select the first high-ROI pilot, and ship it into production in weeks.
FAQ
Who should complete an automation pilot intake form?
The business owner should complete it with the people doing the work and a technical owner who understands system access, data quality, and security constraints.
How many automation ideas should operations teams score at once?
Score 10 to 20 candidates, then shortlist the top 3 for deeper scoping. More than that usually creates ranking theatre instead of implementation momentum.
What makes a good first automation pilot?
A good first pilot has frequent work, measurable pain, accessible data, clear ownership, low operational risk, and a human review point before anything irreversible happens.