Request Management

All requests can be made available in the service catalog for user access and submission. The submission of requests from the service catalog systematically launches the appropriate request workflows.

Yes, each request can be submitted from portal and use a pre-defined workflow.

______________________________________________________________________________________________

In addition to request access and submission via the service catalog (RqM1), other methods in which a request can be created must also include, at a minimum:

·        A purchase order that links or relates the request to the purchase order

·        Manual entry

·        Launched through an alert notification from monitoring and links to the alert notification

·        From a change record and links to the change record

·        From an incident record (requiring the completion of a request to resolve the incident), and links to the incident record

·        A chat session (if chat functionality is supported)

Yes, it does, request records can be created by various methods like manual entry, mail, bot, alert system, request, change, problem, external integration and API.

______________________________________________________________________________________________

Request entitlement can be managed systematically, preventing users from accessing requests via the service catalog/portal to which they are not entitled to receive.

This may be accomplished through service catalog capabilities (i.e., preventing access to requests based on user access/entitlement).

Based on Customer security profile only requests defined for those profile will be available for request

______________________________________________________________________________________________

Identify duplicate requests and flag these requests for appropriate action to be taken by the client.

Yes, Platform can match duplicated requests from same customer

______________________________________________________________________________________________

Client admins can create and apply templates for different types of requests that are needed for their organization with different forms, fields, and possibly prefilled data, depending on the type of request.

Examples of request types can include but are not limited to onboarding and offboarding a user, a new workstation, workstation/user moves and relocations, modifying employee information, password resets, the creation of an email distribution list, information requests, etc.

Requests can be defined based on service catalog customer and use different workflows for same service. Some basic services are delivered OOTB, but as common customer behavior, the service catalog are replaced for meet the organization needs

______________________________________________________________________________________________

Client admins can create and apply specific models for different types of requests that are needed for their organization which include templates (see item RqM5), tasks, and workflows specific to the type of request.

Yes, it dopes using workflows linked on services / service catalog

______________________________________________________________________________________________

From within the request record, the ability to look up and apply a service or component record, or an IT asset from the respective repositories and to select and apply the service/component/IT asset to the request

Additionally, services/components/IT assets can be systematically applied to the request based on the request type, template and/or model, user, etc.

All requests can be linked with IT Asset and CMDB based on customer service needs.

______________________________________________________________________________________________

A method to prioritize requests is available that can be based on risk, lead time, level of effort, severity, business need, workload, and other client-defined criteria.

The customer can prioritize requests based on level of effort, severity, business need, workload, and other client-defined criteria like agreement, priority, unit, VIP, Group or use copilot for defined their prioritize strategy

______________________________________________________________________________________________

Knowledge articles can be linked or attached to request templates and models, so they are available when a particular request is submitted.

The ability to search for a knowledge article from within the request record or any related task record, and link – or reference the article to the request record

For each service/task knowledge articles can be linked previously or by analyst. Same thing can be defined on workflow steps

______________________________________________________________________________________________

Supports the use of tasks and/or workflows. This must include, at a minimum:

·        The ability to build the task workflow and link it to specific request types, via templates and models

·        Supports conditional tasks and workflows driven by the status, condition, and results of previous tasks in the workflow

·        Supports both manual and automated tasks

·        Supports sequential and simultaneous tasks

Yes, the request workflow can be defined/designed based on customer or organization needs on bpmn desing

______________________________________________________________________________________________

Supports dynamic approval tasks at the request level or within the associated workflow tasks; dynamic approval tasks must include, at a minimum:

·        Conditional approvals based on certain data elements or thresholds (such as cost threshold)

·        The assignment of approvals based on certain data elements (such as user, department, or location)

·        Conditional approvals based on the acceptance or rejection of previous approvals

·        The reassignment of approvals if not actioned within a predefined time frame

·       Approvals can be performed in multiple ways; for example, within the toolset, via web access, via mobile capability, or via email at the approver’s discretion

All approval process must be defined on workflow and can be approved by web, app or mail. Conditions and expressions (as constraint) can be applied for specific business rules.

______________________________________________________________________________________________

Requests can be assigned to a group or person based on the request type, request model, or other predefined criteria such as location or department.

