What process automation is, without the slides
If you search Google for “process automation” you get software makers for large corporations talking about robots, platforms and transformation. All of it exists, and almost none of it is any use to you if you have thirty people on the payroll and an ERP you bought eight years ago.
The useful version is this: automating a process means getting a task that today a person does by always following the same steps to do itself, or nearly, so that the person only has to check the result. An email comes in with a request, someone reads it, notes the details on a spreadsheet, prepares a quote from the template, sends it and writes down the follow-up date. Five steps, four of which can happen without anyone touching them. The fifth, deciding whether that quote goes out as it stands, stays in the person's hands.
That's what we do at Digency as an artificial intelligence agency, and the artificial intelligence is only one part of it. On to what matters: how you choose where to start.
The rule for choosing the first process
Three conditions, and all three at once:
- It repeats. Every day or every week, in the same shape. A process that happens twice a year isn't worth automating however tedious it is.
- It leaves a trail. It starts with something detectable (an email, a form, a new row on a spreadsheet, a review) and ends with something you can check (a document, a record, an alert). If the process lives in somebody's head, the first job is getting it out of there.
- It's boring. Nobody in the company enjoys doing it. It's the best sign that it can be systematised and, on top of that, the thing that makes the team welcome it instead of resenting it.
Our view, after a fair few diagnoses: the best first process is almost never the one management has in mind. It's usually one that a specific person does on a Tuesday afternoon and nobody else sees. That's why the diagnosis is done sitting down with whoever does the work, not with whoever runs it.
Step by step: the quote request
It's the process we get asked for most and it shows how the thinking goes. Starting point: quote requests come in through the website form and by email, someone in admin reads them, copies them into a template, sends them to management to put the price on them and then sends them out.
This is how it ends up automated:
- Intake. The form and the mailbox are connected to the workflow. Every new request is read the moment it arrives.
- Reading and sorting. This is where artificial intelligence comes in: it pulls out who is writing, what they want, for when and from which company, even if the email was dashed off in a hurry. And it decides whether it's a job that fits, a request to pass on or junk mail.
- Draft. With those details it fills in the quote template with the usual line items for that kind of work, and checks whether the client already exists in the CRM.
- Review. The draft sits in a tray. A person opens it, adjusts whatever needs adjusting and approves it. Nothing goes out without this step.
- Sending and logging. It goes out, it's noted in the CRM with its follow-up date and, if there's no reply after ten days, whoever is handling it gets a reminder.
What changes for the company: the person in admin goes from transcribing to reviewing, management sees the quotes in order and none of them ends up without a follow-up. What doesn't change: who decides the price and who signs.
Where AI belongs and where ordinary rules are enough
A common mistake is using artificial intelligence for everything, because it looks modern. A good workflow mixes two things:
- Rules for what is a rule: if the amount goes above a certain figure, alert management; if the delivery date is less than a week away, flag it as urgent; if the email comes from a blacklisted domain, discard it. Rules are cheap, fast and they don't get it wrong.
- AI for what a rule can't do: understanding an email written by a person, summarising a review, drafting in the brand's tone, classifying a scanned invoice.
With workflow tools such as n8n the two get chained together without programming from scratch, and the language models are only called in the step that needs them. It's cheaper to maintain and, above all, easier to understand for whoever is going to supervise it.
What not to automate (yet)
Some processes are tempting to automate and are better left for later:
- The ones that change every week. If the team is still deciding how something gets done, automating it sets a provisional version in stone.
- The ones where a mistake is expensive. Sending an offer with a badly calculated price, answering a delicate complaint, touching the invoicing. You automate the preparation, never the decision.
- The ones that depend on a person who isn't in the meeting. If the process lives in the head of someone in the warehouse, you talk to that person first. Without them, the workflow automates a mistaken idea of the process.
- The website chatbot. It's usually the first thing asked for and the last thing worth building. A chat that answers questions is useful when there are a lot of repeated questions and an orderly knowledge base, which almost always starts with the frequently asked questions on the service pages of the website. Before that, the boring internal processes save more time and don't face the customer.
A person in charge: designing with approval
Every workflow we build has three things: a point where a person approves before anything leaves the company, a record of every step the workflow has taken and a clear limit on what it can do. At the start, the approval is on everything. Over time, once the workflow has gone weeks without failing on one type of case, that case can be let through on its own. But the company makes that decision with data, not the agency by default.
This has a practical consequence: the team has to be able to see what the workflow has done and stop it. A simple panel with what came in, what went out and what is waiting for review. Without that, the automation becomes a black box, and a black box in a mid-sized company gets switched off at the first doubt.
How to measure whether it paid off
Two numbers before the pilot and the same two after: how long the process took done by hand, start to finish, and how many errors slipped through (quotes never sent, forgotten follow-ups, badly copied details). During the pilot the review gets timed and the corrections counted. If the time drops and the errors don't rise, it pays off. If the person takes nearly as long to review it as to do it, the workflow is badly thought out and gets rethought before rollout.
Don't trust the first week's estimates, good or bad: the figures settle once the workflow has seen enough cases.
Where to start tomorrow
With no agency and no tools: ask everyone on the team to note down for a week which tasks they do more than once and find boring. Put the lists together. Pick the one that repeats, leaves a trail and nobody wants to do. Write its steps on one sheet, one per line. You now have the design of your first automation, and half the work of a diagnosis.
If you want us to do it with you, we start with that same meeting. And if the process weighing on you most has to do with Google reviews, start by reading how the profile gets worked on in the article about local SEO: part of the problem may not be an automation problem at all.
