Request Fulfillment Process

Body

The purpose of the request fulfillment process is to give advice or instructions; or allow subscription or access to defined, documented services.

Maintain user and customer service through efficient and professional handling of all service requests
Provide a channel for users to request and receive standard services for which a predefined authorization and qualification process exists
Differentiate between the predefined services/requests IT Services provides in a standardized way and guidance on how to subscribe/order; or how to go about it if not
Source and deliver the components of requested standard services (e.g. software, desk phone, courtesy account, firewall rule, one-time funding request, security certificate)
Assist with general information, complaints or comments

User: consumer of an IT service or related component
IT Services Logger: first point of contact by a user experiencing an incident
IT Services Solver: experts for a particular service asset responsible for solving incidents escalated by the first point of contact
Financial/Access Approval Authority: individual with appropriate authority to authorize the expenditure of University funds or to allow a user access to a given application or service
Process Manager: operational oversight of process activity for loggers and solvers on their team
Process Owner: accountable for the incident management process meeting organizational goals and process targets

Process Step	User	IT Services Logger	IT Services Solver	Process Manager	Process Owner	Financial / Access Approval Authority
Request identification	R	R	R	R	A
Request logging and validation	I	R		A
Request categorization	C	R		A
Request prioritization	C	R		A
Request authorization					A	R
Request review	C	R	R	A
Request model execution			R	A
Request closure	I		R	A
Monitors the people performing these activities for quality, etc.		C	C	R	R/A
Monitors to ensure the process is efficient and effective		C	C	C	R/A

All requests should be logged, controlled, coordinated, promoted, and managed throughout their lifecycle via a single system unless otherwise exempted by the IT Services Leadership Team.
All requests should be authorized before their fulfillment activities are undertaken. This ensures that resources are efficiently used only for authorized requests. This does not necessarily indicate that human approval is required for every request; a valid Miami username/password is an example of a valid method of authorization.
Requests and their statuses must be timely and effectively communicated.
Fulfillment of requests should ultimately take place under an agreed set of criteria for determining their priority that is aligned with overall service levels and objectives. When an agreed set of criteria for determining priority is not in place, an umbrella set of assumptions will apply.
Service requests that affect Configuration Items should usually be satisfied by implementing a (pre-approved) standard change.
The ownership of service requests should reside with a centralized function such as the service desk, which monitors, escalates, dispatches, and often fulfills the user request. This policy does not preclude other portions of the organization from logging, tracking, and fulfilling requests. As more information, access, and tools are made available to the service desk, ownership of specific requests will be transferred.

Service Request: a formal request from a user for something to be provided; for example, a request for information or advice, to reset a password, or to install a workstation for a new user
Incident:
Request Model: defines specific agreed steps that will be followed for a Service Request of a particular type (or category)