A busy accounting firm makes the same small decision hundreds of times a month. A job moves to Review, so someone should notify the partner. A client is onboarded, so a welcome message and a set of onboarding tasks should go out. An identity document is thirty days from expiry, so a renewal request should be sent. None of these decisions require professional judgement; they require a person to notice an event and then perform a small, entirely predictable action. In a firm running on memory and habit, exactly this category of task is the one most likely to get missed on a busy Tuesday.
The cost of a missed instance is rarely dramatic on its own. A welcome message that goes out a day late, a review task that never gets created, a thank-you note that nobody sends, none of these sink a client relationship by themselves. What they do, compounded across a year and across every client, is quietly erode the sense that a firm is genuinely on top of things, a feeling clients notice in aggregate long before they can point to a specific missed step.
Accupe's Automations engine exists to take that category of decision away from memory entirely. A firm defines a trigger, an event the platform can watch for, and an action, something the platform should do when that event fires, and from that point on the rule runs itself. This piece goes through how the rule builder actually works, a few realistic examples, and where the line sits between what automation should handle and what still needs a person.
The shape of a rule
Every automation in Accupe follows the same basic structure: a trigger, an optional condition narrowing when it fires, and one or more actions.
- Trigger: the event that starts the rule, such as a job moving to a specific Smart Board column, a new client being onboarded, an invoice being marked paid, or a document approaching its expiry date
- Condition (optional): a filter narrowing the trigger, for example only for a specific service line or client category
- Action: what happens next, such as sending an email template, creating and assigning a task, or updating a job's status
- Every rule fires automatically once saved, with no manual step required to activate it each time the trigger condition occurs
A worked example: the job that moves to Review
The reason this structure works for a non-technical partner is that it reads, in plain language, as a single sentence: when this happens, if this is true, do this. A firm can build a genuinely useful automation library without anyone on staff writing a line of code or thinking in terms of logic gates, because the rule builder is doing the translation from that plain sentence into something the platform can actually execute.
A firm sets up a rule with the trigger "job moved to the Review column." The action attached to it creates a task, assigned to the partner responsible for that client, titled "Partner review required," due within two working days, with the job's name and client already populated so nothing needs to be typed.
From the moment this rule is saved, every job that reaches Review across the entire firm generates its own review task automatically. The manager who moved the card did their part by moving it; the system handles making sure the right partner is prompted to look at it, rather than relying on the manager to remember to also send a Teams message or an email separately, which is precisely the kind of duplicate manual step that gets quietly skipped when three other jobs need attention at the same time. Add a condition narrowing the same rule to a single service line, and a firm can route audit-sensitive work to a specific reviewing partner while leaving routine bookkeeping jobs on a simpler path, without needing two entirely separate Smart Boards to keep the two kinds of review apart.
A worked example: the client who just signed up
A second rule triggers on "client onboarded." Its actions send a branded welcome message through the portal, create a standard onboarding task list, "upload photo ID," "confirm registered address," "provide last year's accounts," and flag the client for an identity verification session to be created within the week.
A junior member of staff onboarding a new client no longer needs to remember the firm's full onboarding checklist from memory or from a document they read once during training; the checklist exists as a running rule that fires the same way every time, for every new client, regardless of who onboarded them or how busy that day was. Consistency across new clients stops depending on which staff member happened to handle the onboarding, and a partner reviewing the firm's onboarding quality no longer needs to spot-check individual files to know the checklist was actually followed.
A firm running two distinct onboarding paths, a lighter one for a straightforward personal tax client and a fuller one for a new limited company with its own Companies House record and PSC declaration to capture, can maintain both as two separate rules keyed off a condition on client type, rather than expecting staff to remember which checklist applies to which kind of client on a given day.
A worked example: the invoice that gets paid
A third rule triggers on "invoice paid." Its action updates the associated job's status where relevant and sends a short automated thank-you message through the portal. This is a genuinely minor courtesy on its own, easy to skip when a firm is busy and easy to forget entirely.
Automated, it happens every time, for every client, without costing anyone a moment of attention, which is exactly the kind of small, consistent politeness that is disproportionately hard to sustain through memory alone across a large client base, and disproportionately noticeable to a client when it is missing. A firm can layer a second action onto the same trigger, for example notifying the assigned manager so they know the job is now fully closed out, fee collected and all, without having to check the Invoices tab separately.
Why triggers and actions stay deliberately narrow
The automations engine is intentionally built around a fixed set of well-defined triggers and actions rather than an open-ended scripting environment. A firm cannot write arbitrary logic that reaches outside the platform, calls an external system, or makes a judgement call the software is not equipped to make. That is a deliberate constraint. A rules engine that only fires on clearly defined events and only performs clearly defined actions is predictable and auditable; the firm can look at any given rule and know precisely what it does and does not do, rather than debugging an opaque script when something behaves unexpectedly.
This also keeps the barrier to entry low for the person actually setting rules up, who in most firms is a manager or an admin rather than a developer. A short, fixed list of triggers and actions is something a non-technical partner can read end to end and understand, which is not something that can be said of most general-purpose automation platforms once a firm starts chaining conditional logic together.
There is a broader design point behind this restraint. Practice management software sits close to regulated professional work, and a rules engine that could reach arbitrarily into external systems or fire off unreviewed actions at scale would be a genuinely different, riskier kind of feature to operate. Keeping the surface area deliberately small is not a limitation the firm has to work around; it is what makes the feature safe enough to hand to a manager rather than needing a developer on staff to configure and maintain it responsibly.
Where automation should stop
Not every recurring pattern belongs in a rule. Automations are well suited to reminders, notifications, task creation and status updates, the connective tissue of a busy practice, but they should not be used to make decisions that require professional judgement: whether to accept a new client, whether a set of accounts is ready to send for approval, or whether a fee variation is justified.
A firm building out its automation library should ask, for every rule under consideration, whether the action is purely administrative or whether it is quietly encoding a decision that a partner should actually be making. The former belongs in an automation; the latter does not, no matter how repetitive it starts to feel, because the cost of automating a judgement call incorrectly is far higher than the cost of a person spending a few extra minutes making it properly.
A useful, simple test in practice is to ask whether the firm would be genuinely comfortable with the action happening exactly the same way for every single client, every single time, without exception and without anyone double-checking it first. A welcome message and a standard task list pass that test easily; almost nothing about who gets accepted as a new client, or whether a particular set of accounts is genuinely ready to leave the building, passes it at all, because both of those decisions genuinely do vary, quite properly, from one client and one year to the next, in ways a fixed rule can never fully anticipate.
What it does not do
The engine triggers and acts; it does not think. It cannot assess whether a job genuinely belongs in Review or was moved there by mistake, and a poorly scoped rule, one triggered too broadly or attached to an action that is not actually appropriate every time, will fire exactly as configured even when the result is unhelpful, which is why rules are worth reviewing periodically rather than set once and forgotten. It also does not replace the Smart Board itself; automations respond to what happens on the board, they do not decide the firm's workflow structure in the first place.
It is also worth flagging a failure mode specific to automation rather than manual process: a rule that was correct when it was written can become wrong silently as the firm's workflow evolves around it. A firm that renames a Smart Board column, or restructures its onboarding checklist, needs to remember that any rule referencing the old structure by name will simply stop firing rather than raising an error, which is a different kind of maintenance burden to the one a purely manual process ever had, and one worth building into a firm's periodic process review rather than only its initial rule-building exercise.
What changes for the firm
Firms that build out a modest library of well-scoped automations, typically covering the genuinely repetitive parts of onboarding, review and billing, describe less reliance on any one person remembering the firm's informal processes. New joiners inherit the firm's actual practice through the rules that fire around them rather than through a slow apprenticeship of watching what more senior staff happen to do. And the firm stops losing small, consistent actions, the review task, the welcome message, the thank-you note, to whichever Tuesday happened to be too busy for anyone to remember.
The firms that get the most out of the engine tend to treat it as a living part of the practice rather than a one-off setup exercise, reviewing the rule library every few months alongside the workflow it supports, retiring rules that no longer fit and adding new ones as the firm's own process matures. A rule library nobody has looked at in a year is exactly as likely to be quietly wrong as it is to be quietly right, which is a reasonable argument for putting a specific, named person, usually whoever already owns the firm's onboarding process end to end, in charge of that periodic review rather than leaving it to nobody in particular. That small piece of ownership, one named person, one recurring calendar entry to review the list, is usually enough to keep a rule library trustworthy for years, in a way that simply hoping someone will notice a stale rule almost never is.