Tasks within the request workflow can be assigned to a group or person based on the request type, request model, and other predefined criteria, and to do so independently of the request (in other words, task assignments can be varied, and different from the request assignment).

Request assignments can be defined on service design, workflow (automatically) or manually.

______________________________________________________________________________________________

The main request can be accessed and viewed from within any associated task. The status of tasks, and the flow of work, can update the status of the main request; examples of this can include, but are not limited to:

·        Completion of approval task(s) can change the request status to ‘approved’

·        The initiation of the first fulfillment task can change the request status to ‘in progress’

·       The completion of the final task can change the request status to ‘fulfilled’ or ‘completed’

The subprocess on workflow can be used for trigger tasks or sub-requests linked on main request. These features need to be defined and customized based on customer needs and business process. Request Fulfillment models must to be designed before implementation and customer can create new ones based on company criteria.

______________________________________________________________________________________________

Service, component, or IT asset information can be added to a request/task at any point in the workflow.

Service, component, or IT asset records in the respective repositories can be added or updated from the request or tasks within the workflow.

Yes, it does. Service, component and IT asset information can be added to a request/task at any point in the workflow

______________________________________________________________________________________________

Purchase orders can be launched, linked, or referenced, if required, to complete the fulfillment of a request; for example, to purchase requested IT assets.

Requests linked with IT Assets will be triggered and based on IT Asset stock, the Stock Control will trigger a purchase request. (Available on IT Asset Management Stock Control)

______________________________________________________________________________________________

User, service desk, and other stakeholder notifications can be automated and triggered at certain points throughout the workflow/life cycle of the request. This can be at pre-defined points in the workflow, and/or triggered by status changes, and other pre-defined criteria/thresholds.

Customer can design all notifications automatically on request design screen, workflow on manually on interested parties

______________________________________________________________________________________________

Users can access and review the status of their requests via the portal/service catalog; this view should be restricted to the requestor/user of the request and allow them to update the request throughout its life cycle, including the ability to cancel the request.

Yes, all request information are available for customer on Service Portal

______________________________________________________________________________________________

The service desk can access and view the status and information of all requests and associated tasks through the life cycle of the request and launch manual notifications as needed as well as provide updates to interested stakeholders.

Customer can design all notifications automatically on request design screen, workflow on manually on interested parties. Updates can be send using comments area that will send additional information to users and stakeholders

______________________________________________________________________________________________

Requests and tasks can be linked or associated with service agreements, internal support agreements, and/or vendor contracts to monitor response, fulfillment, and other commitment targets, and launch automatic notifications to predefined stakeholders as needed.

Request fulfillment service levels can be defined, based on predetermined lead times and expectations for each request type and priority

All request fulfillment must be linked/associated with Service Agreements, Internal, External, Underpinning.

______________________________________________________________________________________________

Detailed information can be documented in both the request record and individual task records as needed throughout the fulfillment life cycle of the request. This includes status updates and other pertinent information about the request.

Default notifications are sent by platform (Create, Resolved, Closed, All internal Actions, manual actions (when needed) and status changed).

______________________________________________________________________________________________

Request records can be closed in the following manners, at a minimum:

·        By the user or requestor at any point through the life cycle of the request – as a result of canceling the request

·        Manually, by the service desk, the user, or by other eligible persons at the completion of the requested tasks

·       Systematically based on the completion of all underlying tasks in the workflow

Yes, it does and must to be defined on service workflow based on customer business rules

______________________________________________________________________________________________

Incident records and/or change records can be launched from within the request, linking the records together; this can be done as part of the pre-defined request workflow, or manually as needed.

On request screen there area relationship with Incident Process, Change and can be created/linked manually or defined on workflow.

______________________________________________________________________________________________

Ad hoc requests can be created and submitted for non-standard, unusual, or one-off requests. Workflows for these requests can be built within the request as needed.

Using Kanban tasks or sub-tickets customer can use ad-hoc requests/incidents or get information from other external source use integration via API.

______________________________________________________________________________________________

Costs associated with the request can be captured and aggregated, inclusive of purchased IT assets and billable hours, and can launch or link a billable invoice to the appropriate cost center/approving manager.

All request is linked with a cost. The request cost can be linked on financial process, Apportionments Tab, Account Activities