The only defense a person has in our over-communicated society is an oversimplified mind.
—Al Ries & Jack Trout1
Put simply, to an end user, IT either fixes stuff that is broken (Incident management) or provides new stuff (Request fulfillment). Which one does your department do more?
Request fulfillment is undoubtedly integral to the everyday work of any IT department. Every day there will be requests for new equipment from headsets to new workstations, requests for software installations or other services, such as new email groups, FTP folders, or yet other services that also require coordination with HR and facilities departments such as the off-boarding of terminated employees.
Other departments also handle user requests of their own such as applications for medical insurance, visitor passes, or cameramen deployments. The day-to-day work of many employees in an organization can be seen through the lenses of receiving requests from internal or external customers, and going through the motions of fulfilling them. Hence, the new buzzword Enterprise Service Management.
At the CERN particle physics lab in Switzerland, scientists, staff, and visitors can go to an online portal from which they can request IT services or rent a bicycle on-site.
Being systematic with your requests fulfillment process allows you to streamline and automate the flow of information and responsibility for the tasks involved in fulfilling a request in a consistent and trackable sequence, akin to a digital assembly line.
Unlike logging incidents however, Request fulfillment does not work by just redirecting emails from end users in ServiceNow and voila requests are created automatically in ServiceNow. For every request, there is a form to be filled, and approval and fulfillment workflows to be defined up-front.
In this chapter:
Request components: Overview of what it takes to fulfill a request in ServiceNow from both the perspective of the requester and of the fulfiller’s teams
World-class examples: Examples of front-end portals and the process that went into their making
Handling approvals: What could go wrong and how to avoid management blunders
Simplified collaboration: How to eliminate opportunities for duplication and confusion inherent in ServiceNow’s modular request architecture
Planning the portal
When planning your Request fulfillment portal it is easy to get caught up in discussions about first mapping all your business services, integrating with Assets management and Procurement, etc.
But unless you already have those processes in place and in a system trying to do all those things in tandem with your request portal project in ServiceNow could spell disaster, or unnecessarily postpone your go-live.
At Al Jazeera we went live with Incident management and worked to go live with Request fulfillment within weeks afterwards, considering it to be the true glory. But it did not work that way and seeing how big a challenge it actually was to stabilize Incident management in ServiceNow it was decided to focus on on-boarding all critical teams in the department first and making sure they were accustomed to managing incidents in ServiceNow with the service desk as the Single Point of Contact (SPOC) for all IT requests, including ERP’s. Then only came Request fulfillment, more than a year later.
Lesson learned, when we finally launched the portal at Al Jazeera we resisted the temptation to integrate it with Assets management. In fact as of 2017, the two are still not fully integrated even though both processes are managed in ServiceNow.
Other ServiceNow customers also shared similar experiences. At the University in California for example, IT had launched ServiceNow with Request fulfillment, Knowledge, and Incident management all at once but then within weeks they had to disable service requests in ServiceNow, citing spam and customer dissatisfaction, abandoned Knowledge, and focused on just using plain simple Incident tickets both to record incidents and requests2 (as we also did at Al Jazeera).
Also at CERN “It was decided to simplify the Request fulfillment process in order to achieve easier acceptance by the CERN user community.” 3
If those stories offer any insight as you approach your Request fulfillment project, remember that you are not in a marathon to implement ITIL basic processes and that a period of adjustment, customization, and improvement will normally follow the launch . Once things stabilize, build on.
User journey
In order to understand all the key elements of Request fulfillment in ServiceNow here are the steps of a typical request in ServiceNow. After this overview each element will be discussed separately.
Requester goes to the request portal through which she can request stuff.
She navigates to the form for the item or service that she wants, fills it and submits her request. She could also add the item to the shopping cart, request more items, and finally check out.
A Request record is created in ServiceNow for her request and goes through the Request workflow.
The request workflow will automatically trigger an Approval request to the line manager of the requester if her request crosses a certain price threshold.
Once the manager approves the Request, the Requested item workflow will be triggered for the Requested item (RITM). If more than one item was requested, a workflow for each requested item will be triggered at the same time.
If the RITM requires special approval, an Approval request will be triggered for it.
Once in the fulfillment phase of the order, the RITM workflow will create one or more Catalog tasks to procure and deliver the Requested item to the requester.
Once all Requested items have been delivered, the Request is closed.
As shown above, to request and fulfill a request, your customers, management, and your resolver teams will be subjected to multiple ServiceNow interfaces and records. To control all this, there is one workflow that defines the flow of all Requests (REQ) as well as workflows that define the approval and fulfillment process for each Requested item (RITM).
Each completed Request (REQ) in ServiceNow will have left behind all of the following records:
Request record (REQ)
Requested items records (RITMs)
Approval requests for REQ and for RITMs
Catalog tasks
Since things are already complex it is important that you strive to simplify things at each step as discussed below.
Front-end examples
The Request catalog is the portal to which you point your end users to make their requests. It is where they choose the item they want, fill the form for it, and submit their request.
It needs to be easy to navigate so that users can successfully identify the service they need, fill the respective form, and submit the request. Otherwise even if they intended to follow your process and submit their request via the portal, they may not be able to do it.
When reaching out to the service desk it is not always clear to the requester if they are reporting an issue about something that should have been but is not, or if they are requesting something new. For example, an employee may need to make international phone calls but when she finds out that she cannot do them from her phone extension, she may report it as an issue. However, from a service desk perspective, this may be considered a request and will require management approval (and cost center accounting). For this, as shown in the examples below, front-end portals often blend the ability to request new services with the ability to report new issues.
There is a lot of variety in structure, layout, and content of Request portals from organization to organization or even from one business unit to another. Within the Volkswagen group, Audi’s portal is different from that of Porsche’s, yet different from that of other brands in the group.
Depending on the size of your organization and your users’ expectations, your Requests portal may be considered the face of IT (or the entire organization), and it may thus need to be customized, or be embedded into an existing intranet portal that your users already access. If that is the case, you can build your Request fulfillment portal directly in your existing intranet portal and just send the requests to ServiceNow for processing.
Al Jazeera’s portal
At Al Jazeera , the service desk portal (see Figures 6-1 and 6-2) is accessible from the corporate intranet for staff members to preview the available services and request them by filling out the dedicated forms. The portal also provides one-click access for reporting issues.
Figure 6-1. Request portal at Al Jazeera is available in English and Arabic.
Figure 6-2. Request Portal at Al Jazeera built into the SharePoint intranet is responsive.
CERN Service Portal
The CERN Service Portal (Figure 6-3) offers access to all services offered by the research organization, lists the contact details of the service desk, and offers a search box as the primary interface. After all, CERN is all about finding answers to the secrets of the universe!
Figure 6-3. CERN Service Portal. https://cern.service-now.com/service-portal/
Some forms on the portal are Record producers, that is, based on a set of questions in the form, either an Incident or a Request will be logged.
Harvard University IT services
The IT services portal at Harvard University (Figure 6-4) combines access to information about the offered services together with links to requesting those services.
Figure 6-4. Harvard Univerity IT (HUIT) Services Portal . huit.harvard.edu/services
UC Davis portal
Like the portal at Harvard, the UC Davis portal (Figure 6-5) integrates the knowledge base with the requests catalog. First and foremost, it is a one-stop front-end to all IT services offered, even though many of the listed Services do not lead to a fillable ServiceNow form, but instead to a page that provides information about the service and instructions on how to request it (for example emailing [email protected]). Other links on the portal can take you directly to external service providers such as Office365.
Figure 6-5. IT Service Catalog for the University of California Davis. http://itcatalog.ucdavis.edu/
Volkswagen iServe
At the Volkswagen Group , each car brand has its own portal (see examples in Figures 6-6 and 6-7). Like at Al Jazeera emphasis is on quick access to the request forms of the desired service or item.
Figure 6-6. Audi Serviceshop for requesting IT and non-IT services.
Figure 6-7. iServe Requests portal for Volkswagen.
For internal workflows that involve a limited number of users or approvers, or where requesters themselves have work to handle in ServiceNow you may not need a glossy request portal and could more simply go with the built-in service catalog interface (see Figure 6-8). This will be the quickest to build, expand, and maintain.
Figure 6-8. Default Service catalog accessible from within ServiceNow
Integration options
You may as well consider using your own organization’s front-end portal solution and just integrate it with ServiceNow’s back end.
The portal could be built using ServiceNow’s CMS or Service Portal solutions, but note that unlike the option to build the catalog in ServiceNow directly, building a front end entails additional work distinct from that on the Catalog back end in ServiceNow. So you may as well consider using your own organization’s front-end portal solution, such as SharePoint or Drupal and integrate it with ServiceNow’s back end as some of the examples above have done.
This has the advantage that the front-end portal will be built and maintained by a team already dedicated to building front-end portals at your organization, while your ServiceNow developers can focus on the Catalog back end in ServiceNow, building workflows. If you go down this route consider these integration options:
Build and manage the forms in ServiceNow and have them embedded (with “iframes”) in the external front-end portal page.
This is an agile and hybrid solution that lets your ServiceNow developers control and update forms from ServiceNow without the responsibility for building the entire front-end portal. The downside is that forms may not be responsive from mobile phones.
Build all forms in the external portal (e.g., SharePoint) and have it send the submitted requests to ServiceNow either via Web Services or email.
Handling approvals
Even though managers in other departments tend to be concessive with granting approvals (so long as there is no chargeback), approvals also serve as explicit acknowledgements of responsibility for the risks that may be associated with the request (e.g., granting access to a system or the stealth of an asset).
If your approval logic is straightforward and the lines of reporting available in ServiceNow are accurate, then you could rely on ServiceNow to automatically determine who the right approver is for each request and collect the approval automatically.
However if you are in a situation where determining who should approve a particular request is somewhat complicated because, for example, actual reporting lines may differ from those declared in the HR systems, or because too many factors would need to be considered (e.g., approval required depends also on the seniority of the requester) then automating the approval logic in ServiceNow may not work for you. Consider this flexible approach instead:
The request form explains the type of approval required (e.g., Department manager) and asks the requester to name her approver (see Figure 6-9).
Figure 6-9. Field in a catalog form requesting the approver to specify who her Head of section is
An approval request is automatically sent to the suggested approver.
The service desk verifies if the named approver is the right one and if not informs the requester.
The request is approved once the service desk verifies that the correct approver has been named, and the approval is obtained.
This approach is efficient in that approval requests are sent automatically as soon as the request is submitted, on the fair expectation that the requester knows who her boss is (department manager, bureau manager or whichever approval level is requested).
As such, you eliminate the chance for delays caused by ServiceNow incorrectly sending the approval request to the wrong person (e.g., a manager on leave and no delegate set in ServiceNow).
The need for the service desk to review the suggested approver may be protested as a bottleneck. But note how neither the service desk needs to wait for the suggested approver to respond, nor does the approver need to wait for the service desk verification to approve. The two can happen simultaneously (see Figure 6-10).
Figure 6-10. Flexible approval workflow if you do not have perfect information in ServiceNow
Duplicate approvals
ServiceNow may collect multiple approvals possibly from the same manager for the same request:
If the request crosses a certain expense threshold, then an approval request can be sent to obtain approval for the budget expenditure (Figure 6-11).
Figure 6-11. Approval Requests in ServiceNow can be comfortably approved or rejected directly by email
If the Requested item (RITM), for example access to a particular system or shared folder requires approval from the line manager of the requester, or the system owner, then another approval request will be triggered for the Requested item.
To avoid the annoying and inefficient duplication of approval requests, you may customize ServiceNow to skip the second approval if it is going to be sent to the same person that just approved the request. But then you lose the flexibility of approving single RITMs and rejecting others; it's a trade-off.
Bypass or modify approval
Especially when you first pilot and introduce your portal, your service desk may have to fill in request forms on behalf of requesters on the phone, or when the request is received by the service desk already with the necessary approvals.
On such occasions, even if your service desk logs the request on behalf of the requester, ServiceNow would, by default, trigger and wait on the approver to approve the request. To avoid this, you can provide the service desk with the option to bypass approval and move straight into fulfillment.
This could be done with a checkbox on forms that is visible only to service desk analysts which, once checked, would bypass approval and move straightaway to fulfillment. Alternatively, they could set the Requested by and the Approver fields to be the same so that no approval request is sent.
Detailed approval requests
In the email notification that is sent to the requester upon logging a request it would be useful to include a copy of the form(s) that were filled in. It makes the email much more valuable for reference, in case of disputes or issues, and for sharing.
The same goes for approval requests; laying out the entire request directly in the email sent to the approver will make it easier to approve and review the request (see figure 6-12).
Figure 6-12. Filled form is sent in the approval request email
Collaborating on requests
As outlined above, for each request there will be a Request record as well as at least one Requested item record. Then there will also be Catalog tasks for the fulfillment and delivery of the requests.
Each of those ticket types can be assigned and has comments, work notes, and email notifications. When an analyst on the fulfillment side wants to update the requester, on which comments fields should she type? How can she put the request on hold?
In the cited examples where IT had to backtrack on its request portal, one key issue that upset customers with requests was the level of “spam” they received from ServiceNow.
To avoid confusion and duplication, I recommend simplifying and consolidating the channels of communication for requests as follows:
Use Catalog tasks to assign work on Requests.
Request and Requested item records are not actionable records; they may be pending approval or may have work in progress as tracked in a Catalog Task generated by the workflow. The assignable unit of work for a request is the Catalog task.
It will be confusing if Requests are assigned; assign only Catalog tasks. If there is a need to assign new work about a Request, a new Catalog task under the Request can be created and assigned.
Unify on only one user-communication channel per request.
Potentially, each Request , Requested item, Approval request, and even Catalog task can have its own communication thread and watch list members, and so messages and replies could easily be fragmented across all those tickets. A simpler solution is to maintain that all user communication with the requester gets posted to the Request’s comments thread and only the Request record (REQ) generates the email notifications that are sent to the requester.
Anything that gets posted as a reply to an Approval request or to a Requested item should be posted as a Request comment (see Figure 6-13).
Figure 6-13. All communication with the user is consolidated in the Request ticket
Show requesters only one number for their Request
Have all customer-facing notifications sent about a request carry the REQ number, not the RITM. The notification may be triggered based on activity in the Requested item (RITM) workflow, but you only show the end user the Request number.
Task to attend unexpected requester comments
Finally, consider what happens if the requester writes a comment on the Request while it is pending approval, and there is no Catalog task open for it yet.
Because the Request is not assigned to anyone the update will go unnoticed. In such a scenario you could:
Assign the request to the service desk to handle the requester comments. The problem is that once the service desk replies what should it do with the Request ticket in its queue?
Open a Catalog task for the service desk to review and handle the requester’s inquiry . If new inquiries come in for the same request, re-open the same Task.
Replies to closed requests
Once a Request is complete email replies to it can be handled the same way as email replies to closed incidents, showing up in the Feedback list for the service desk (see Chapter 4).
Unlike for incidents however, a Request should not be re-opened. If it is determined that further support is needed, or that the support provided was incomplete, either a new request should be submitted or a new incident .
Tweet-ready takeaways
Since Request fulfillment is already complex as it is, strive to simplify things at each step of the process.
You don't have to build both the front end and the back end of your portal in ServiceNow; you can integrate with your intranet portal.
Even if your approval logic cannot be automated in ServiceNow, you can have a flexible and semi-automatic approval process in ServiceNow.
Keep it simple and unify on only one user-communication channel per request.
Expect to receive unexpected messages!