
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
A quick update for those of you that were interested in our Work Request Management application.
We decided that an additional application was needed to enabled us to reduce the complexity around handling Requests.
As you are probably aware the out of the box REQ -> RITM -> RTASK structure is great in concept but for the most part only works for those wanting an Amazon style shopping cart. Multi-buys etc.
*we only delivery services to internal customers and in the most part these are one item per request.
We ultimately wanted a blend that sat somewhere between Request Fulfilment and Service Requests and a way for us to differentiate between a "I need" request and "it's broken" incident.
We built a completely new application called Work Requests, which is pretty closely aligned to Service Requests but based on the Incident form.
Overview of the key differences:
Field | Incident | Work Request |
Ticket ID | INC | WRQ |
Customer | Yes | Yes |
CI | Yes | Yes |
Category | Yes | Yes |
Sub Category | Yes | No |
Urgency/Impact | Yes | No |
Priotiy | Calculated | Yes |
Due date | No | Yes |
Approval | No | Yes |
Child Tasks | Yes - Lead Incident | Yes - Master Request |
Cost | No | Yes |
From the service catalogue the customer is given two options to raise ticket to IT
- Create new Request - "I need…"
- Create new Incident — "Something is broken…"
For the most part this works pretty well, especially where we don't have a dedicated service desk to do the initial investigation .
*If the wrong ticket type is created IT staff can use a "Convert" UI action that changes the INC to WRQ or back the other way as required
The other key difference is that Work Requests have a workflow with a 5 stage process-flow to show IT where they are through the process- Awaiting approval
- Work in Progress
- Closed Incomplete
- Rejected
- Complete
The import one here is the Awaiting Approval. Work Requests require a Business Sponsor Approval, which is normally the line manager.
Once selected the Business Sponsor has two quick and simple ways to approve a Work Request ticket.- Accept or Reject via HTML email
- Accept or Reject via Web Self Service
Once approved, the Work Request can be actioned, if it's rejected the Work Request is closed and customer notified.
If the Business Sponsor changes at any time or IT decides that the request needs a different approval they can simply amend the form and the workflow will automatically restart and request approval again.
We've had such a success with this application that we now use Record Producers to create Work Requests across the entire Service Catalogue. Including the capture of the Business Sponsor... No more Catalog Items for us!!
In addition to this we achieve a simple multi layered request process by creating a parent Work Request with many child Work Requests.
This give us the ability to request Approval for the parent and use that approval on all child objects.
Just recently we have used this in our new IT Provisioning wizard. where HR or the Line Manager approve the "New Starter" Work Request and all subsequent child Work Requests for application and device access are pre-approved and are routed directly to application and device teams. Pure Magic! Anyway that's probably a future post....
Hope this sheds some light of our version of Requests in ServiceNow?
(its certainly far less complex and very efficient, for us)
Until next time...
Paul Hardy
Informa Plc.
Twitter | LinkedIn
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.