Most teams know they lose time to routine work. Very few can say how much, or which routines are worth fixing first. This guide gives you a method you can run in an afternoon with nothing more than a shared document and a few teammates.
We call it the busywork audit. It is not specific to Orbira. You can run it and do the automation with whatever tools you like. We wrote it because every conversation we have with teams starts in the same place: “we know we should automate things, but where do we begin?”
Why start with an audit
Automation projects fail in two ways. Some automate something nobody cared about, so the effort never pays back. Others try to automate something that was never well defined, so the result is brittle and people stop trusting it.
An audit avoids both. It makes you write down the work as it really happens, and it ranks that work by a simple measure of payoff and risk before you touch any tool.
Step 1: Collect the candidates
Ask each person on the team to list every task they did more than once in the last month that felt mechanical. Give them ten minutes. Prompt with these questions:
- What did you copy from one place to another?
- What did you write that looked almost the same as something you wrote before?
- What did you check, sort or label by hand?
- What did you chase someone about?
- What report did you build from the same sources as last time?
Do not filter at this stage. A messy list of thirty items is better than a tidy list of five.
Step 2: Describe each one in one sentence
Take each item and rewrite it as a single sentence in the form: when X happens, do Y with Z, and deliver it to W. For example:
- When a support email arrives, decide if it is about billing, a bug or a feature request, and put it in the matching queue.
- Every Friday, summarise the tasks closed this week and post the summary to the team channel.
- After each customer call, turn the notes into action items and create tasks for them.
If you cannot write the sentence, the task is not yet well defined. Put it aside. That is useful information too: it means the work depends on judgement that has not been written down.
Step 3: Score each task
Give every task three scores from 1 to 5.
Frequency. How often does it happen? A daily task scores 5, a monthly task scores 2.
Effort. How long does one occurrence take? Ten seconds scores 1, an hour scores 5.
Stakes. What happens if it goes wrong? A typo in an internal summary scores 1. A wrong message to a customer scores 5.
The payoff is frequency multiplied by effort. The risk is the stakes score. A high-payoff, low-risk task is your first candidate. A high-payoff, high-risk task is a candidate with an approval step. A low-payoff task is probably not worth the trouble, however annoying it feels.
Step 4: Check the inputs and the outputs
For each shortlisted task, answer three practical questions.
- Where does the information come from, and can it be read automatically?
- Where does the result go, and can it be written automatically?
- Who decides whether the result is right, and how will they see it?
The third question matters most. If nobody will look at the result, it will quietly drift. If the right person can review it in under a minute, the automation will last.
Step 5: Choose the first three
Pick no more than three. Choose one that is quick and safe, so you get a win. Choose one that saves the most time. Choose one that involves approval, so you learn how your team feels about handing over decisions.
Resist the urge to start with the most impressive task. The first workflow teaches you how to describe, review and trust automation. Pick something where being wrong is cheap.
Step 6: Define what done looks like
For each of the three, write down the expected result, who approves it, and how you will know it is working. A good definition is concrete: “the Friday summary appears in the team channel by 16:00, and the owner reads it before it posts.”
Also decide when you will review. We suggest looking at the first five runs of any new workflow closely, then once a month after that.
A worked example
Imagine a four-person product team. Their list contains eleven items. After scoring, three stand out:
- Weekly status summary: frequency 4, effort 4, stakes 2.
- Triage of the shared feedback inbox: frequency 5, effort 3, stakes 3.
- Copying action items from meeting notes into tasks: frequency 4, effort 2, stakes 2.
The status summary has the best payoff and low stakes, so it goes first. The inbox triage has a higher stakes score because a mislabelled message might be missed, so the team decides labels can be applied automatically but replies need approval. The meeting follow-up goes third because it depends on notes being written in a consistent shape.
This is an illustration of the method, not a measured result from a real team.
What not to automate
Some work should stay with people. Be cautious about tasks that involve sensitive conversations, one-off judgement calls, or anything where the person on the other end expects a human. Automation can prepare the groundwork for these tasks, for example by gathering context, but the decision and the words should be yours.
Common mistakes
- Automating a broken process. If the manual version is confusing, the automated version will be too. Fix the process first.
- Skipping the review step. Even simple workflows drift as tools change.
- Giving broad access. Grant the narrowest permission that works, and widen it only with a reason.
- Measuring nothing. Keep a simple count of how many times each workflow ran and how often you had to correct it.
Your next step
Block thirty minutes this week. Run steps 1 and 2 with your team. You will end up with a list that is useful whether or not you ever use Orbira. If you would like to try Orbira on the first workflow you pick, join the waitlist.
