Find the ordinary path
Write down what happens from arrival through review to completion. Use one representative case, not a department-wide ambition.
Free planning tool · any industry
Map one workflow before choosing automation.
Turn a repeated process into a clear brief: where it starts, what information it needs, where people decide, and how a small trial would be checked. Use it for an internal conversation or a project discussion.
Start the worksheetThe method
Follow the work from trigger to handoff.
First choose one frequent, narrow process. Record the real starting event and the rough number of cases. List the information needed and which record the team trusts. Mark each person who can access or change it, then name the final handoff.
Make the hard cases visible
List missing inputs, duplicates, safety or financial concerns, and unavailable systems. State who makes consequential decisions and what they check.
Test one small step
Use fictional or de-identified samples. Compare the proposed step with the source record, note corrections, set a success check, and decide when to stop or return to the manual path.
See a fictional property-management example
Routine repair intake: A fictional resident reports a dripping tap. A coordinator receives roughly 20 routine requests per week. The approved property record is the source of truth for unit and contact preference; the message supplies the symptom.
People and exceptions: Only assigned staff can see resident details. Missing unit information goes back for clarification; a suspected urgent leak goes to a human-led safety route. A coordinator checks urgency, approves any work order, and owns the contractor handoff.
Small trial: Use ten fictional requests to see whether a draft intake card carries the original report, flags missing fields, and routes urgent wording for review. Stop if an urgent case is treated as routine or a card misstates the source. Staff continue the existing manual path when the trial stops.
This example is invented for teaching. It is not a client case, deployed system or performance claim.
Decide what to test
A repeated task is a starting signal, not a verdict.
Before choosing software, ask whether the team can identify the correct input, check the proposed output and recover when it is wrong. The same process may contain one suitable administrative step and several decisions that must stay with people.
A useful first candidate
Look for a narrow step with a recognizable trigger, a trustworthy source record and an owner who can review the result. Preparing a draft intake card or checking whether required fields are present is easier to inspect than replacing an entire handoff.
Map it manually first
If requests arrive through several channels, fields are inconsistent or no one knows which status is authoritative, document the ordinary path and exceptions before proposing a connection. A shared checklist may reveal the real problem without any new software.
Keep a human-led path
Urgency, safety, financial or legal consequences, access to personal data and customer-facing promises need explicit rules and an accountable reviewer. If the team cannot define who may decide or stop the work, pause the automation idea at that point.
Use the finished brief
Make a small trial falsifiable.
A useful test names both what should work and what would make the team stop. Keep the existing manual route available while the proposed step is being checked.
- Choose one step. For example, prepare a draft from an approved sample record; do not automate final approval or sending.
- Include normal and exception cases. Try missing information, duplicates, unclear urgency and an unavailable source so the team sees how the process fails.
- Compare against the original. Have the owner check each output against its source, record corrections and confirm who receives the next handoff.
- Set a stop condition. Pause if the draft changes a key fact, exposes information to the wrong role or treats an urgent case as routine. Return to the manual path and investigate before continuing.
Private worksheet
Describe one real process.
Use process descriptions rather than names, customer records, passwords or confidential files. Each answer should be specific enough that a colleague could check it. No data is sent from this worksheet.
Your private trial brief
One workflow to review
This is a planning aid, not an automation readiness verdict. Compare it with the real process and confirm permissions before a trial.
Suggested next step
Review this brief with the process owner. Confirm the source record and access rules, choose fictional or de-identified test cases, and agree on who can stop the trial. If a custom build is useful, share only a short, non-sensitive outline through the project form.
Discuss a project separatelyThe worksheet answers are not copied into that form.
Questions before you start
Use the worksheet with clear limits.
These answers help you decide what belongs in the brief and what should be checked with your team.
Is every repetitive task a good automation candidate?
No. Repetition is a reason to investigate, not a readiness verdict. A useful first trial has a clear trigger, information the team can verify, a named owner and a step that can be reviewed or reversed. If those are unclear, map the manual process first.
Should I enter customer or employee records here?
No. Use roles, process descriptions and fictional or de-identified examples. The worksheet does not send or save answers to a server, but the text remains visible in your tab and in anything you choose to print or save.
What if our current system has no API or export?
Do not assume an integration is available. Check the system and your access permissions. A first trial may use an approved manual handoff or a staff-reviewed copy of non-sensitive sample information; direct system access can be considered later if it is feasible and authorized.
Does the brief calculate savings or say we are ready to automate?
No. It organizes questions and proposes a bounded test. Actual benefit, error rate and operating cost would need evidence from your own process and a reviewed trial; the page does not estimate them.
Can I use this outside property management?
Yes. The property example is fictional. Use the same trigger-to-handoff questions for accounting, field service or another industry, then adapt the access rules, qualified review and stop conditions to that work.
What should happen after the brief is complete?
Review it with the process owner. Confirm the source record, permissions and current manual fallback. Select a few fictional or de-identified normal and exception cases, agree on who checks the result, and stop the trial if a defined risk appears. A custom project request is optional and separate.
Custom work, if needed
Use the brief to ask better questions.
Let's Create AI scopes custom agents, tools and automations around the actual workflow. Client-hosted or assisted deployment can be discussed. Any external model, API or subscription costs are paid separately by the client.