Gestión del sistema de ticketing

A day in my life managing a ticketing system for an AMS

Our service has two very different main activities. On the one hand, we are carrying out an application migration for the Client to a WEB technology, and on the other hand, we provide AMS maintenance service (Application Management Service), based on ITIL. In this article, I will focus on the second part, what a day is like as a maintenance service manager.

Management focus to Latin America and schedule adjustment.

Before I begin, I would like to clarify that our service covers several clients in the Latin America region (LATAM), so we have adjusted our working hours to adapt to this time zone. In my team, there are people who work in the morning/afternoon and others who work in the afternoon/ evening to better meet the Client’s needs. This means that, in some cases, we can offer a “around the clock” ticketing management system to work with urgent ticketing needs, starting in the afternoon and finishing them by morning.

What is ticketing? The life of a Work Item.

In our AMS service, each task we perform is identified by an associated “ticket,” which is the management unit used throughout the team’s work. This ticket explains the task description, the problem to be solved, and how it has been resolved.

Ticketing and maintenance tasks are divided as follows:

I receive an email from Azure DevOps (our ticketing tool) notifying us of the opening of a ticket for one of the projects/applications we maintain.

Step by step in ticketing management:

The first thing I do in our ticketing tool is to check which category the ticket belongs to:

Bug: If the application is not functioning correctly.
Task: When a user has made an error entering data and needs us to modify it in the database. We need to ask for permission for this!
Evolutionary: When a new process is requested for the application or an existing one is adapted to a new business requirement.

Prioritisation and assignment in the ticketing system.

The next thing I do is prioritise the task based on its type and other factors:

Bug: Is it a critical issue? Does it affect more than one customer’s account? …
Task: How many tables are involved? Does it have an impact on billing (a critical process for the customer)?
Evolutionary: Does it have a deadline? Do we have available staff?

Then I assign the task to a team member. Normally, Evolutionary tasks are addressed in the morning when there is more availability of people and fewer urgent tasks. Assignment in our ticketing service depends on the availability of people and whether the project already has someone working on another requirement. Bugs and Evolutionary tasks that require an urgent solution are assigned to the afternoon team. It is important to note that if a Bug is identified after 00:00 and it is critical enough, we can address it in the morning, and it is the manager of the morning in Kiteris who assigns it (I work in the afternoon/ evening shift). Whether it’s that person or me, the assignment is done through our Azure DevOps ticketing management tool, which sends an email to notify the assigned team member.

Working on the solution.

Once the task is assigned, the ticketing management process varies depending on the type:

Bug:
We verify that it is a real application error and not incorrect data or a database issue. It is crucial to reproduce the error in our maintenance environments. If it’s the latter, we reject the incident and explain the reason in Azure DevOps ticketing tool.
If the error is real, we move on to developing a solution.
Task:
We prepare the database script to correct the data.
We validate with the client before executing it.
We send it to the DBA to run in the corresponding environment.
Evolutionary:
First, we hold a meeting with business analysts to evaluate the need that originated it, its feasibility, and potential impacts on other modules.
We conduct a detailed analysis of modules, classes, and tables that need modification.
We estimate the necessary work hours for development and communicate this to the client.
We carry out development, usually after opening a new ticket dedicated solely to development since the initial ticket was only for analysis and assessment.

Testing Phase

We start the testing phase. It’s important to note that we work with three different environments: EVO (Evolutionary), PRE (pre-production), and PRO (production), and each type of task follows a specific process:

Bugs: If an error occurred in EVO, we only test in EVO. If it occurred in PRE or PRO, we test in PRE using the same data or as similar data as possible to what caused the error.
Task: Once Client’s DBA informs us they have executed the script, we verify in corresponding environment that data has been corrected properly.
Evolutionary: It is always tested in EVO to ensure full implementation (checking each point of analysis) and compliance with Evolutionary requirements.

Informe de gestión de ticketing

End of ticketing journey: closure and evaluation

If tests are unsatisfactory, we go back to previous step. If satisfactory, we generate a version for EVO or PRE as needed.

Business analysts from each country test solution in deployed environment. If they find any errors or if Evolutionary does not meet requirements, we go back to testing step.

If solution is correct:

Bug: Generate version for next environment; when reaches PRO, close it. 2. Task: If correct, close directly.
Evolutionary: From EVO moves to PRE where undergoes new series of tests; finally deployed in PRO where closed.

Management and Monitoring of the Service

At the end of each month, we generate a report extracted from the ticketing tool that includes the number of incidents opened and closed, the work done by each person, the time dedicated to each ticket and sub-service, SLAs, among other relevant data.

We invite you to continue reading other interesting articles on our blog and discover the following success stories in ticketing management:

Thank you very much and see you in the next post.