Css eng r1

33
Working in the CSS request tracking system.

description

 

Transcript of Css eng r1

Page 1: Css eng r1

Working in the CSS request tracking

system.

Page 2: Css eng r1

This document contains instructions on performing common actions in the request tracking

system CSS Remedy, used in Kaspersky Lab ZAO.

Getting started. Logging to the system.

In order to log into the request tracking system one should open the

https://companyaccount.kaspersky.com link in a web-browser and enter user name and password, that

was provided to authorized CSS user.

Please, note that the CSS request tracking system officially supports only Internet Explorer 8 and

Internet Explorer 9. If you are experiencing various errors while working with the CSS request tracking

system in a different web-browser then it is suggested to use Internet Explorer 8 or 9 instead, as such

issues can take extended period of time to be fixed or may not be fixed at all.

When you attempt to enter the system for the first time, you will be asked to change your password.

Page 3: Css eng r1

New password should meet common complexity requirements. It must contain uppercase and

lowercase characters and special symbols.

The following fields should be filled in: Current Password (enter your current password here),

and New Password followed by Confirm New Password (enter your regular password here which you are

planning to use for log on).

Press the Save button, after filling in the provided web-form and you will start working with the

system.

Changing the notification language.

After logging in the CSS system for the first time one should check the notification language,

which was set for the current account. Notification language should be set to English (United States)

value if it was set to any other value by any reason.

Do the following in order to change the notification language value:

1. From the Overview Console which is opened automatically after logging into the system, open

the Incident Management Console. In order to do so select Incident Management and Incident

Management Console from the drop-down list.

Page 4: Css eng r1

2. From the Incident Management Console select the “My Profile” link in the “Functions” drop

down list.

3. Upon selecting “My Profile” BMC Remedy IT Service Management Console will be opened.

Select the “Notifications” tab in the given console and check the configured value for the

Notifications language. If by any reason the configured value differs from the “English (United

States)”, then it should be selected from the drop-down list. After changing configuration press

the “Save” button and relogon to the system.

Page 5: Css eng r1

Working in the Overview Console.

Work in the CSS request tracking system starts with the opening of the “Overview Console”.

From the given console you can do the following:

Open Incident Management Console in order to work directly with the request tickets registered

in the CSS system.

In order to do so you should select “Incident Management” and “Management Console” in a drop-

down list.

Page 6: Css eng r1

You can find more verbose information regarding work in the Incident Management Console in the

“Incident Management Console and working with request tickets” section of this document.

Create a new incident in the request tracking system.

In order to do so you should select “Incident Management” and “New Incident” in a drop-down list.

You can find more verbose information regarding creation of a new request in the CSS request tracking

system in the “Creating a new incident” section of this document.

Find a request ticket registered in the system based on one or several attributes of the incident

(request ticket number, author of the request, etc).

In order to do so you should select “Incident Management” and “Search Incident” in a drop-down list.

Page 7: Css eng r1

You can find more verbose information regarding incident search in the “Search Incident” section of this

document.

Change password for the current CSS user.

In order to do so you should select the “Quick Links” and “Change Password” in a drop-down list.

In the result new console similar to the one which occurred during first login to the CSS system will be

opened.

Page 8: Css eng r1

Enter current password in the “Current Password” section of the form. Then enter new password in the

“New Password” and “Confirm New Password” sections of the form. Press the “Save” button after filling

in the given form and start working in the CSS system with the changed password.

Page 9: Css eng r1

Incident Management Console and working with request tickets.

Review of the Incident Management Console interface.

The following interface will be displayed after opening Incident Management Console:

In the top part of the Incident Management Console in the “View By” section one can select request

tickets queue to be displayed in the console.

Personal – request tickets queue, which consists of the incidents that have been assigned to the current

user logged into the system.

Page 10: Css eng r1

Selected Groups – request tickets queue, which consists of incidents that have been assigned to one or

several groups of specialists available to the current user. “My Group Selection” console will be opened

after selection of the given option:

All groups of specialists available for the current user are displayed in the current console. After

selecting all necessary groups in the given console press “Ok” button and the console will be closed.

Consequently all request tickets assigned to the selected groups of specialists will be displayed in the

Incident Management Console.

All My Groups – request tickets queue, which consists of incidents that have been assigned to all groups

of specialists available to the current user.

