Scribd
Upload
126 views4 pages

Service-Now: Types of Support Tools

The document discusses different types of support tools used including Remedy, ServiceNow, and Radix. It then outlines the priorities, service level agreements, and statuses an incident can have in ServiceNow. Finally, it provides the steps for raising, developing, testing, and implementing a change request.

Uploaded by

harish
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
126 views4 pages

Service-Now: Types of Support Tools

The document discusses different types of support tools used including Remedy, ServiceNow, and Radix. It then outlines the priorities, service level agreements, and statuses an incident can have in ServiceNow. Finally, it provides the steps for raising, developing, testing, and implementing a change request.

Uploaded by

harish
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

INC714080: Finance: cash journal issue

INC622447:

Types of Support tools

1. Remedy
2. Solution Manager (SAP Product) (SOLMAN)
3. Service-Now
4. Radix
5. Clarity

Service-Now
Queues in Service Now:

My Assigned work:

My Team assigned work:

My Team unassigned work:

Below are the Priorities of the incident

1. Low
2. Medium
3. High
4. Very High
Impact of Priority: SLA (Service Level Agreement)

1. Low: We should resolve the issue in 5 days


2. Medium: We should resolve the issue in 3 days
3. High: We should resolve the issue in 1day
4. Very High: We should resolve the issue in 3 Hrs

Below will be the status of the incident

1. New
2. Active:
3. Awaiting User Info:
4. Resolved
5. Closed
**Please ignore “Vendor contacted” and “Awaiting change”

Initially the status of the incident will be new

Once the incident is assigned by Project manager or any concerned person, the status will get change to
“Active”

 From here onwards the SLA will start.


 If we need any information from the user, we set the status of the incident to “Awaiting user
info”

Note: When the status of the incident is “Awaiting user info” It will not come under SLA. i.e it will
not count the time.

 Once we get the all required information from user, we resolve the issue.
 If the user satisfied with the resolution that was provided by us, we have to set the status of the
incident to “Resolved”.
 After 5 days, the incident will automatically get “closed”
 These five days, user will have the option to “reject” the solution.

CHANGE REQUEST

Support Project:

If any configuration or program changes are required, we need to raise the change request.

Once we raise CR, we can close original incident and ask the user to follow CR.

Implementation project:

Once the BBP is signed off, client is not allowed to make any changes or to give any new processes
to map. If they do this, then that is treated as Change request.

Below are the steps:

1. As a first step, we get all the requirements


2. Consultant create the Change request
3. Do the configuration/development changes.
4. Do the testing (FUT) – Functional unit testing
5. Release the TR
6. Request approval to Quality
7. Get it approved by concerned person.
8. Do the Quality testing and Integration test if any
9. Get UAT (User acceptance test)
10. Request approval to Production
11. Get it approved by concerned person.
12. Get it implement in Production

You might also like