A support queue fills up with new tickets on a busy morning. One employee needs access to a shared folder, while another reports a crashed payment gateway. Both requests land in the exact same inbox. When teams treat every incoming ticket the same way, critical system outages get stuck behind routine administrative tasks.\u00a0Every support queue has two very different kinds of work hiding inside it, and treating them the same is what slows everything down.<\/p>\n
This article covers how to define and separate these two workflows effectively. We will explore the key differences, outline the metrics that matter most, and share best practices for ticket classification. You will also see how a modern service platform can help teams route issues automatically and keep operations running smoothly\u00a0with tools like monday service.<\/p>\n"}]},{"main_heading":"Key takeaways","content_block":[{"acf_fc_layout":"text","content":"
An incident is any unplanned interruption to a service or a drop in service quality. In plain English: something that should be working has stopped working, and users can’t do what they need to do.<\/p>\n
Incidents happen without warning, and they need fast attention. A broken VPN, a crashed application, or a frozen payroll system all count as incidents because they disrupt normal operations and put productivity at risk.<\/p>\n
The goal of incident management<\/a> is simple: get the service back up and running. You don’t need to fully understand why something broke during the incident itself. You just need to restore service quickly and document what happened so your team can investigate the root cause later.<\/p>\n Here are common examples of what an incident looks like in day-to-day work:<\/p>\n A service request<\/a> is a formal ask from a user for something to be provided, approved, or changed. Nothing is broken, the user just needs something new, standard, or expected.<\/p>\n Service requests follow predictable patterns, which is what makes them so different from incidents.<\/p><\/blockquote>\n A new hire needs a laptop. An employee needs access to a shared drive. A manager needs a software license for their team. These are planned, repeatable activities that follow known workflows.<\/p>\n Because service requests are predictable, they’re ideal candidates for automation and self-service. Why have an agent manually handle a password reset when the workflow can do it automatically? Organizations that implement self-service password reset tools can reduce password-related help desk tickets by 90%<\/a>, according to a Forrester TEI study.<\/p>\n Common service request examples include:<\/p>\n On monday service, these distinctions are built into how tickets are classified and routed from the start.<\/p>\n"}]},{"main_heading":"Key differences between incidents and service requests","content_block":[{"acf_fc_layout":"text","content":" Now that both terms are defined, the practical differences become easier to see side by side. The simplest way to tell them apart? Ask what the user wants. If they want something restored, it’s an incident. If they want something delivered, it’s a service request.<\/p>\n Here’s how the two compare across the dimensions that matter most:<\/p>\n\n\n
\n