A 30-day AI plan for a professional firm

Week 1: where does the time actually go?

Measure before you change anything, because the baseline is what makes week four meaningful and it takes about three hours to collect.

You are not doing a full time-and-motion study. You are cataloguing recurring administrative tasks, the ones that happen on a trigger rather than on a matter. Give everyone a shared sheet with six columns and ask them to fill it in as tasks come up over five working days.

• Task. What it is, in the words the team already uses.
• Trigger. What causes it to happen. An email arriving, a job closing, Friday afternoon.
• Who. The person who actually does it, not who owns it.
• Frequency. Times per week.
• Minutes. Realistic minutes per instance, including the interruption cost of switching to it.
• Systems. Which programs are open while they do it.

At the end of the week, work out the annualised hours yourself rather than trusting an impression:

minutes per instance × instances per week × working weeks per year ÷ 60 = hours per year

Use whatever working-week figure fits your firm. Forty-six is a common planning assumption once leave and public holidays come out, and you can adjust it. Then convert to money using your own fully-loaded cost for the person doing the task, which is their salary plus on-costs divided by their actual working hours, not their charge-out rate. If the task displaces billable work, run the same line at charge-out as well, and note that the two numbers answer different questions.

Sort the sheet by annual hours. Almost every firm finds the same shape: a handful of small tasks, repeated constantly, that nobody has ever added up. A six-minute task done twelve times a week is around fifty-five hours a year at forty-six weeks. That is your own number, not a statistic from an article, which is what makes it persuasive internally.

Two things to mark while you count. Which tasks involve client-identifying information, because that determines what tooling is eligible. And which tasks people describe with visible irritation, because that column matters more than it sounds when you reach adoption.

Week 2: which single workflow do you pick?

Pick one. Not three, not a strategy, one workflow that will be finished and running by the end of the month.

The temptation is to pick the biggest number from week one. Resist it if that task is also the most sensitive or exception-heavy. A first build has a second job beyond saving hours: it teaches the firm how this works and earns the team's willingness to do the next one.

Score your top five candidates from 1 to 5 on five criteria and add them up:

1. Frequency. Does it happen often enough that a fix compounds.
2. Rule-shaped. Could you write the decision rules on one page. If the answer is "it depends on judgement", that is a partner's job, not a workflow.
3. Blast radius. If it goes wrong, is the error visible and reversible before a client sees it. Low blast radius scores high.
4. Data sensitivity. Can this be done without client-identifying material leaving systems you control. Lower sensitivity scores high.
5. Owner. Is there one person whose day this improves, who wants it.

The winner is the highest total, not the highest hours. In most professional firms it lands on something like: an enquiry arriving and being filed with a drafted reply waiting for approval, a job closing and triggering the invoice and the follow-up schedule, or the Friday report assembling itself from inputs scattered across three systems.

Then spend ninety minutes mapping it properly with the person who does it. Write down every step in order, including the ones they do without noticing. Then write the exception list, which is the part that decides whether the build succeeds. Every "except when the client is on a retainer" and "except for the two matters we handle differently" needs to be on paper now, because these are what break a workflow in week five.

Finish week two with one page: the current process, the exceptions, what the automated version should do, what it must never do without a human, and the number you are trying to move.

Week 3: how do you build it without breaking anything?

Build in your own accounts, with a person in the loop wherever the work touches a client or money, and test against real historical inputs rather than tidy invented ones.

Four rules make the difference between a workflow that survives and one that gets switched off in March.

Everything in the firm's name. Accounts, keys, subscriptions and the workflow itself. If a contractor builds it in their account, an ordinary disagreement about scope becomes an operational outage.

A human approves anything that reaches a client, a court or a payment. Drafts wait. The workflow can do most of the job and stop, which is where the value is anyway. If the work involves confidential material, settle the data question before the build, because it determines which tools are eligible.

It fails loudly. When something breaks, the workflow stops and alerts a named person with enough detail to act, rather than guessing or retrying silently. Silent failure is the expensive kind, so a heartbeat confirming success matters as much as an alert reporting failure.

Test on real inputs. Take twenty genuine historical examples, including the messy ones, and run them through. Invented test data always passes, because you invented it to fit the design.

Then run in parallel for a few days, doing it both ways and comparing outputs. It feels wasteful and it is the cheapest insurance available, because it surfaces where the workflow and the person disagree.

Week 4: how do you know it worked?

Compare against the week-one baseline, count the exceptions, and make an explicit decision to keep, fix or stop. A workflow with no measurement is a subscription with a story attached.

Look at four things:

• Hours. Re-run the week-one arithmetic on the same task. Same method, same assumptions, so the comparison holds.
• Coverage. Of the items that should have gone through the new path, how many did. Anything under most of them is an adoption problem, not a technology one.
• Exceptions. How many items the workflow parked for a human, and whether that number is falling as the rules improve.
• Quality. Spot-check ten outputs against what a person would have produced. Completion is not correctness.

Then do the handover properly, because this is where value is most often lost. Train in the week people start using it, not before. Leave a one-page card where the work happens and a short screen recording. Name the owner. Close the old path on a stated date, because if the old spreadsheet still opens, it will be used.

Finally, write down what broke during the build and what you changed. Two paragraphs. It becomes the runbook, and it is what stops the same problem being diagnosed from scratch next year.

What does this cost in your own time?

Roughly a day of principal time spread over the month, plus a few hours across the team. Being honest about that upfront is what separates a plan that finishes from a plan that stalls in week two.

The shape is two to three hours in week one, ninety minutes mapping in week two, an hour or two of review in week three, and an hour of training in week four. Whoever builds it, the firm cannot outsource the mapping conversation or the exception list, because that knowledge only exists in your people. If you cannot find that time this month, start next month instead of half-running it.

What happens on day 31?

You either extend the workflow you built or you start the next one on the list. You do not start five.

Extending is usually the better second move. The first build teaches you where the process was messier than described, and a second pass over the same workflow, tightening the exception handling, often returns more hours than a new project would. The systems, the accounts and the team's understanding are already in place.

When you do move to the second workflow, run the same four weeks. The audit sheet from week one is still valid, so the exercise gets faster each time. A firm that finishes one workflow a quarter ends the year with something that genuinely runs the practice. A firm that starts four at once usually finishes none.

What are the common ways this goes wrong?

Six, and they are predictable enough to be avoided on purpose:

1. Buying tools first. Tool choice is the last decision. Map, then choose. Very often the capability is already inside a subscription you pay for.
2. No baseline. Without week one you will spend week four arguing about whether things improved.
3. Starting with the hardest thing. The most sensitive, most judgement-heavy task is the worst first project and the best third one.
4. Automating a broken process. If the process is wrong, automation makes it wrong faster and at scale. Fix it first.
5. No named owner. Workflows owned by everyone are maintained by no one.
6. Skipping the handover. A workflow the team does not use is more expensive than the manual process, because you paid for it twice.

What to do next

Start the audit on Monday. It is the only step that requires no decisions, no budget and no software, and it makes every subsequent decision easier.

1. Create the six-column sheet and send it to the team with one line of explanation.
2. Collect it Friday and do the arithmetic yourself.
3. Score your top five candidates and pick one.
4. Book ninety minutes with the person who does that task.
5. Decide who is building it, and confirm accounts, review steps and failure behaviour before anyone starts.

If you would rather have the mapping run for you and the first workflow built and handed over documented, that is the engagement Shift is set up for. Either way, the audit sheet is the part nobody should skip.