Four links for fast incidents sorting are located in the “Counts” section of the Incident Management

Console:

Open – all open incidents that are located in the selected queue, including new cases, cases waiting for

reply from the technical support, cases waiting for reply from the client.

Unassigned – all incidents that are located in the selected queue and are not assigned to any particular

specialist.

Unacknowledged – all incidents that are located in the selected queue, which are assigned to a specialist

and that are waiting for reply from the technical support side.

Breached – all incidents that are located in the selected queue and contain complaints from the

customer’s side.

Page 11: Css eng r1

Working with request tickets.

When the client submits an incident via web-form on technical support web site it appears in

corresponding queue and can be browsed from the Incident Management Console.

Each incident has unique ID, short description of the issue or Summary, Priority, Product Name and

Product Model/Version, and Assigned Group as well as several other attributes.

All these attributes can be browsed from the Incident Management Console.

Page 12: Css eng r1

In order to start working with some incident it should be opened by double left mouse button click on

the incident in the Incident Management console. Consequently Incident Management – Incident

Request console will be opened:

After submitting a new incident via web form on technical support web site, or via Incident Overview

Console (see “creating a new incident” section for more details) it will be automatically transferred to

corresponding incident queue. New incident should be manually assigned to technical support specialist

who will be working with the incident itself.

In order to assign incident to a particular specialist “Assignee+” status should be modified to account of

the specialist responsible for incident in question.

It can be done using one of the following methods:

1. Using a fast link Assign to Me, which can be found in the Quick Action section of console. This way the

incident will be assigned to the user that is currently logged into the system.

2. Using drop-down list next to the “Assignee+” field in the Incident Management – Incident Request

console.

Page 13: Css eng r1

You should select one of the listed accounts in the drop-down list, which represents specialists

responsible for the incident processing.

If selected, the account will be displayed next to the “Assignee+”.

Please, press the “Save” button in order to save and apply changes.

“Notes” field of the Incident Management – Incident Request console contains detailed description of

the issue submitted during creation of the incident.

In order to see the full description of the issue one should press the highlighted button next to the

“Notes” section:

It is possible to adjust size of the resulting screen and move it inside the window of console.

“Summary” field contains short description of the issue.

Next block contains information regarding product version, which was specified by the submitter of the

incident.

Page 14: Css eng r1

The given values can be adjusted if necessary; you can select alternative values from a drop-down list.

After changing configuration press the “Save” button in order to apply changes.

“Work Detail” block displays all actions that were documented in the case.

This block includes, information regarding internal and external correspondence, attached files, license

info.

“Submit Date”, “View Access” and several other characteristics are assigned to each entry in the given

block, and can be viewed from the Work Detail tab.

Page 15: Css eng r1

The following info is being displayed above the Work Detail field:

Assigned Group*+ - group of specialists, who are responsible for processing of the incident.

Assignee+ - Account of the specialist, who is responsible for processing of the incident.

Status* - current status of the incident.

The following statuses are available:

1. New – new incident, which was recently moved to the current assigned group. This case

hasn’t been assigned to any particular specialist, yet.

2. Assigned – case assigned to a particular person and waiting reply from the responsible

technical support specialist.

3. In Progress – this status is not used now.

4. Pending – case was processed by a responsible specialist, and is waiting for reply or any

other action from the customer’s side (for more details see possible status reasons below).

5. Resolved – case is closed. The issue was resolved completely and no further actions are

required. If necessary the given case can be re-opened from the client’s side.

6. Closed – case is closed. Cases with such status cannot be re-opened from the customer’s

side.

7. Cancelled – case was cancelled with or without explanation of the reasons. запрос на

техническую поддержку отклонен. Cases with such status cannot be re-opened from the

customer’s side.

Page 16: Css eng r1

Status Reason – reason for the current status of the case. Depending on “Status” value, possible “Status

Reasons” may vary:

1. For status Pending:

Customer Hold – the case is waiting for the customer’s reply. The given status reason is

used when it is expected that the customer will not reply to the case for a significant

period of time. If the given status reason is set then the customer will not receive weekly

notifications regarding inactivity in the case. This case will not be closed automatically if

the customer will not update case for two weeks or more.

Waiting for customer reply – the case is waiting for the customer’s reply. The given status

reason is used when it is expected that the customer will reply to the case soon. If the

