The problem is almost never the software
When hours go missing in the office, the first thought is that the program is the wrong one. Often the business software does its job perfectly well. The trouble is everything around it, the data someone has to fetch from somewhere else and type back in by hand
Replacing the software, in that case, solves nothing. It moves the manual work onto new screens, and meanwhile you pay for the data migration, for training your people, and for several months of working worse than before
What automating without changing programs means
The idea is simple. A piece of software does the mechanical steps in place of the person, using your business software exactly the way she would: it opens the screen, looks up the code, types into the fields, saves
Your program doesn't need connections, integrations or special modules. It's enough that the job can be done with a mouse and a keyboard, looking at the screen
In practice the software stays the one you know, the passwords stay yours, your internal procedures stay the same. All that changes is who does the dull steps
What kind of work automates well
I use a single rule to tell. What automates well is what is written down somewhere and follows a rule that never changes
Copying data from an Excel file, a PDF or an email into the business software is the typical case, because the data already exists and only has to be moved. The same goes for checking that codes, dates and amounts match across two systems, or for downloading documents from a portal and attaching them to the right file
Bulk updates work well too. Customer records, price lists, case statuses, all the things someone does one line at a time today
What kind of work is better left to people
Anything that calls for a decision, an interpretation or a phone call is not worth automating. It isn't a technical limit. It's that a person does that work better
Then there are the exceptions. The unreadable document, the supplier who writes amounts his own way, the code that isn't in your records. The software must not try to guess. It has to stop and ask
Where it should stop is the part to settle calmly, before a single line of code gets written
How to do the sums yourself before you call anyone
Take the process you have in mind and count the people working on it, the hours it takes them in a day, the days a month it comes up, and the hourly cost to the company. That last one is what an hour of that person really costs you, contributions included, not their take-home pay
Say, only to show you the sum, two people, two hours a day each, twenty days a month, at twenty-five euros an hour. That's eighty hours a month, so two thousand euros a month and twenty-four thousand a year. The numbers are made up for the example, yours will be different
Now take out the part that stays manual anyway, because nothing ever gets automated a hundred per cent. Stay cautious and reckon on two thirds of it going away. Those two thirds are the real figure to compare with the monthly fee for the automation
If the two figures look alike, let it go. If the manual work costs several times as much, then let's talk. And there's a part that never enters the sum but weighs all the same, the errors to fix afterwards, the month-end backlog, and good people kept busy making digital photocopies
What we need to tell whether your case works
Numbers can be argued about in the abstract, a process can't. To say whether something can be automated we have to see which programs come into play, how many steps the procedure has, and how many times a month you do it