An automation that drives your business software works the way a person would. It opens a screen, looks for a field, types into it and clicks a button. If the software changes its screens, the automation finds itself looking at something it doesn't recognize. It's the biggest doubt people raise with us, and rightly so, so let me explain it properly.
Not all updates are the same
Most updates to business software don't touch anything the automation needs. They fix the way a total is worked out, they add a printout, they correct a bug nobody had noticed. In cases like these the automation carries on running and nobody notices a thing.
The changes that matter are the visible ones. A field that gets a new name, a button that moves to another tab, an extra window asking for a confirmation before saving, a new column that shifts all the others along by one. For the person doing the work these are small things: you notice, you grumble, you carry on. A program stops instead, because it's looking for something exactly where it used to be.
Why stopping is the right reaction
This part matters more than all the rest, and it holds for any automation, not only the ones I write. When a well-built system can't find the screen it expects, it has to stop and say so, not guess.
The real risk isn't the automation that stops, you see that one straight away. The risk is the one that carries on anyway and writes the taxable amount into the VAT box because the fields have shifted along by one. By the time you notice, you have a pile of entries to redo by hand. A stop is something you see and fix. A value written wrong in silence is a problem that grows on its own.
That's why a serious automation checks it is where it thinks it is before writing anything, and reads back what it wrote once it has been saved. If either of those two checks doesn't add up, it stops there and says so.
How much work it takes to put it back on its feet
It depends on what changed, but usually far less than you'd imagine. If the software renamed a field, we update that one reference and the process starts again, with the logic around it untouched. If the vendor rebuilt the whole interface, then the job is longer. That's a rare case, though, and you usually know months in advance, because a change like that gets announced.
What makes the difference is the way the automation is written. If every reference to the screens sits in one place, changing one is a matter of minutes. If instead they're scattered all over the code, each little fix turns into a treasure hunt. It's a technical detail you shouldn't have to check yourself, but if you're weighing somebody up, it's a fair question to ask.
Why the service is a subscription and not a one-off delivery
This is the honest reason Muffin Suite works on a monthly fee instead of handing you the code and waving goodbye. An automation isn't a piece of furniture you put together once and leave standing there, it leans on programs that keep moving.
If I simply delivered it and left, it would work perfectly until the first update to your software. After that it would become your problem, with code in your hands that you didn't write. With the monthly fee, small fixes of this kind are part of the plan, I make them and you don't notice a thing.
What we need from you
Very little, but not nothing. If you know your software is going to be updated, telling us before rather than after changes a lot, because we check it calmly instead of in a rush with the office at a standstill. We also need somebody who can try the process out after a change, ideally on a few made-up cases or on documents already closed, before it goes back to running on real work.
If your software has a separate test environment, say so, it's the best place to check an update without risking anything. If it doesn't have one, we work anyway, just more carefully.
The question to ask anyone, not just me
If you're thinking of having a process automated, this is the question that in my view separates careful work from rushed work: what exactly happens when the screen isn't the one expected. If the answer is that the system stops, sends an alert and leaves a log of everything it had done up to that point, you're on the right road. If the answer is vague, hold on to that doubt.
How to see whether your case holds up
To say anything sensible about your process I need to know which program you use, which steps the person doing the work goes through today, and how often it comes up. That's already enough to tell whether it makes sense, and how exposed it is to changes in your software.