Blog Posts

Case Study: Analyzing the Complaints Process at Granada City Council


This is a guest article by Arturo Martínez Escobar from the Ayuntamiento de Granada-Agencia Municipal Tributaria, Nemury Silega Martínez from the Universidad de las Ciencias Informáticas in Cuba, and by Manuel Noguera from the Universidad de Granada. If you have a process mining case study that you would like to share as well, please contact us via

The city council of Granada was triggered to look at their dossier handling processes, because citizens had complained about delays. The administrative services group could identify time gaps where dossiers did not seem to advance, but they could not explain why these delays happened. Therefore, a process mining analysis was performed within the tax collection department of the Granada council. Because certain tasks were not registered in the IT system, the process mining analysis was combined with interviews of employees.

The results of this project changed the point of view of the managers in the department, who initially thought that the negligence of employees was the main cause of the delay. In reality, there were other factors such as a lack of staff rotation by incidents, and a lack of people with signing responsibilities whose rotation or absence was not covered, which influenced the delays. Due to this project, the organization has gained traceability and deadlines control, which results in benefits for citizens, public employees, and politicians.


Granada is a city with a population of 250,000 people in the South of Spain. The analysis was performed on one of the processes performed by the Municipal or Local Tax Agency, which acts as an agency with its own competencies for tax management and collection in the city of Granada.

Town Hall


The target of analysis was the appeals and complaints process about the collection of taxes and other public revenue. For example, when a citizen does not agree with a tax collection statement they can register a claim, which then starts the appeal and complaints process. They receive a response to their claim at the end of the appeal and complaints process. Because citizens had to wait a long time for their response, they started to complain to the city council about these delays.

In fact, delays in the appeals and complaints process are not just a performance problem, but they are also a compliance problem: There are legal deadlines, and it is a legal obligation for the council to expedite dossiers ex officio in order to meet these deadlines.

After receiving complaints about these delays, manual inspections of individual dossiers confirmed that there were indeed requests that were not advanced in a timely manner. However, officials were not able to tell whether this was a common problem and they could not explain why these delays occurred.

The appeals and complaints process starts when a claim is registered in one of three places: (1) Electronically via the General Registry office in the City, (2) in person at one of the General Registry offices, or (3) at the registry of the Local Tax Agency.

Complaints Process

Once the application is registered at the General Registry office (see middle lane in the above picture), it must be received by the registry of the Local Tax Agency (see upper lane in the above picture) and subsequently be delivered to the Appeals and Complaints department (see lower lane in the picture above), which is responsible for the resolution of these appeals. If the application is recorded directly at the Local Tax Agency, a note is created by collateral effect on the overall check to maintain traceability of the record. After the physical arrival of all documents regarding the application, the applications are delivered to the Appeals Complaints department.

Based on the manual inspections, we suspected that most of the delays were in starting the application to resolution process (see area highlighted in red above).


To find data for the process mining analysis, we checked the repositories such as the dossier database for records related to the activities in the process. We found that each application was written into a dossier row with information in a similar format. We also saw that the electronic registrations and the Registry Office IT system share the same database, and that each electronic registration description appeared with the suffix “-e” (which made it possible to distinguish electronic registrations from in person registrations).

While thee dossier database was shared, different tables were used for registering information at the different departments. This means that data from these different tables had to be combined to create a data set that can be used to analyze the full end-to-end process. The data contained a dossier ID, which could serve as the case ID. Furthermore, information about what was done (activity), who performed the process step (employee), and timestamps about the start of each step were available.

The main challenge was the re-creation of the dossier history from its beginning. The IT software applications that support the processes are all integrated within the municipal information system. However, they often use different field names regarding the same record across different tables. Furthermore, we had to clarify the actual meaning of each field in the database to identify exactly which records correspond to the citizen’s original appeal and which records correspond to new records created afterwards (indicating steps in the process).

To complicate things even more, although there was a dossier ID that could be used as a case ID, each application creates a new dossier ID to manage a new claim. The new dossier ID is different from the management dossier that motivated the citizen complaint (i.e., the original claim). Therefore, for each dossier ID there should exist a reference dossier ID or a dossier proceedings ID, which must be traced and correlated to create the full end-to-end data set.


We solved this challenge by extracting the dossier ID relationships (see figure above) between the three tables from the Local agency event log, the main registry event log and the claims records event log. The dossier ID from claims records event log was then used as the overall case ID for the data set.

We had to pay extra attention due to the different ways that the process can be started: Some dossiers had to be traced through two registries (if started at the General Registry office) while others went through only one (if launched directly at the Local Tax Agency). Furthermore, the claim dossier ID is only created when it reaches the resources processing unit. However, its history starts earlier (passing through a database record or two before). Therefore, the claim dossier ID had to be filled in retroactively for these earlier events.

Activity Names

Finally, an additional challenge emerged from the fact that the activity names were not in a readable form. A combination of three fields of numerical values and attributes had to be mapped to a human-readable label that indicated the activity that was performed in a meaningful way (see the table above for an excerpt).

After all these data preparations, we had created a CSV file with a total of 7,582 events and 2,511 cases for our process mining analysis.


We imported the data set in the process mining software Disco to discover the process that was performed for these 2,511 cases.

In the discovered process (see the process map below, which is based on the Total duration visualization), we could clearly see one major bottleneck, which has had the biggest impact on the delays. This confirmed our hypothesis from the manual inspections: There is a big delay before the application-to-resolution process is started in the Appeals and Claims department. We also saw that this was a general problem and not limited to a few exceptional claims.

Full Process

We then filtered the data set down to just the claim creation events and the start of the process in the Appeals and Claims claims department (see process map below). Certainly, 23.6 weeks, 18.6 weeks and 24.1 weeks on average to pass the registration processing does not look normal.

Partial Process

We then further analyzed the data set using the Dotted Chart plugin in ProM (see visualization below). The dotted chart plots each case in a horizontal line as a sequence of dots. Each dot represents one process step that was performed. The y-axis represents the time frame of the data set from March 2014 until September 2015.

From this visualization we can observe two things:

  1. There are areas in the timeline, where much less activity is shown than in other time periods. What happened there? Was the process stopped? Why?
  2. The vertical patterns of dots indicate that many activities were performed for different cases nearly at the same time. This indicates a batch processing pattern in the process.

Partial Process

As a next step, we had to find out what happened in those periods of inactivity in the process. Were these claims suspended or pending for some reason? Because there was no record in the data about what happened at that time, we performed interviews with employees working in the process to identify the root causes.

During these interviews we learned that:

We realized that — because they were not visible in the system — there was not enough awareness about the importance of these classification tasks. The feeling at the municipality was that the delays could be the fault of the employees. The employees were not recognized for their work on this highly specialized and important task.

Furthermore, it was now clear that the speed of the process could be improved by adding employees who would perform the manual re-registration tasks in the system until the data transfer was properly automated. This way, the knowledge workers would not have to spend time on these basic data entry tasks anymore.

In addition, we learned that there were also improvement possibilities in the resource organization: Particular people were responsible for signing the dossiers. When they were not available, for example, due to illnesses or vacation, then delays could occur. By ensuring a capacity to cover cases in situations of absence, delays in the dossier handling progress could be avoided.


Based on our analysis, we made the following recommendations:

New Process

As a result of these changes, we have now achieved the following improvements:

Process mining was totally unknown for the management of the organization as well as their technical staff. They have been impressed with the graphical power of representing the process flows and annotating the model with performance metrics. Frequent activities could be made visible and the results were easy to interpret.

Previously, the logs from the IT systems were only used for the purpose of occasional checks triggered by inquiries from citizens. The transaction records were never used to visualize, analyze or audit the process in a systematic way before. We have found that process mining can significantly help to improve administrative processes in our government agency, and we believe that this method is extensible beyond the department of resources and claims collection. For example, areas where we will explore process mining in the future are the social services processes, subsidies, tax collection and management, sports concession fees and licenses, etc.

We have learned that the exploratory analysis of the business process through process mining can reveal issues of concern that are unknown, and that it can impact the performance of the organization and performance of their employees. We have also seen that not all process activities are always captured in the system records. Therefore, it is good to sit down with the responsible users in an interview in addition to the process mining analysis to complete the picture. This can also help to uncover additional factors that influence the process, which are often not visible in the data.


You can download this case study as a PDF here for easier printing or sharing with others.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples