Service Request Form Development Automates Workflow
For new hire and termination tasks that require timely and thorough execution, a manual system leaves too much to chance. Communication is often initiated by rote, subtasks read off a checklist and assigned in separate messages, and reminders are managed through Outlook calendars. What results is new hires report to work without all of the necessary hardware, software, and access to do their jobs. On the other end of the employment spectrum, terminated employees depart with account access still enabled long after they’ve cleaned out their desks. Or worse, access is accidentally disabled well before they’re notified of their employment status. No matter what the oversight, no matter how infrequent the occurrence, the consequences have nightmarish potential. It doesn’t have to be that way.
Any ITIL v3 verified platform incorporates an online service catalog and self-service portal available to end users as well as IT staff. This includes intuitive forms for end users to submit new incidents and service requests, a searchable knowledgebase and the ability to view the status of previously reported incidents and requests. Service catalog items contained within a standard service desk implementation feature pre-built forms and pre-defined workflows for hardware, mobile device or software purchase requests; Access requests to a system or facility; or requests for a password reset by an agent. Aforementioned examples aside, any manner of task that can be documented, inserted into a web form drop-down list, and routed via email to the appropriate group or individual can be part of an automated workflow and approval process.
Using the HR example, service desk developers can create forms for submission of new hire requests into the service request section of the end user portal. The form can allow for entry of the new employee’s name as well as a freeform notes field for describing any additional hardware, software, accounts, and telephony needs. Developers can likewise create forms for termination requests with the same fields, freeform notes, and relevant tasks regarding the termination. These requests, upon submission, can allow multiple levels of management approval before being authorized and routed for completion to the group or individual responsible. For new hires, hardware procurement and set up tasks may be routed to the relevant groups, imaging and software installations to another, access to various systems to yet another group. Most importantly, the workflow rules, checklist items, and role-based authorizations can be customized and managed from one form using one ITSM platform. In addition to the multiple “triggers” set in motion from one form, subsequent email reminders of open items can auto-generate at predetermined intervals. Form rules can also be set up to reroute task ownership in the event of absences or other unavailability statuses of those resources in the queue.
It’s also important to illustrate that forms are not finite entities upon completion. They can always be modified to accommodate morphing organizational structures, new technology releases, or policy and procedure changes. Different data fields may be captured, task notifications routed to different groups, access, and device requests shifted to different departments entirely. What does remain consistent is the process by which the service request form development team works with client IT management throughout the form design and testing phase to ensure all service requests function harmoniously with their operational construct. And of course, the automation of task distribution, approvals, and notifications through the fulfillment of those requests is designed to minimize the opportunity for human error that is more often by omission than commission. The good news is once that process is set in motion with the submission of a properly developed web form, it’s that much harder for even the busiest internal staff to forget what to do next.