In the first weeks of March 2020, many businesses in Turkey found themselves rewriting their operational plans within days. Production facilities cut shifts, accounting teams shifted to working from home, and logistics crews could no longer reach the field. One question emerged with unusual clarity: which of my processes will keep running even if my team cannot get to the office? This is not simply a question about efficiency. It is a question about resilience. And the quality of the answers companies give right now will largely determine how quickly they recover in the weeks ahead.
Robotic Process Automation, widely known as RPA, has been gaining ground among larger Turkish companies over the past few years. Banks, insurance firms, and telecommunications operators have used it to automate repetitive tasks such as data entry, reconciliation, and reporting. But the lens through which RPA is now being evaluated has shifted. The question is no longer ‘will RPA make us more efficient?’ It has become ‘to what degree can RPA free our critical processes from dependence on human presence?’ These two questions may look similar, but they lead to very different places.
RPA bots operate in two fundamentally different modes: attended and unattended. Attended bots run on an employee’s desktop and require that employee to trigger them; if the employee is absent, the bot does nothing. Unattended bots run server-side, on a defined schedule or in response to a system trigger, without any human initiation. From a business continuity standpoint, only the second model is genuinely meaningful. A finance bot that completes e-invoice reconciliation at midnight means the invoicing flow continues even if no one arrives at the office the next morning. Without clearly distinguishing between these two modes before making an RPA investment, companies discover in a crisis that their automation provides far less protection than they assumed.
Most business continuity plans in mid-sized Turkish manufacturing and retail companies are built around IT infrastructure and data backup. The process layer, however, remains deeply human-dependent: issuing invoices, reconciling bank statements, updating stock records, notifying suppliers. Each of these steps requires a specific person, sitting at a specific machine, following a specific sequence in a specific application. If that person is at home, the VPN connection is unstable, or access to the corporate system is restricted, the process stops. Unattended RPA strengthens the most fragile link in this chain by executing the process according to predefined rules without requiring human involvement. The critical boundary, though, is this: RPA operates reliably only on processes that are rule-based, repetitive, and well-defined. Exception handling, judgment calls, and steps that require contextual interpretation still need human oversight.
Which processes can realistically be brought under RPA-backed continuity coverage? A practical test: if a process is performed by an experienced employee using the same steps every time, with the same logic applied on every run, a bot can perform it too. In Turkish companies, common processes that meet this criterion include e-invoice and e-archive invoice processing, data submission to the Revenue Administration portal, bank statement reconciliation, order entry, and stock updates. In logistics firms, operational steps such as driver assignment notifications may also qualify. One requirement must be stated plainly, however: for a process to be automated, it must first exist as a written procedure. Processes that live only in an employee’s memory cannot be botted. They must be made visible before they can be made resilient.
The contribution RPA makes to business continuity is real, but ignoring its limits creates serious operational risk. The first issue is bot maintenance: when a source system’s interface changes, the bot breaks and requires intervention. If the team is remote, a delayed fix can halt the process entirely, which means bot management itself must be remotely accessible and properly documented. The second issue is exception handling: what does the bot do when it encounters unexpected data? Most RPA platforms route exceptions to a queue and wait for human approval. If the human is unreachable, the queue grows. That backlog becomes an additional burden during recovery. The third issue is cost. In Turkey, where dollar-denominated software licences carry significant weight under currency pressure, RPA licensing is a real budget consideration for smaller companies. Positioning RPA as a continuity tool therefore demands not just technical planning but financial and operational planning as well.
As you review your business continuity plan, make this question concrete: if half my team loses system access for two weeks, which processes stop, and what does that stoppage cost the business? The answer identifies which processes should be prioritised for automation. RPA is not a universal answer for all of them, but for high-volume, rule-based, repetitive operations it provides a reliable resilience layer. Installing the technology is not enough. Cleaning the data that feeds the bot, documenting exception scenarios, and ensuring that bot management is possible from outside the office must all be part of the plan. Resilience is not measured by how quickly you adapt when a crisis hits. It is measured by how prepared you were before it arrived.
This article was originally written in Turkish by Gökhan MERCANOĞLU on March 23, 2020 and has been automatically translated into English and other languages using machine translation.