A new employee starts their first day, but still does not have access to the required systems. The laptop is prepared, but waiting in another location. The manager does not know who is responsible for role-specific training, and HR is trying to reconstruct the preparation process from several messages.
The problem is usually not a lack of engagement. More often, onboarding is treated as a series of independent tasks rather than one process with an owner, status, and clear outcome.
ESM for HR helps organize these situations without turning the HR department into an IT team. The logic is simple: employee-related cases should be visible as processes, not as communication scattered across inboxes, spreadsheets, and messaging tools.
HR does not need another inbox. It needs a visible process.
In many organizations, employee case handling is still based on email, spreadsheets, and forms sent to specific people. This model works as long as the number of cases is low, the team remains stable, and participants remember who is responsible for each topic.
However, higher turnover, intensive recruitment, rapid headcount growth, or reorganization is enough for this simple mechanism to start generating delays. Messages land in different inboxes, documents are saved in several places, and the current status of a case has to be clarified through additional questions.
This is where the practical value of ESM, or enterprise service management, appears. In the HR context, it does not mean implementing an extensive HR system. It means applying service management principles to cases handled for employees, candidates, managers, and other departments.
A case should have an owner, status, action history, required data, and a clearly defined next step. This way of working increases process visibility. It becomes clear which cases have been submitted, who is responsible for handling them, and at which stage a delay occurred.
The biggest change is not the digitization of a form. It is the reduction of dependency on individual knowledge. When an HR employee is absent, other team members can reconstruct the context and continue handling the case without searching through private correspondence.
HR processes lose transparency when their flow remains in correspondence
In HR departments, many activities are repetitive, but they are not always treated as processes. This applies to onboarding, offboarding, role changes, document requests, data updates, benefits questions, equipment, and application access.
Each of these cases may involve several areas: HR, IT, administration, the manager, finance, or security. If communication takes place only by email, each participant usually sees only the part of the history they were included in.
The problem becomes especially visible when one task depends on the completion of the previous one. Granting the required permissions requires prior confirmation of responsibilities. Completing offboarding depends on the return of equipment and removal of access rights. A role change requires updates to data, permissions, and sometimes the scope of responsibility.
If these dependencies are not visible, the process starts to resemble passing the ball between teams. Everyone may complete their own part correctly, and yet the whole case remains unfinished.
ESM organizes this mechanism by registering the case, assigning responsibility, controlling status, preserving the history of actions, and enabling later analysis. It does not require copying the entire ITSM model into HR. It uses the practical logic of ITSM where HR needs control over the flow of cases. This broader logic is also reflected in the Mint Service Desk ITSM page.
Onboarding should not end with a checklist in a spreadsheet
Onboarding is the process of preparing a new person to start work and perform their responsibilities independently. It includes not only signing documents, but also providing information, preparing the workstation, granting access, issuing equipment, and planning role-specific onboarding.
From the employee’s perspective, this is one experience. On the organization’s side, however, it consists of activities performed by several teams.
HR prepares documents and personal data. The manager defines the role, responsibilities, and onboarding plan. IT creates the account, prepares equipment, and grants permissions. Administration organizes the workplace, access card, or other elements needed to start work. Depending on the organization, finance, security, or training owners may also be involved.
A checklist helps record tasks, but it does not solve the problem of responsibility, sequence, and communication. It has to be updated manually, versions have to be controlled, and everyone has to work on the same document. It is easy to miss a change in the start date, missing required data, or a task marked as completed without confirmation of the actual result.
A well-designed onboarding process should show which actions are required, who is responsible for them, which tasks depend on earlier decisions, and how completion of the process can be recognized. Not every activity has to be automated. What matters more is that the process does not disappear into correspondence.
It is also worth separating the standard flow from exceptions. Onboarding an office employee looks different from onboarding a remote worker, and different again from onboarding a warehouse employee. One extensive form often leads to some fields remaining empty while critical information lands in comments. Preparing several process variants for different employment types, locations, or roles is often a better solution.
HR workflows should follow the purpose of the process, not the department structure
A common mistake when organizing HR processes is mapping the organizational structure instead of the actual flow of work. Separate categories are created for HR, IT, administration, and finance, but it is still unclear who should perform the next step and who is responsible for the final outcome.
HR workflows should be designed around the purpose of the process. In onboarding, the goal is not to distribute tasks to several departments. The goal is to prepare the employee to start work.
Offboarding also does not end with sending information about the termination of employment. It is the process of safely and systematically ending cooperation with an employee. It includes removing or closing access rights, returning equipment, handing over responsibilities, completing required documentation, and confirming that the involved teams have performed their actions.
The case owner does not have to perform every task. They should, however, see the whole flow, react to delays, and confirm that the expected result has been achieved. Without this role, a process may have many contributors but still no one responsible for closing it.
This is the difference between a task list and a process. A list shows what needs to be done. A process also shows who is responsible for sequence, completeness, and outcome.
HR process development starts with visibility, not automation
ESM development in HR should be approached in stages. At the beginning, the most important step is to register cases in one place and gain basic visibility. Only then does it make sense to standardize forms, statuses, and the scope of required information.
The next step is to define responsibility and completion criteria for the case. Once these elements are organized, assignment rules, notifications, and reporting can be developed.
This sequence reduces the risk of creating a large configuration project that includes every possible exception before the organization verifies which processes actually need to be organized.
A new tool will not fix a process that has not been described first. Cases can be moved into a system and the same chaos can be recreated there: too many categories, unclear forms, no owner, and statuses that do not reflect real progress.
Before implementation, it is worth analyzing several recurring scenarios. Where does the case come from? What data is needed at the beginning? Who makes the decision? Who performs the actions? How can the organization recognize that the process has been completed?
Only after this analysis does it make sense to design queues, ticket types, forms, and handling rules. It is more reasonable to start with one or two high-frequency processes with many dependencies, such as onboarding, offboarding, or employee requests. After launch, actual usage can be observed and additional scenarios can be developed.
Automation requires consistent data and assigned responsibility
Automation in HR processes can be useful, but only when it is based on clear data and assigned responsibility for each stage.
If an onboarding form includes the role type, location, start date, and required access scope, some cases can be routed according to agreed rules. If the same information appears in a free-form comment, automation will rely on incomplete or inconsistent data.
A system can accelerate task routing, but it will not decide for the organization who should perform the task. When responsibility is unclear, automation only sends the case to the wrong place faster.
This is a common mistake in process improvement projects. Rules, notifications, and automatic assignments are implemented first, and only later does the question appear: was the process described correctly at all? As a result, the tool works according to its configuration, but the organization still does not know who is responsible for the outcome.
Automation should be treated as acceleration of agreed rules, not as a substitute for them.
Reporting should show where responsibility is lost, not only the number of closed cases
Reporting in HR processes should not be limited to the number of open and closed cases. The number of closed tickets says little if it is unclear how many times a case was transferred, where data was most often missing, and which stages regularly caused delays.
In HR processes, it may be more important to identify the point where responsibility disappears. It is worth analyzing cases waiting for data, processes stuck in a specific status, and tasks completed only after the planned deadline.
The example is simple. If onboarding is regularly delayed because required access information is missing, the problem may not be IT’s working pace. It may be that managers provide data too late or that the initial form is not precise enough. If offboarding gets stuck at equipment return, it is worth checking whether the process clearly defines who confirms the return and by when.
A report should therefore help answer not only “how many cases were closed?”, but also “where does the process lose control?”. Only then does data become a basis for improvement, not just a summary of activity.
HR should define the process, and IT should provide the technical foundation
The concern about burdening IT appears when every process change requires technical support or a configuration change performed by IT. As a result, HR depends on IT even when changing a simple form, and the technical team becomes responsible not only for the platform, but also for interpreting HR process rules.
In the ESM model, responsibility for maintaining the tool should be separated from responsibility for the process flow. IT may be responsible for security, integrations, platform availability, and technical standards. HR should define the handling logic, the required data, participant roles, and completion criteria.
This separation does not mean full independence between departments. Changes affecting other teams still require agreement. The goal is to limit situations in which IT becomes the operator of every business process simply because it is responsible for the system being used.
This is especially important in processes such as onboarding and offboarding. IT often participates in them, but it does not own the entire process. Preparing an account, equipment, and access rights is one element. The business outcome is that the employee is ready to work or that cooperation has been ended safely.
Mint Service Desk can separate HR case handling from day-to-day IT work
In this context, Mint Service Desk can act as a shared environment for handling HR processes without the need to manage them through separate inboxes and spreadsheets. Tickets can be organized by queues, types, priorities, and statuses, while forms can be adjusted to the information required in a specific scenario.
The history of actions and communication is preserved as a natural result of working on a ticket, which makes it easier to reconstruct the case flow. HR can have its own area of service, while IT keeps responsibility for the platform and technical matters.
Depending on the configuration, case handling can be transferred between the appropriate queues or teams, while the current status remains visible to the people involved. This approach can be applied to onboarding, offboarding, employee requests, and data updates.
This does not mean that every process should be mapped in the system immediately. First, it is worth defining the owner, data scope, and completion criterion for the case. Broader context is described in the article ESM: How to Extend Service Management Beyond IT Without Another Platform.
To assess how Mint Service Desk could be used in a specific organization, it is best to start with the process that currently generates the most delays, manual coordination, or questions about responsibility. A practical starting point can be contacting the Mint Service Desk team.
A good HR process ends with an outcome, not with a status change
When evaluating ESM in HR, it is worth looking not only at handling time, but also at the quality of the outcome. Onboarding is not completed because all tasks were marked as done. It is completed when the employee can start working, has the required tools, access to systems, and the information they need.
Similarly, a document request is not resolved when it is transferred to a queue. It is resolved when the employee has received the correct document. A data update does not end with confirmation that the case was received, but with the change being made in the appropriate systems.
ESM for HR should increase visibility of responsibility and reduce dependency on informal communication. A tool can support this model, but it will not replace the decision about who is responsible for the result.
The biggest problem in HR processes is rarely the lack of a form. More often, everyone has completed their own part, but no one was responsible for the whole case.
