Skip to main content

Service Requests, Incidents, and Work Intake

ITIL provides useful terminology for understanding why work enters ISS.

Not every ticket represents the same kind of work.

Two particularly important concepts are service requests and incidents.

Service Requests

A service request is a normal request from a user for something ISS provides.

Examples may include:

  • Software installation
  • Access to a system
  • Equipment setup
  • Password assistance
  • A new computer
  • Help configuring an application
  • A request for information
  • A standard technology service

Service requests are expected parts of delivering and supporting our services.

Incidents

An incident is an unplanned interruption to a service or a reduction in the quality of a service.

Examples may include:

  • Email is unavailable.
  • Wireless connectivity is failing.
  • Classroom technology stops working.
  • Colleague becomes unavailable.
  • A service becomes unusually slow.
  • A customer cannot use functionality that normally works.

Not every incident is a major outage.

An incident may affect one person, a group, a location, a service offering, an entire service, or a significant portion of the College.

Detailed Incident Management requirements are addressed later in this chapter.

KACE and Work Intake

KACE is the primary system ISS uses to record and manage service requests, incidents, and routine operational work.

The ISS Communications Standard establishes the fundamental expectation:

Work begins with a ticket.

Tasks estimated at eight hours or less should normally have a ticket before work begins.

Work estimated to require more than eight hours should receive greater visibility through the weekly status report and appropriate planning.

Work exceeding eight hours does not automatically become a formal project.

Depending on the work, the manager may determine that it should be handled as:

  • Maintenance or sustainment
  • An enhancement
  • A change
  • A small project using the basic project methodology
  • A formal project using the complete project methodology

Outages and emergencies are exceptions when immediate response must occur before normal documentation can be completed.

Work Intake Helps Determine Where Work Belongs

Most customer requests initially enter ISS through Operate.

From there, the work may:

  • Be resolved through normal operational support.
  • Be identified as an incident requiring service restoration.
  • Reveal a recurring problem that needs further analysis.
  • Identify an opportunity for continual improvement.
  • Identify a larger need requiring planning.
  • Result in Build work.
  • Become a formal project.

Tickets therefore provide more than a list of tasks. They are also an important source of information about how our services perform and where improvement may be needed.

Either Party Can Create the Ticket

The customer does not always have to create the ticket.

If an ISS employee receives a legitimate technology request through:

  • Email
  • Telephone
  • Microsoft Teams
  • In person
  • Another appropriate communication method

the ISS employee may create the ticket on the customer's behalf.

The customer should not be required to restart the support process merely because they contacted someone directly.

The Ticket Is the Operational Record

Tickets provide:

  • Ownership.
  • Visibility.
  • Customer communication.
  • Troubleshooting history.
  • Workload information.
  • Resolution history.
  • Service-management data.
  • Customer feedback.
  • Information for continual improvement.

The ticket should contain meaningful information about the work.

As work progresses, employees should document information such as:

  • Troubleshooting performed.
  • Relevant findings.
  • Communication with the customer.
  • Changes made.
  • Vendor interaction.
  • Decisions affecting the request.
  • Work remaining.
  • Dependencies or delays.
  • Expected next steps.

Important operational information should not exist only in someone's email, Teams messages, telephone conversations, hallway conversations, or memory.

Detailed expectations are addressed later in Documenting Our Work.

Reassigning Work

Reassignment is sometimes necessary, but reassignment does not mean simply changing the ticket owner.

Before handing work to another employee or team, document:

  • What has been done.
  • What was found.
  • Why the ticket is being reassigned.
  • What is believed to need to happen next.

The customer should not have to start over because ownership changes.

Back to top