Back-Office Automation: The Trinary Method for Getting from Idea to Result

Intro

Friday, 3 p.m. Your controller is retyping supplier invoices from email into the accounting system by hand. Six hours a week. Everyone knows it should be automated — someone even said so out loud in a management meeting eight months ago.

The retyping is still there.

This isn't a technology problem. The tools exist and they work. Nobody has a clear mandate to turn the idea into a project, nobody knows where to start, and nobody wants to be the person who spent the budget on a system the team won't use. Here's the approach we follow at Trinary to avoid that: what happens at each step, what you receive, and where it stops if you decide not to go further.

What actually blocks automation in small and mid-sized businesses

When an automation project fails, it's rarely because the tool was wrong. The causes we run into most often:

• Automating a process nobody ever documented. Without knowing how the task really gets done, exceptions included, you automate an idealized version that matches nothing.
• Buying the tool before understanding the need. The licence is signed in January, the real problem surfaces in March.
• Going too big at once. A twelve-month project spanning four departments has time to lose its sponsor and its momentum before producing anything.
• Forgetting someone has to live with it. Training lasts an hour, then it's back to Excel at the first unplanned exception.
• Measuring nothing. Without a starting number, you can't demonstrate a gain. The project becomes a line item nobody renews.

The approach below defuses those five traps, one at a time.

Starting point: a free 30 to 60 minute conversation

Before we talk about a mandate, we talk. This first meeting is free, virtual, and it isn't there to sell you anything. We cover four things:

• Who you are: your market, your size, how the organization actually runs day to day.
• What you already have in mind. Most executives arrive with an instinct, sometimes a project underway. We start there.
• Your current tools: ERP, accounting system, CRM, spreadsheets, industry software. What's in place determines a good part of what's feasible.
• Whether there's a fit. Sometimes the answer is no, or not now. That's a useful answer, and it costs nobody anything.

If it makes sense to continue, we propose one of the three formats below.

Step 1 — The diagnostic: measure before proposing anything

Nothing gets designed until we know what's actually happening. The diagnostic is an observation exercise, not a sales exercise. We sit down with the people doing the work — not just their managers — and look at the processes eating time: invoices, quotes, purchase orders, client data entry, recurring reports, time tracking.

The analysis draws on four sources:

• Interviews with the key people in the process, at every level: administration, operations, technical staff, leadership.
• Observation of the tools actually in use, including the side spreadsheets nobody mentions in meetings.
• Document review of templates, forms and procedures.
• Technical validation. Before recommending an integration, we verify the API exists, is documented, and returns what's needed. A recommendation that hasn't been technically validated isn't a recommendation.

The logic follows DMAIC (define, measure, analyze, improve, control): we measure before proposing, and we define how results will be tracked afterward. For each process, we document four things:

1. Volume: how many times per week, per month.
2. Actual time, reconstructed from the systems and the people involved — not estimated in a meeting.
3. Error rate and cost of rework: a mis-keyed invoice — what does it cost to fix downstream?
4. Exceptions: the cases that don't follow the rule and derail most automations.

We add a technology read — what your tools already do, what's missing — and a skills read.

From the analytical format onward, this inventory becomes a map of the current process: a swimlane diagram showing every step, its owner, its duration, the systems and external parties it passes through, and where the file sits waiting. Friction points are catalogued one by one and classified by impact and automation potential. That's a portrait of what exists, not a proposal — the proposal comes in step 2, within the same mandate.

Three formats, depending on the depth required

These formats are reference points, not a closed menu: if your situation falls between two of them, we build a custom mandate from the same components. Durations vary with complexity and availability — yours, ours, your partners'.

The deliverable isn't only a document: the report comes with the process maps as PDFs, readable and printable without any particular tool. From the analytical diagnostic up, we come and present the findings to your leadership and your teams.

One important point: steps 1 and 2 make up the diagnostic itself. With a DIAG-1 or a DIAG-2, the mandate ends when the report is delivered and presented. You then choose what to do with it — with us, with your internal team, or with someone else. Steps 3 through 6 apply if you go through to implementation.

Step 2 — The design: mapping the optimized process

The first map describes what exists. The second describes what should exist. The distinction sounds theoretical and isn't: a process automated as-is is a bad habit made faster.

So we produce a second map, laid over the first: what disappears, what becomes automatic, what stays human, what stays manual because an external constraint requires it. The two maps side by side, with the time on each step, is the most convincing argument you can put in front of a leadership team.

The design answers specific questions:

• Which steps disappear, which stay human?
• Who approves what, and at what moment?
• When an exception comes up: does the system block, or route it to a person?
• Which data moves between which systems, in which direction?
• What are we deliberately not doing in this first version?

Two principles shape every proposal we make.

A modular architecture rather than one large system. Each module delivers value the moment it goes live, without depending on the others. You validate the approach on the first before investing in the next, you see gains within the first weeks, and you spread the investment over time. A monolithic eighteen-month project offers none of that.

Where there's AI, it proposes and a human approves. No generated content enters a deliverable without sign-off. That's a matter of professional liability, but also of adoption: teams remain the authors of their own work.

Scope is worth its weight. A well-drawn boundary is the difference between shipping in a few weeks and a project that stretches across two quarters. And a design rejected at this stage costs a few days; rejected after development, it costs a quarter.

Steps 3 and 4 — Pilot and integration: usually the same job

In theory, you build a pilot and connect it afterward. In practice the two are rarely separable: you can't validate invoice-processing automation without access to the accounting system. So we develop in connected conditions from the start, except where the mandate allows working on a historical or synthetic dataset.

What makes a pilot useful:

• A deliberately narrow scope: one document type, one team, one location.
• Running alongside the existing process, so nobody loses their safety net.
• A success criterion defined up front. "Process 90% of standard invoices without manual intervention" is a criterion. "See if it works" isn't.

What to watch during integration:

• Access rights and data security: who sees what, where data travels, what's retained. In Quebec, Law 25 sets specific obligations; that gets handled at design time, not after the fact.
• Traceability. When someone asks why an invoice was approved, you need an answer.
• Reversibility. If the system goes down, the team has to take over manually without losing data.

The pilot also surfaces what the diagnostic missed — and there's always something: the supplier who sends invoices as photos, the project code the team has been putting in the comments field since 2019. Better to find that on 5% of the volume than on 100%.

Step 5 — Measurement: the numbers that decide what comes next

We take the indicators collected during the diagnostic and compare. It's the only way to turn a hunch into a budget argument. The indicators we track most often:

• Processing time per unit (per invoice, per quote, per file), before and after.
• Share of volume handled without human intervention.
• Error rate and cost of rework.
• End-to-end lead time: how many days between receiving a document and booking it.
• Adoption rate: is the team using the system, or has it drifted back to old habits?

That last one is the most frequently forgotten. An automation that three quarters of the team works around shows excellent technical performance and zero real return.

Targets aren't invented after the fact: they're set during the diagnostic, with a starting value and a target value. And when data is missing to establish a reliable baseline, we say so in the report instead of filling the gap with an assumption dressed up as a fact. A projection built on an invented number doesn't survive its first quarter. When the solution rests on a language model, measurement also covers answer quality — continuous work, not a one-time validation.

Step 6 — Ongoing support: optional, but this is where the value compounds

Once the proof of concept is delivered, you can stop there. Most clients continue instead, and that's the approach we prefer: a POC left frozen degrades, a POC maintained becomes a production tool. Depending on the solution delivered, support can include:

• Hands-on training with the daily users, on their real files.
• Documentation of the target process and the solution, so the next employee doesn't have to guess.
• Licences, notably to cover language model consumption.
• Hosting and infrastructure management.
• Support, with a clear point of contact and an agreed response time.
• Continuous development: new features, new processes, rollout to other teams.

These are bundled into a package. It's also where the next move gets decided: once a team has seen one process work, the second automation sells itself internally.

Your checklist before launching an automation project

Worth confirming before you sign anything, with us or with anyone else:

• A baseline measurement: time, volume, error rate, in numbers rather than from memory.
• The exceptions in the target process are identified, not just the standard case.
• The scope of the first delivery fits on one page and explicitly excludes certain things.
• A written success criterion, with a number and a date.
• The people doing the task have been consulted, not just informed.
• A named internal owner, with time genuinely freed up.
• The systems to connect are listed, with their access and technical limits.
• Compliance handled at design time: Law 25, retention, access rights.
• A fallback plan if the system goes down.
• Post-delivery in the budget: training, adjustments, support, continuous development.

If you can check most of these, you're ready to start. If you can only check two or three, that's not a problem: establishing those answers is precisely part of the diagnostic.

From idea to result

Back-office automation isn't spectacular. It's a sequence of ordinary decisions made in the right order: measure, design, test small, connect, check the numbers, support the team. The difference between a company that gets there and one that's been talking about it for eight months rarely comes down to budget or technology. It comes down to method.

If you recognize your organization in that Friday 3 p.m. scene, the first step isn't picking a tool. It's putting a number on what it's costing you.