1. Working in the CSS request tracking
system.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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:

17.  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.

18. “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.

19. 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.

20. 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”:

21. 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.

22. 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.

23. 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 -

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29.  “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.

30. 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.

31. 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.

32. 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.

33. 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.