given status reason is set then the customer will receive weekly notifications regarding

inactivity in the case. This case will be closed automatically if the customer will not

update case for two weeks or more.

Third Party Vendor Action Reqd – the case is waiting for reply from a third party

application vendor.

Waiting for new release – the issue is supposed to be fixed in a new release. Customer is

notified about that and is waiting for the new release.

Internal request – this status reason is not used now.

Waiting for bug resolution – this status is not used now.

2. For status Resolved:

Page 17: Css eng r1

Solution provided – solution is delivered and accepted by the customer.

Workaround provided – temporary solution or a workaround was found and delivered to

the customer. The customer accepted workaround and is not willing to further

investigate the issue.

Feature request registered – feature request for the future version of the product was

registered and forwarded to the product group.

No Further Action Required – the given case does not require any further investigation

and/or actions.

No reply from the customer – the customer was inactive for 2 weeks or more and the

case was closed automatically.

Resolved Automatically – the issue was resolved automatically without direct

intervention. It is not possible to pinpoint the issue or the root cause of the issue any

more.

3. For status Closed:

Redirected – the issue, described in the incident, is not technical. Incident was redirected

to the necessary division (sales, PR, etc).

Closed Automatically – incident was closed automatically.

4. For status Cancelled:

By customer – the case was closed by customer without any documented reason.

Support contract termination – the case was closed due to support contract termination

or expiration.

Transferred to HD – this status reason is not used now.

Transmitted in HD – this status reason is not used now.

Page 18: Css eng r1

“Create” button is used to create additional entries in the work detail tab. Every activity that occurred in

any case should be properly documented, in order to add any information of such sort press the

“Create” button:

Incident Work Info console will be opened. You can see interface of the console below:

In order to add any information to the “Work Detail” tab of the incident, one should do the following in

the “Incident Work Info” console:

1. Fill in the “Summary” field with a short description of the current entry which will be displayed

in “Work Detail” tab. If the given message will be public, i.e. will be sent to the customer, the

given text will be highlighted with a bold text and will be displayed in the beginning of the letter

to the client (we suggest to enter greeting here, for example “Good day”).

2. Fill in the “Notes” field with the actual description of the activity or instructions for the

customer. If the given message will be public, i.e. will be send to the end-user, then it is

necessary to verbosely describe the action plan, solution, configuration advice, etc. for the

customer here.

Page 19: Css eng r1

3. Select the necessary “View Access” value for the given entry. There are two possible values:

- Internal – given entry will be available only to support engineers via BMC Remedy (CSS).

Entries with status “Internal” will not be available for end-users. This View Access status is set by

default.

- Public – given entry will be forwarded to the customer. Entries with status “Public” will be

available for support engineers via BMC Remedy (CSS) and end-users via personal cabinet.

If necessary the appropriate “View Access” status can be selected from a drop-down list:

4. If it is necessary to add some files or screenshots to entry in Work Log, than one should press

the “Add File” button and select the necessary file in pop-up window. Then press “Open”

button:

Wait until progress bar will be filled in to 100%, this means that the given file was uploaded

successfully. If needed additional files can be added consequentially (up to 3 files). Please make sure you

have selected correct value in the “View Access” field before uploading files.

After adding all necessary data and uploading files, you should press “Save” button in the Incident Work

Info console in order to apply changes and add data to the Work Detail tab of the current case. In all

other cases press the “Close” button in order to discard changes and leave the Incident Work Info

console.

Page 20: Css eng r1

After applying changes all saved data will be displayed in the “Work Detail” tab, including the recently

created entry.

After adding reply to the customer in the “Work Detail” tab, the case should be transferred to the

“Pending” status; Status Reason should be set to “Waiting for customer reply” in most cases.

Press the “Save” button once again in the “Incident Management – Incident Request” console in order

to confirm changes in Status of the case.

After transferring incident to the “Pending” status, this case will be displayed in the queue of cases

“Open” in the “Incident Management Console”.

If the case in question, was assigned to a responsible specialist, the incident was answered and

transferred to the “Pending” status, there are no complaints regarding the incident, then it will be

displayed only in the queue if cases “Open” in the “Incident Management Console”:

Page 21: Css eng r1

Creating a new incident.

Support engineer occasionally has to create incident tickets via CSS request tracking system, for

instance, if some issue has to be escalated to a higher level of technical support.

