Start with repeated work that has a clear trigger, reliable inputs and a responsible owner. Compare how often it happens, what the manual effort costs, and what happens when it goes wrong. Choose a manageable workflow whose result can be checked before automating a wider process.
An agency can find possible automations in almost every part of its work. That does not make every task a sensible first project. A proposal reminder, client intake or a reporting handoff each deserves its own evaluation.
The first project should let the team learn how to run and maintain a workflow responsibly. It should also address a problem that matters in the agency's actual work.
- Collect recent examplesDescribe actual recurring work and where it stalls.
- Compare candidatesCheck frequency, effort, consistency, data, and ownership.
- Keep judgment visibleIdentify decisions that remain with a person.
- Pilot and inspectChoose a bounded workflow with an observable result.
Possible automation candidates are starting points for investigation, not equal priorities.
Which recurring tasks are creating the problem?
Ask the people doing the work to describe recent examples. What starts the task? Which records do they check? What are they trying to accomplish? Where do they wait, repeat information or ask another person for status?
Keep the conversation specific. “Our onboarding is messy” is an observation worth exploring, but it is not yet a workflow definition. “The account manager retypes the approved client details into a project and asks sales to confirm the scope” gives you a handoff to examine.
Possible candidates include lead assignment, proposal follow-up, intake status, project setup and recurring reporting. This list is a starting point for investigation, not a claim that those workflows are equally valuable or supported by every platform.
What do we compare before choosing?
Use a short evaluation sheet. Describe the current work and the proposed result, then review the conditions that would make automation practical.
- Process stabilityCheck whether normal cases follow an agreed process.
- Usable inputsCheck whether required data is available and usable.
- Failure consequenceCheck what happens when work is late, incorrect, or repeated.
- Exception ownershipName who reviews exceptions and maintains the workflow.
Do not add numerical scores that imply unsupported precision.
| Criterion | Question to answer |
|---|---|
| Frequency | How often does this work occur in the agency? |
| Manual effort | Which steps require effort today, and how was that effort measured? |
| Consistency | Do normal cases follow the same agreed process? |
| Data quality | Are the required inputs available and usable? |
| Judgment | Which decisions still require a person? |
| Consequence | What happens if the action is late, incorrect or repeated? |
| Ownership | Who reviews exceptions and maintains the workflow? |
Use these criteria to compare the candidates, rather than adding numerical scores that imply more precision than the evidence supports. A workflow can be frequent and still be unsuitable if its start condition is unclear.
Which task is a manageable first pilot?
Choose a bounded process with an observable result. It might assign a new lead to an owner and make the next action visible. It might prepare a delivery workspace after a person approves an engagement. The important point is that the team can inspect what happened.
Illustrative example: an agency wants an approved client intake to notify the project owner and update a readiness checklist. The pilot leaves final kickoff approval with that owner. It does not attempt to redesign the entire client relationship in one build.
This is a hypothetical example. It is not a ScaleAxis result or a claim that any particular product implements the workflow.
Which decisions should remain with a person?
Write down decisions that depend on context. A change in project scope, conflicting client information or an unusual billing arrangement may require review even when the surrounding records are handled automatically.
- Scope changeRoute changed project scope for review.
- Conflicting informationGive a reviewer the engagement and missing condition.
- Unusual billingRoute unusual billing arrangements to an authorized owner.
- No agreed ownerResolve responsibility before building automation.
Automation can relocate unclear work without resolving responsibility.
Give the reviewer enough information to act. “Please check this client” is weaker than an item that identifies the engagement, the missing condition and the decision required.
If the process has no agreed owner, resolve that before building. Automation can move the work into another system while leaving the responsibility just as unclear.
Does the workflow need AI?
Many useful automations involve defined events and record changes. They do not require a model to generate or interpret text.
If AI has a useful job, define its input and expected output. Decide where a person reviews the result, what information may be supplied, and what should happen when the result is unusable. Treat a draft message or an interpretation as something to evaluate, not automatic permission to act.
Compare the maintenance required for the whole workflow. Adding a model can change the review and failure conditions even when it makes one step easier to demonstrate.
How do we establish a useful baseline?
Observe the current process before replacing it. Record actual examples of completion, manual work and exceptions. Note where you are estimating because no measurement exists.
Agree on the pilot's acceptance checks. For a handoff, these could include correct ownership, the expected fields arriving, missing inputs staying visible and repeated events being handled appropriately.
After the pilot, evaluate comparable work. Count the time spent reviewing exceptions and maintaining the workflow as part of the result. A shorter demonstration does not establish a reduction in the agency's total work.
What should be tested before expansion?
Test normal cases and foreseeable exceptions using sample records. Try a missing field, a duplicate event, a disconnected account and a failure after an earlier action succeeded.
- Normal sample recordVerify the expected workflow result.
- Missing fieldCheck how absent input remains visible.
- Duplicate eventCheck how repeated activity is handled.
- Disconnected accountCheck recovery after connection failure or partial success.
A non-builder should be able to identify state, owner, and recovery path.
Ask a team member other than the builder to follow the operating note. They should be able to identify the current state, find the responsible owner and understand the approved recovery path.
The automation platform guide explains how to evaluate implementation and failure handling in Make, Zapier or n8n. The onboarding guide shows how a specific handoff can be defined.
What is the next step after a pilot?
Expand when the workflow is understood, its exceptions are manageable and somebody can support it. If those conditions are missing, a narrower scope or a process change may be the useful next step.
For help evaluating candidates, review the ScaleAxis operations audit. Bring the current process and recent examples of where work gets held up. Confirm the proposed work and support arrangements before starting implementation.
Questions and answers
Should reporting or onboarding be automated first?
Either can be a candidate. Compare the agency's actual work, data quality, required judgment and exception burden. Reporting is a poor first project if its inputs are inconsistent; onboarding is a poor first project if nobody has agreed on its start conditions.
Do we need AI for the first automation?
Not necessarily. A defined trigger, record update or reminder may solve the problem without generated output. Use AI only where it has a clear job, an appropriate review process and a way to handle uncertain or incorrect results.
How do we measure whether a pilot helped?
Record the workflow's baseline and evaluate the same work after the pilot. Check completion, manual effort, exceptions and maintenance. Separate observed results from estimates and account for the work staff still need to do.
When should we stop or change the pilot?
Revisit it when inputs remain unreliable, exceptions overwhelm the owner, or the workflow creates more administration than it resolves. A smaller scope or a process change may be a better next step than adding more automation.