The Trigger You Set Once: Automation That Runs the Job
Most practice automation fails because it's built on reminders, not triggers. Here's how to design workflows that move work forward without anyone remembering to push it.
Ask most firm owners what they've automated and you'll hear a version of the same list: a reminder email that goes out on the 20th, a recurring calendar invite, a spreadsheet macro someone built in 2019 that nobody dares touch. These aren't automations. They're prompts to a human, who then does the actual work manually. The moment that human is busy, sick, or on leave, the whole thing stalls.
Real automation in an accounting practice isn't about being reminded to do something. It's about work moving forward on its own when a condition is met — a trigger fires, and the next step happens without anyone deciding to make it happen. The difference sounds subtle. In practice it's the difference between a system that runs the job and a system that nags you about it.
Reminders vs. triggers
A reminder assumes a person is the engine. "Chase the client for their BAS records" appears on someone's list, and if that someone has a full day, the chase slips to tomorrow. A trigger assumes the state of the work is the engine. When the job hits the status "awaiting records" and stays there for three days, the follow-up sends itself.
The mental shift is this: stop asking "who needs to remember to do X?" and start asking "what condition should cause X to happen?" Every recurring frustration in a practice — the unbilled job, the client who never got onboarded properly, the return that sat in review for two weeks — is a missing trigger. Something changed state, and nothing responded to that change.
Good client accounting software lets you attach behaviour to state changes rather than to dates on a calendar. That's where automation stops being a novelty and starts being infrastructure.
The triggers worth building first
You don't need forty automations. You need the handful that cover the moments where work reliably goes to die. Here are the ones that pay for themselves fastest.
New client created → onboarding runway starts
The instant a contact becomes a client, a chain should fire: the engagement letter drafts, the portal invite goes out, the standard onboarding checklist appears on the board, and the document request lands in the client's inbox. Nobody types a welcome email or manually assigns tasks. The trigger is "client status = active," and the runway builds itself.
Records received → job moves to the next stage
When the last outstanding document lands in the portal, the job shouldn't wait for someone to notice. It should move from "awaiting records" to "ready to prepare" and land in the right person's queue. The document arriving is the trigger. Left to humans, this is the handoff delay that quietly adds days to every job.
Work marked complete → invoice generated
The single most expensive gap in most firms is the one between finishing work and billing for it. If completing a job triggers a draft invoice — priced from the engagement, with WIP attached for reference — you never again finish something in March and bill it in June. The trigger is the status change, not month-end.
Deadline approaching → owner alerted, client nudged
A BAS or lodgment obligation that's drifting toward its due date with no movement should raise its hand. Not a blanket reminder to the whole team, but a specific alert to the person who owns that deadline, plus an automated nudge to the client if the hold-up is on their side.
Where AI changes what a trigger can do
Traditional automation is rules-based: if this exact thing, then that exact thing. That works beautifully for structured events like status changes and dates. It falls down on messy, unstructured input — and a practice runs on messy, unstructured input.
This is where built-in AI extends what your triggers can respond to. A client email arrives. A rule can't read it. But AI can classify it — is this a records submission, a new query, a complaint, a scope-creep request? — and route it accordingly, drafting a reply or creating a work item on the relevant board. The trigger is no longer "a specific button was pressed." It's "a message arrived and here's what it's actually about."
The important boundary: AI handles the reading, sorting, and drafting. It proposes; a person disposes. You don't want an AI silently reclassifying a job or sending an unreviewed response to a client on a sensitive matter. The value is in removing the triage and the blank-page problem, not in removing your judgement. In Finye, AI works as a layer over your workflow — it reads inbound messages, drafts replies, and suggests where work should go, while the actual send or status change stays with your team.
Designing automations you can trust
The reason firms are wary of automation is that a bad one is worse than none. An invoice that sends itself to the wrong client, or a reminder that fires on a job already done, erodes trust fast. A few principles keep automation on your side.
- Automate the move, review the message. Let the system change statuses and generate drafts freely, but keep a human check on anything that reaches a client until you trust the pattern.
- Make triggers specific. "Job idle for 5 days in review" is a good trigger. "Remind me weekly" is not — it fires whether or not there's anything to do.
- Give every automation an owner. If a follow-up sends itself, someone should still be accountable for the outcome. Automation moves the work; it doesn't move the responsibility.
- Start with one job type. Build the full trigger chain for your most repeated compliance job first. Get it running end to end, then clone the pattern.
The compounding return
The point of building automation this way isn't to shave a few minutes off tasks. It's that work stops depending on anyone remembering. Your capacity stops being capped by how many things your team can hold in their heads at once. A job that moves the moment its condition is met never sits in limbo, never waits for a Monday review, never gets forgotten because the person who owned it was on leave.
That's the real promise of automation and AI in a practice: not fewer staff, but the same staff running far more work without dropping any of it. You set the trigger once. The job runs itself from there.