In order to create a new incident, one should select Incident Management – New Incident from a drop-

down list of the Overview console.

Incident Management – Incident Request console will pop-up consequently:

In order to successfully create a new incident, one should fill in fields located in the highlighted sections

of the console.

During creation of a new incident field “Company” will be filled in automatically.

Page 22: Css eng r1

Several first digits of the support engineer’s last name or full last name should be entered in the

“Customer+” and “Contact+” fields in the Incident Management – Incident Request console. Then press

“Enter” button on a keyboard. “Customer+” and “Contact+” fields will be filled-in automatically or

several options will be suggested:

After filling in the first section, proceed to the “Notes” and “Summary*” fields. Fill in verbose description

of the issue in the “Notes” field, fill in short summary of the issue in the “Summary*” field.

Finally, you will have to select correct values for the following fields from drop-down lists:

Product Name+ - select correct product name.

Model/Version – select correct build of the product specified in the Product Name+.

Categorization Tier 1+ - category of the issues or product component which is causing the issue.

Categorization Tier 2 – subcategory of the issue, list of available options depends on value

specified in Categorization Tier 1+

Categorization Tier 3 – subcategory of the issue, list of available options depends on value

specified in Categorization Tier 2 (can be blank).

Impact* - impact of the issue. Select value according to the case priority table in the

“Regulations between Partner and Kaspersky Lab in providing end-user corporate technical

support” document. Or select 4-Minor/Localized value.

Urgency*- urgency of the issue. Select value according to the case priority table in the

“Regulations between Partner and Kaspersky Lab in providing end-user corporate technical

support” document. Or select 4-Low value.

Incident Type*- supplementary field, select Customer Support Incident option here.

Reported Source – supplementary field, select Direct Input or E-Mail option here.

Page 23: Css eng r1

After filling in all fields, form should look like this:

And:

Finally press the “Save” button in order to create new request, with the incident ID number equal to the

value specified in Incident ID*+ field. This case will be transferred to the queue of specialists which

includes specialist specified in the “Customer*+” field.

In order to escalate incident on a higher level of technical support, it has to be assigned to a particular

technical support specialist (refer to “Working with request tickets” section for more details) and

escalate the incident itself (refer to the “Incident escalation” section for further details).

Incident escalation.

Incident escalation to the second level of technical support should be performed only in cases of

a complex issue directly related to one of products developed by Kaspersky Lab that are currently

supported. If the issue in question is described either in knowledge base -

Page 24: Css eng r1

http://support.kaspersky.com/ or in the FAQ sub-section of the “Technical support” section in the

partner site, then escalation should not be performed. All necessary troubleshooting data should be

collected prior to escalation according to the FAQ sub-section of the “Technical support” section in the

partner side.

In order to successfully escalate incident to the queue of the higher level of technical support following

steps should be taken:

1. Create new entry in the “Work Detail” tab with filled escalation form from partner side:

======================

1. SHORT PROBLEM SUMMARY

======================

2. OS, KASPERSKY VERSIONS

======================

3. DETAILED PROBLEM DESCRIPTION

======================

4. STEPS TAKEN TO TROUBLESHOOT

======================

5. ATTACHED FILES DESCRIPTION

======================

Please, describe the issue in question as verbosely as possible, also describe environment of the

customer, recent configuration changes that may have caused the issue, steps taken to

troubleshoot the issue and results.

This form should be filled in correctly in order to successfully escalate request ticket to a higher

level of technical support. If the given form will not be submitted correctly support professionals

of the second level of technical support are authorized to return request ticket back to your

queue with description of the violation. Support professionals of the second level of technical

support are referring to the data listed in the escalation form only, they are not obliged to read

the whole correspondence included it the request ticket.

Page 25: Css eng r1

Press the “Save” button in order to apply changes upon adding entry with the described form to

the “Work Detail” tab (select status “Internal” for such entries).

2. Press the “Escalate” hyperlink in the Incident Management – Incident Request console, in order

to transfer request ticket to the higher level of technical support.

3. Press the “Proceed” button in the pop-up window.

4. Fill in all fields in pop-up window. You can copy filled-in escalation form here from the item 1 of

the given instruction, or short comments if the given form was submitted correctly. It is also

possible to attach additional files from here using “FTP Links” tab. Press “Save and Escalate

Incident” when you are done.

Page 26: Css eng r1

5. Press “Ok” button in pop-up window, notifying that the ticket was successfully escalated.

6. Finally, press “Ok” button in pop-up window notifying that the given incident cannot be

monitored any more as it was relocated to a restricted queue and the current account has

insufficient rights to monitor it.

Page 27: Css eng r1

Incident will be temporary relocated to another queue and will not be available in the Incident

Management Console until it will be processed by a technical support specialist or developer.

Incident will be returned back afterwards.

Page 28: Css eng r1

Incident closure.

When the incident is successfully resolved, one should set a “Resolved” status for it.

This can be done using one of the following methods:

1. Using the “Resolve” button in the Incident Management – Incident Request console. The

following console will be displayed after pressing the “Resolve” button:

All fields highlighted with a bold text should be filled in:

Assignee*+ - select account of a user closing the case from a drop-down list.

“Resolution” – description of the final solution which resolved the issue.

“Status Reason” - reason for assigning status “Resolved” to the current case. Please, refer to the

“Working with request tickets” section of the current document.

Page 29: Css eng r1

“Summary” – title of accompanying letter to the customer with notification regarding case

closure.

“Notes” – body of the accompanying letter to the customer with notification regarding case

closure.

“View Access” – view access of the case closure entry. If the “Public” value was assigned then

the customer will receive accompanying letter which will consist of the “Summary” and “Notes”

fields. Also these entries will be displayed in the personal cabinet.

Press the “Save” button after filling in the given form, in order to close the case.

2. Change “Status” of the current incident to the “Resolved”; select it from drop-down list in

Incident Management – Incident Request console. Then specify “Status Reason”; select one

from a drop-down list. Please, refer to the “Working with request tickets” section of the current

document for more details. Add description of solution which resolved the issue in the

“Resolution” field.

Page 30: Css eng r1

In most cases it is recommended to add, additional entry to Work Detail tab of the incident with View

Access* - Public prior to closing any case. Do so in order to notify the end-user that the case will be

closed. The given action is similar (from the end-user’s perspective) to filled “Summary” and “Notes”

fields from the first method.

Press the “Save” button to save and apply all changes.

End user will see that the case is closed in personal cabinet, and if the user agrees that the issue was

resolved he can press the “Accept” button in personal cabinet.

If the end-user does not accept that the incident was resolved he can press the “Decline” button in the

personal cabinet and enter comment. In such cases incident will be returned back to original queue.

In some cases it is necessary to close incident without possibility to reopen it. For example if the end-

user have specified incorrect e-mail during incident creation. Do the following:

- Notify the client that the incident will be closed, explain the reason. Suggest creating a new case, if the

end-user is willing to return to the issue in question later.

- Assign “Closed” status to the incident (select this option from a drop-down list next to “Status” field).

Select “Status Reason” from a drop-down list. Please refer to the “Working with request tickets” section

of the given document for more details. In the “Resolution” field enter reason to close the case.

- Press the “Save” button in order to save and apply changes. Press the “Close” button to leave Incident

Management – Incident Request console.

It is not possible to add any information to the case which was successfully closed.

After closing any incident, i.e. assigning “Closed” or “Resolved” status, customer satisfaction survey may

be sent to the end-user.

The given data will be used by employers of the Kaspersky Lab ZAO to evaluate service level and

implement future improvements.

Page 31: Css eng r1

Search Incident.

In order to search incident select Incident Management – Search Incident option in the Overview

console.

The following console will appear in result:

In order to search any incident one or several parameters should be defined; then press the “Search”

button.

Additional options related to parameters displayed in the personal cabinet to end-user, such as

customer External Request ID is available if you open hyperlink to the right of the Incident ID field.

Page 32: Css eng r1

Options related to parameters displayed in the personal cabinet to end-user:

External Request ID – ID of request displayed to the end-user in personal cabinet (differs from ID

displayed in the CSS Remedy).

Company – Company of client specified in the personal cabinet.

Search results will be displayed in the top part of the Incident Management – Incident Request console.

If necessary found cases may be opened directly from the Incident Management – Incident Request

console by double left mouse button click.

Page 33: Css eng r1

Logging out from the system.

In order to Log out from the CSS Remedy request tracking system press the “Logout” hyperlink in the

Incident Management console or Overview console.