Return to Previous Page
A common question we hear in tracking incident tickets for IT is "what do the statuses in Incident mean? or "how should I use the statuses in Incident?" You have the ultimate say, yet we will discuss the traditional interpretations we hear.
Many of us "old hats" came from a CMMS that used "Approved". That was confusing to "customers", often because they expected someone was implementing a resolution immediately, but that was not always the case. When founding Incident, we decided to use basic language that would be more easily interpreted.
Where you see links to view "TOTAL ASSIGNED" work that is considered open, SchoolDude will typically ignore statuses of Complete, Closed, Void, Duplicate, Declined, On Hold, Forwarded. SchoolDude's custom data and reporting services have performed work with clients on their specific definitions and groupings of what is "open" vs. "closed" vs. "ignore" in custom dashboards and reports.
Be sure to give your feedback on how you have used statuses, particularly for "complete" vs. "closed" in your organization.
New incidents are initially set to this status. Generally, they have not been assigned to someone for the work to be completed. Typically, there is not an action taken on the job yet.
First stages. We are not 100% sure who will do the job or if we will perform it.
Work in Progress
Any incidents assigned or scheduled to be completed. Typically at this stage, the incident has been reviewed and assigned for resolution.
We are on the job.
A Complete status signifies that all actual work has been performed. Transactions such as purchases or labor may not be fully captured on the work order yet, but this will alert personnel that the work has been done.
The job is done.
Both the work and any documentation has concluded. Once all notes and/or transactions are added into the incident, or if corrective action has been verified, this is often when work is “closed”. Once an incident is closed, no more transactions can be added unless you reverse the status back to “Complete” in order to capture new entries for labor, purchases, etc.
The job and any documentation about the job is done.
The job will be done, but not until resources are ready.
It is in the hopper, but more pressing needs have to be attended to first.
Any work order that you want to keep open for an extended amount of time. This can be used to keep track of notes or labor hours for a general task done daily or for extended time periods (e.g., server maintenance, staff training)
There is no need to create incidents for every instance if I am tracking labor or purchases, so keep it simple with an open job for several weeks or months. Journal Notes are helpful for any additional documentation by date.
Parts on Order
The incident is waiting for the arrival of parts before continuing.
We will resolve the issue when supplies arrive. It is handy to use the Action Taken field to let everyone know when supplies are expected.
Work is paused (besides waiting for parts or waiting on more information), perhaps due to coordinating resources.
We are not ready yet, but do expect to perform the job.
Waiting More Information
If you are waiting for more information from the requester or another person before proceeding the completion of work.
The work description was not clear or there are circumstances that need clarification.
This request is waiting for monies or funding to become available before work can begin.
If we get the funds, we will do the job, but it is not certain at the moment.
This status is used to show that a work request has been recognized, but is waiting to be performed at a later date.
We are identifying the need, but it must be on the backlog until a confirmation or a denial is given.
Show incidents forwarded to another department. This is often used to route work from IT to Facilities (a copy can be automatically cloned from SchoolDude’s Incident to MaintenanceDirect). This can be done when a service request is mistakenly entered to the wrong department.
This was submitted to the wrong department and we have forwarded it to the correct one. Example: an issue in a computer lab was determined to be an electrical issue vs. hardware issue.
incidents that will not be done. They may be declined by a site administrator or by a person in the IT department.
We do not have the resources or that is outside of our typical scope.
A previously requested incident already exists.
We know about it and it has been documented elsewhere already.
Incidents you would like to ignore and not appear in reports unless specifically requested. You cannot delete an incident, so you may want to “void” them, or overwrite the incident's content with work you actually do intend to perform.
Ignore this, I was testing what an incident would look like.
Incidents that were not properly resolved, or the issue has resurfaced.
Someone caught the issue and there is not a need to create a new incident.
Add your comments below on how you have used statuses, particularly for "complete" vs. "closed" or other statuses.