Automation is often thought of as a process that requires systems to "talk" to each other. While this can facilitate automation, it is by no means a requirement. But before focussing on the technological problem, a good first step is to consider whether automation makes sense.
Automation works best for processes that are repetitive, time consuming, or open to human error. Usually, these are tasks that take place on a regular schedule or that are triggered by a prescribed action (such as a form submission or incoming email). Or they can be multi-step tasks that must occur in a particular sequence.
Because automated routines cannot accommodate unexpected variation, implementation usually requires some form of process improvement. Process improvements can have a standardizing influence and may include small things such as optimizing the order in which steps occur, harmonizing practices between staff, and occasionally removing extraneous steps altogether.
A typical automation project starts with a process map that outlines the flow of information between systems. These maps can be illuminating: sometimes they reveal inconsistent practices and they can help with identifying weak areas where processes can breakdown. The process map will become a blueprint for the automation, so we use this opportunity to pinpoint potential process improvements. Since change works best when others are included, this is also a great time to involve staff.
Once the process map has been refined, we begin to assemble the technological requirements. Where systems do not exchange information natively, we make use of intermediary technologies that do the translating between two or more systems. Increasingly, many of these tools are packaged with productivity suites that you may already use (e.g. Microsoft 365 or Google Workspace). We have also built our own tool, called Baton, which allows us to interface with systems that do not have built-in connectors or APIs.
Automations we have previously built include: