In this article, we will discuss how we automated the application intake in the task tracker, which processes can be automated, and how to avoid mistakes in doing so.
Application Intake Before Automation: The Problem and the Search for a Solution
One of our clients is a major private insurance company with several thousand employees. They have a large website and numerous digital products, such as insurance calculators. These are continually improved and refined based on feedback from clients and in compliance with legislative requirements and insurance market regulators.
Even though we utilize a task tracker in our work, not all tasks were logged in it. This was because some tasks were too minor, or sometimes new departments from the client's side got involved. In such situations, it was quicker and simpler to send an email.
We designated a specific mailbox and frontline support specialists who promptly responded to messages. They would handle issues independently if they could or allocate the task in the task tracker to the relevant expert. However, at one point, the volume of such tasks became overwhelming. We realized that merely scaling horizontally and increasing the number of first-line specialists was not a viable long-term solution.
We needed to modify the processes themselves so that the same number of people could handle more tasks and expend less effort. Hence, we began searching for a solution.
In our retrospectives, we surveyed the specialists handling incoming requests. We attempted to categorize and classify tasks in the task tracker based on specific criteria.
We found that many tasks were quite standard. They barely differed from one another, always followed the same process, required similar actions, and yielded roughly the same outcomes.
We designated a specific mailbox and frontline support specialists who promptly responded to messages. They would handle issues independently if they could or allocate the task in the task tracker to the relevant expert. However, at one point, the volume of such tasks became overwhelming. We realized that merely scaling horizontally and increasing the number of first-line specialists was not a viable long-term solution.
We needed to modify the processes themselves so that the same number of people could handle more tasks and expend less effort. Hence, we began searching for a solution.
In our retrospectives, we surveyed the specialists handling incoming requests. We attempted to categorize and classify tasks in the task tracker based on specific criteria.
We found that many tasks were quite standard. They barely differed from one another, always followed the same process, required similar actions, and yielded roughly the same outcomes.
Experiments and Automating Routine Tasks
Testing hypotheses and exploring automation possibilities took several years. During this time, a significant backlog of ideas accumulated. Together with the Imaga Research and Development (R&D) team, we conducted several brainstorming sessions and a strategic planning meeting. During these sessions, we devised solutions, proposed hypotheses, and drew up a plan for their implementation.
We decided to use customization tools in the task tracker. Initially, we needed to design a working algorithm. This responsibility fell upon the project managers, as they had the necessary experience in application intake. System analysts also participated in the process, helping to formalize and describe everything in the form of sequence diagrams. The implementation was handled by in-house automation developers.
After creating the algorithm, we adapted the task tracker to our needs: we utilized functionality-bound checklists, custom add-ons, tags, automation for status transitions and assignee changes, and custom fields.
We also introduced standards that are essential for automation and formalization of the process, outlining task selection criteria. For instance, defining what a task should contain when transitioning from assessment to implementation or from implementation to testing.
After creating the algorithm, we adapted the task tracker to our needs: we utilized functionality-bound checklists, custom add-ons, tags, automation for status transitions and assignee changes, and custom fields.
We also introduced standards that are essential for automation and formalization of the process, outlining task selection criteria. For instance, defining what a task should contain when transitioning from assessment to implementation or from implementation to testing.
We refined the existing checklist and outlined the documentation requirements in it.
Each feature addressed a specific problem. For instance, fields helped to make the ticket more readable and accessible to many people. We have many employees in our company. They periodically go on vacation, and new ones often join. It's crucial that any team member can pick up a ticket and understand what to do with it.
For minor tasks, we outlined a checklist detailing the stages they need to go through.
Before starting work on a task in development, we need to answer all possible questions in as much detail as possible, using both automated and manual checklists. We knew what to ask and what would be required later.
What We Automated and the Results We Achieved
We automated various types of tasks, such as log extraction tasks, scheduled maintenance processes, content updating tasks, and complex jobs.
Log Extraction Tasks
An insurance company employee wants to retrieve logs related to a customer who had previously reached out to the support team, perhaps because they couldn't renew or purchase a policy.
The insurance company has all the necessary details since the customer provides them through feedback forms. Essentially, the request needs to be rerouted to the technical team.
Such requests don't require any clarifications — they're straightforward, so we decided to automate them first.
Now, an insurance company staff member redirects log requests to the task tracker. Almost all log processes are fully automated and are handled separately. The incoming request lands in a dedicated swim-lane specifically for this topic and is forwarded to an AGIMA employee with the required expertise. Human intervention is only necessary if there's missing data in the request.
Given the large accumulation of logs, they are scheduled to be offloaded to separate servers. The logs are structured by product and creation date. When a specialist receives a request, they initiate scripts capable of retrieving the necessary data from the site's storage.
The script searches the relevant log for the user's ID and extracts all the found data. The employee then receives the results and updates the ticket. Feedback is sent to the client.
Our company is working on fully automating the process. Currently, it's artificially limited because logs can contain sensitive information. Human involvement remains essential due to technical limitations and complexities in security policies.
An insurance company employee wants to retrieve logs related to a customer who had previously reached out to the support team, perhaps because they couldn't renew or purchase a policy.
The insurance company has all the necessary details since the customer provides them through feedback forms. Essentially, the request needs to be rerouted to the technical team.
Such requests don't require any clarifications — they're straightforward, so we decided to automate them first.
Now, an insurance company staff member redirects log requests to the task tracker. Almost all log processes are fully automated and are handled separately. The incoming request lands in a dedicated swim-lane specifically for this topic and is forwarded to an AGIMA employee with the required expertise. Human intervention is only necessary if there's missing data in the request.
Given the large accumulation of logs, they are scheduled to be offloaded to separate servers. The logs are structured by product and creation date. When a specialist receives a request, they initiate scripts capable of retrieving the necessary data from the site's storage.
The script searches the relevant log for the user's ID and extracts all the found data. The employee then receives the results and updates the ticket. Feedback is sent to the client.
Our company is working on fully automating the process. Currently, it's artificially limited because logs can contain sensitive information. Human involvement remains essential due to technical limitations and complexities in security policies.
Product Update Processes
We also automated regular technical maintenance and software product updating processes. We realized that we always performed this work at roughly the same time, involving the same people, and with consistent preliminary data. We gathered the information, analyzed it, recognized the need for scheduling, and set up automated update tasks. Previously, we had to remember or mark a date in the calendar and recall that maintenance or a certain certificate needed updating. Now, we have a maintenance schedule and a notification system in the task tracker, which autonomously creates a ticket at the necessary time for a specific person and sends them an email reminder. The employee completes the task, moves it to the next status, and after verification, the task is closed.
Complex Tasks Requiring Multiple Specialists
We understood that there are tasks unique in content but always follow the same process: analysis, design, development, testing, and release, with validation in between. Previously, there was one large board in the task tracker where tasks moved from left to right, and statuses were updated during meetings. After enhancing the functionality of the task tracker, interaction with each executor for such tasks follows a conveyor principle with maximally automated processes. The task arrives automatically for an employee; once completed, the executor checks off items on a checklist. The task is then assigned a new status and forwarded to another individual. Managers are now only needed occasionally — when there are questions, the task is non-standard, or there's insufficient input data. Thanks to standardization, the number of approvals has reduced, allowing us to provide clients with more accurate completion timelines. The average lead time from development to production on the project has reduced from 120-130 days to around 80, and we see the potential to cut it down to 50. It's important to note that tasks vary in complexity and duration. Some are closed in one day, others in one hour.
The revenue generated by managers increased by nearly 30%. The project's volume also grew, but the same number of managers efficiently handled the task volume.
A year was spent on process implementation, creating plugins, and refining them. We are now in the process of executing other ideas. Some plans were more ambitious than the final implementation, and some didn't work out due to the technical limitations of the task tracker. However, we strive to automate all possible repetitive tasks by any means available.
The transformation is ongoing. However, now we have results and understanding: we don't need to increase the number of people in the team, but can achieve higher productivity through automation.
The revenue generated by managers increased by nearly 30%. The project's volume also grew, but the same number of managers efficiently handled the task volume.
A year was spent on process implementation, creating plugins, and refining them. We are now in the process of executing other ideas. Some plans were more ambitious than the final implementation, and some didn't work out due to the technical limitations of the task tracker. However, we strive to automate all possible repetitive tasks by any means available.
The transformation is ongoing. However, now we have results and understanding: we don't need to increase the number of people in the team, but can achieve higher productivity through automation.
Future Plans
Currently, we want to give developers the ability to customize some aspects of the work process themselves. The proposal was well received.
We also plan to set up email integration so that based on an email's subject, a word, or a phrase, a task is automatically created. A script will parse information from the email and forward it to a ticket, then send a response to the person who reached out for technical support.
Challenges We Encountered During Automation
Introducing new processes always comes with challenges — for instance, with people. Not everyone is inclined towards the order required for automation and standardization. Some employees are not used to consistently updating tickets to the same statuses with the necessary amount of information, writing comments every time, ticking boxes, or filling out required fields.
Many approach changes with skepticism. Not everyone is open about their apprehensions, and as a result, employees may criticize the changes or resist them to thwart their implementation and protect themselves. In such cases, we have meetings in a conference room or share screens remotely, showing the process and its actual benefits, so that the person can see the tool's value for themselves. We assist in choosing other tasks.
Overcoming these fears is aided by openness within the company, as well as the practice of retrospectives, team meetings, and discussions. This allows us to identify concerns and address apprehensions.
Currently, we're gradually transforming the format of our regulations' descriptions and their presentation to cause less distress to people. We showcase new ideas during retrospectives or internal demos.
We strive to engage the entire team in the development of new solutions, to gather feedback, and to hear fresh ideas.
Overcoming these fears is aided by openness within the company, as well as the practice of retrospectives, team meetings, and discussions. This allows us to identify concerns and address apprehensions.
Currently, we're gradually transforming the format of our regulations' descriptions and their presentation to cause less distress to people. We showcase new ideas during retrospectives or internal demos.
We strive to engage the entire team in the development of new solutions, to gather feedback, and to hear fresh ideas.
Processes That Can Be Automated
By default, automation is suitable for repetitive tasks: if we automate testing, we use the same states in the same sequence. Here, the living mind of a human isn't required; it's enough to describe the scenario.
In our opinion, the following can also be automated:
- Not the entire process, but parts of it. Even if the chain of actions is unique, you can always simplify, automate, and template its parts. To replicate a practice that worked well, project management frameworks are implemented — templates that can be followed with a high likelihood of achieving a decent result.
- A stage or a particular process within tasks. For instance, instead of maintaining a large staff of project administrators, document management can be automated. Or at least it's worth a try.
- Financial accounting or document approval. The process would likely be the same: mark a task as completed, forward it to accounting for payment, and receive a payment notification.
- Requirement validation and internal validation using ChatGPT and similar bots. For example, automating the initial validation of fields in documentation. Currently, we're starting to implement checks to ensure that technical fields are described consistently throughout a document. We've tested ChatGPT for these tasks, and it performs wonderfully. Thus, it can be integrated into some automated processes to avoid tedious tasks — like checking phrasing on 100 pages.
Recommendations for Those Wanting to Replicate Our Experience
Start by analyzing the flow of tasks over a year or two and try to identify commonalities, grouping them by certain characteristics.
Divide tasks into requirements, features, and management, for example. Maintain separate boards for them to avoid distracting developers with management and to focus analysts on requirements.
Customize your board, and then the ticket itself. Repetitive questions can be placed in a mandatory field of the ticket. This way, an employee won't be able to create or pass the task forward until this field is filled. For instance, if there is no appropriate test data for further task verification.
Gather feedback from employees and conduct retrospectives. Find out the challenges they face and the tasks they'd like to eliminate. Most likely, modern automation tools can assist employees, which will improve performance indicators.
Customize your board, and then the ticket itself. Repetitive questions can be placed in a mandatory field of the ticket. This way, an employee won't be able to create or pass the task forward until this field is filled. For instance, if there is no appropriate test data for further task verification.
Gather feedback from employees and conduct retrospectives. Find out the challenges they face and the tasks they'd like to eliminate. Most likely, modern automation tools can assist employees, which will improve performance indicators.
