Зміст
(Б-13) Сервіс «Громадський бюджет» : РЕГЛАМЕНТ ВЗАЄМОДІЇ СЛУЖБИ ПІДТРИМКИ КОРИСТУВАЧІВ ТА КОРИСТУВАЧІВ ІТ-СИСТЕМИ ЗАМОВНИКА
ГОЛОВНА СТОРІНКА ГРОМАДСЬКОГО БЮДЖЕТУ
РЕГЛАМЕНТ ВЗАЄМОДІЇ СЛУЖБИ ПІДТРИМКИ КОРИСТУВАЧІВ
ТА КОРИСТУВАЧІВ ІТ-СИСТЕМИ ЗАМОВНИКА
Зміст
1. ТЕРМІНИ. 2
2. ЗАГАЛЬНІ ПОЛОЖЕННЯ. 3
3. РІВЕНЬ ПІДТРИМКИ, РЕГЛАМЕНТ НАДАННЯ, ОБМЕЖЕННЯ ТА ПОКАЗНИКИ ЯКОСТІ ПОСЛУГИ (SLA) 3
4. ОПИС ТИПІВ ЗВЕРНЕНЬ ТА ПРИОРІТЕТІВ. 5
5. ПОРЯДОК ПОДАННЯ ТА ОБРОБКИ ЗВЕРНЕНЬ В СЛУЖБУ ПІДТРИМКИ КОРИСТУВАЧІВ. 6
6. ПРОЦЕС КОМУНІКАЦІЇ ПО ВИКОНАННЮ ЗАДАЧ (ЕСКАЛАЦІЇ ЗАДАЧ) 7
6.1. Для відповідального співробітника підтримки користувачів першої лінії підтримки: 8
6.2. Для відповідального співробітника другої лінії підтримки користувачів: 8
6.3. Для відповідального співробітника служби технічного супроводу Системи: 8
6.4. Можливість використання інших каналів зв’язку для комунікацій при ескалації задачі 9
7. ОЦІНКА ЯКОСТІ РОБОТИ СЛУЖБИ ТЕХНІЧНОЇ ПІДТРИМКИ. 9
1. ТЕРМІНИ
Назва терміну | Визначення терміну |
---|---|
Запит на обслуговування | Звернення, що потрапляє в службу підтримки користувачів у рамках нормального функціонування сервісу для виконання робіт у рамках пропонованого сервісу |
Консультація | Комунікація із замовником в письмовій, усній або демонстративній формі з метою пояснення ситуацій і рішення пов'язаних з ними проблем. |
Помилка (Bug) | Звернення Замовника, яке описує некоректну або несподівану поведінку системи з причини помилок на рівні програмного коду. |
Послуга | Сервіс, що отримує Замовник використовуючи ІТ-Систему |
Узгоджений час надання послуги | Узгоджений проміжок часу, коли ІТ-Система має бути доступною. |
Плановий простій | Заздалегідь узгоджений проміжок часу недоступності Послуги, який використовується для технічного обслуговування, оновлення версій або тестування |
Аварійний простій | Проміжок часу, необхідний для виконання аварійних робіт з метою відновлення надання Послуги після припинення її надання внаслідок настання Аварії |
Періодичність виконання планових робіт | Максимальна кількість планових робіт за проміжок часу |
Час реакції на звернення | Максимальний період часу з моменту реєстрації до моменту початку виконання звернення та інформування Замовника чи відповідного(-их) користувача(-ів) Послуги про призначення відповідального за розгляд звернення співробітника |
Година | У цьому документі годиною називається робоча година, якщо явно не вказане інше |
День | У цьому документі днем називається робочий день, якщо явно не вказане інше |
Запит на зміну (Request for Changes) | Звернення Замовника із запитом про проведення додаткових робіт, необхідних для зміни поточної конфігурації системи з метою внесення змін до процесів Замовника |
Ескалація | Процедура передачі запиту або інциденту на більш високий рівень підтримки у разі, якщо його не вдалося вирішити на поточному рівні |
Портал самообслуговування | Портал самообслуговування призначений для самостійної реєстрації звернень в Службу підтримки користувачів, а також оперативного отримання відповідей на актуальні питання. Портал є альтернативою реєстрації звернення по телефону або за допомогою повідомлень електронної пошти. Використання порталу самообслуговування дозволяє не тільки фіксувати і передавати запити в сервісну службу, але також і відстежувати виконання технічними фахівцями Розробника роботи за зверненнями. |
Замовник | Підприємство або партнер Компанії, який отримує послуги підтримки користувачів від Виконавця |
Розробник | Підприємство, що надає послуги Замовнику по технічному супроводу ІТ-Системи. |
SLA | Service Level Agreement Угода про рівень сервісу |
Тікет | Письмове звернення Користувача Системи в службу підтримки користувачів по будь-якому питанню чи проблемі. У тікет-системі зберігається вся історія спілкування між Користувачем і спеціалістами Служби підтримки користувачів. |
Тікет-система | Спеціальний модуль системи баг-трекінгу, за допомогою якого здійснюється взаємодія між Користувачами та фахівцями Служби підтримки користувачів. |
2. ЗАГАЛЬНІ ПОЛОЖЕННЯ
Регламент призначений для управління зверненнями, що надходять в Службу підтримки користувачів Компанії (далі Виконавець) від Користувачів ІТ-Системи або Замовника. У цьому документі регламентований процес взаємодії між Службою підтримки користувачів Виконавця та користувачами ІТ-Системи Замовника на підставі зон відповідальності і термінів реакції та усунення інцидентів і запитів. При отриманні повідомлення про будь-яку проблему співробітник Служби підтримки користувачів зобов'язаний виконати наступне:
- Відреагувати на запит Користувача в регламентний час;
- Виконати класифікацію запита та визначити зону відповідальності;
- Дати відповідь Користувачу, повідомивши номер тікету;
- Якщо потрібно - уточнити інформацію по запиту;
- Розв'язати проблему в регламентований термін.
2.1. Типи звернень Користувачів в підтримку:
- Помилка, проблемна ситуація, пов’язана з експлуатацією ІТ-Системи - звернення, що поступає в Службу підтримки користувачів у рамках нормального функціонування Системи для виконання робіт у рамках пропонованого сервісу.
- Відмова або Недолік – звернення Замовника, яке описує некоректну або несподівану поведінку системи із-за помилок на рівні програмного коду.
- Побажання щодо розвитку Системи - звернення Користувачів із запитом про проведення додаткових робіт, необхідних для зміни поточної конфігурації системи з метою внесення змін до процесів Замовника.
- Консультація - комунікація із замовником в письмовій, усній або демонстративній формі з метою пояснення ситуацій і рішення пов'язаних з ними проблем.
Звернення Користувача може бути зареєстроване одним з наступних способів:
- отримано при самостійній реєстрації звернення Користувачем на порталі самообслуговування (переважний спосіб);
- створено автоматично при відправці електронного повідомлення на визначену адресу …<@itsup.kiev.ua>;
- створено вручну співробітником Служби підтримки користувачів в результаті телефонної розмови з Користувачем або Замовником при використанні інших каналів зв'язку, у разі коли Користувач не має змоги створити звернення самостійно. Контактний номер телефону з питань підтримки даного продукту 044 …
3. РІВЕНЬ ПІДТРИМКИ, РЕГЛАМЕНТ НАДАННЯ, ОБМЕЖЕННЯ ТА ПОКАЗНИКИ ЯКОСТІ ПОСЛУГИ (SLA)
3.1. Регламент надання Послуги та технологічні обмеження Послуги.
Показник | Значення |
Узгоджений час надання Послуги | 9х5 (робочий час по робочих днях відповідно до чинного законодавства України) |
Час найменшого навантаження (для проведення планових робіт) | 19:00 – 08:00 |
Перша лінія підтримки | Експерти здійснюють прийом і реєстрацію звернень Послуги: - за телефоном: ? - по електронній пошті: ? - через сайт: ? |
Графік підтримки Послуги | Прийом та реєстрація звернень – 9х5 Вирішення інцидентів та виконання звернень – 9х5 |
Максимальна кількість користувачів Послуги | Вказати за необхідністю |
Максимальний обсяг інформації, що зберігається в БД | Вказати за необхідністю |
Перелік користувачів Замовника | Вказати за необхідністю, для обмеження прийому звернень тільки від дозволених користувачів |
Розробник забезпечує дотримання наступних показників рівня підтримки Послуги в рамках технологічних обмежень, вказаних в п.3.1 згідно регламенту надання Послуги:
3.2. Терміни реакції та вирішення запитів
У цьому розділі описані терміни реакції Служби підтримки користувачів на звернення від Користувачів, терміни виконання задач\запитів.
Термін реакції - час, за який Служба підтримки користувачів зобов'язана відреагувати на запит\задачу залежно від типу звернення, тобто надати зворотний зв'язок за запитом або прийняти завдання в роботу.
Терміни усунення\виконання - час, за який Служба підтримки користувачів зобов'язана усунути інцидент або передати завдання в інший підрозділ для виконання доопрацювання, надання консультації або усунення помилки і за фактом виконання завдання повідомити Заявника.
Терміни можуть коригуватися залежно від блокуючих чинників або пріоритету запиту.
Тип запиту | Тип звернення | Пріоритет | Початкова відповідь | Термін усунення\ виконання | |
Помилка, проблемна ситуація, пов’язана з експлуатацією ІТ-Системи | Звернення Користувача щодо Помилок та проблемних ситуацій, пов’язаних з експлуатацією Системи | Критичний | 30 хв | 2 години | |
Високий | 1 година | 8 годин | |||
Низький | 2 години | 2 доби | |||
Відмова або Недолік | Звернення Користувача щодо Відмови або Недоліку | Звернення фіксуються, після чого формується Запит щодо усунення Відмови або Недоліку засобами третьої лінії технічного супроводження Системи (якщо така передбачена для відповідної ІТ-Системи), або формується Запит Замовнику протягом: | |||
Критичний | 30 хв | ||||
Високий | 1 година | ||||
Низький | 2 години | ||||
Побажання щодо розвитку Системи (Запит на зміну) | Звернення Користувача щодо розвитку Системи | Фіксуються, після чого формується Запит щодо реалізації пропозицій Користувачів Замовнику протягом 16 годин | |||
Консультація | Інформаційні запити щодо змісту, по функціональності Системи і т.і. | Критичний[AP1] | 30 хв | 2 години | |
Високий | 1 година | 8 годин | |||
Низький | 2 години | 2 доби |
3.3. Порядок проведення планових та аварійних робіт стосовно ІТ-Системи
Планові регламентні роботи на апаратному та програмному забезпеченні ІТ-Системи, які можуть призвести до повної або часткової недоступності Системи, проводяться Виконавцем виключно в час найменшого навантаження за умови погодження із Замовником.
Дії Виконавця при виконанні планових робіт, які можуть призвести до повної або часткової недоступності Системи, повинні відбуватися у наступному порядку:
- Планування робіт.
- Погодження з Замовником часу початку та тривалості робіт.
- Оформлення заявки типу «Зміна» в системі Виконавця.
- Виконання регламентних робіт.
- Інформування Замовника про час відновлення доступності ІТ-Системи та результати проведення робіт, якщо такі роботи пов’язані із внесенням змін до ІТ-Системи.
Аварійні роботи на будь-яких компонентах ІТ-Системи проводяться Виконавцем з часу визначення причини Аварії до повного її усунення без погодження з Замовником.
4. ОПИС ТИПІВ ЗВЕРНЕНЬ ТА ПРИОРІТЕТІВ
Усі звернення, які фіксуються в тікет-системі Замовника або Виконавця поділяються на 4 основні типи. У кожного з типів є своя внутрішня категорія.
Тип звернення - атрибут запиту, який використовується для розрізнення запитів, що поступають в Службу підтримки користувачів.
Категорія - внутрішній атрибут запиту, який використовується для розмежування завдань за конкретним типом, виходячи із складності, глобальності і пріоритету звернення.
Визначення типів звернень вказано в розділі 2. Загальні положення цього Регламенту.
- Помилка, проблемна ситуація, пов’язана з експлуатацією ІТ-Системи - звернення, що поступає в Службу підтримки користувачів у рамках нормального функціонування Системи для виконання робіт у рамках пропонованого сервісу.
- Відмова або Недолік – звернення Замовника, яке описує некоректну або несподівану поведінку системи із-за помилок на рівні програмного коду.
- Побажання щодо розвитку Системи - звернення Користувачів із запитом про проведення додаткових робіт, необхідних для зміни поточної конфігурації системи з метою внесення змін до процесів Замовника.
- Консультація - комунікація із замовником в письмовій, усній або демонстративній формі з метою пояснення ситуацій і рішення пов'язаних з ними проблем.
Опис категорій:
В Помилках, проблемних ситуаціях, пов’язаних з експлуатацією ІТ-Системи та Відмовах і Недоліках існують три категорії, які базуються на критичності реалізації основних бізнес-процесів Замовника:
- Пріоритет «Критичний» – необхідність негайного виконання дій, пов'язана з неможливістю реалізації процесів, що виконуються Замовником. Звернення описує:
- блокування взаємодії користувача з системою;
- невиконання основних функцій системи;
- збої;
- втрати даних;
- порушення логіки роботи;
- інші подібні моменти пов'язані з порушенням виконання основних функцій системи
Прикладом такої помилки може бути некоректна робота пошуку по сторінці - видає некоректні результати; втрата інформації при збереженні форми та інше.
- Пріоритет «Високий» – запит на виконання дій в Системі, що потребують прискореного виконання для своєчасного виконання процесів Замовника. Звернення описує:
- незручності в роботі системи;
- неможливістю виконання системою деяких функцій.
- інші подібні моменти, які не пов'язані з порушенням основних функцій системи, але надають незручності в роботі.
Прикладом такої помилки може бути неможливість переглянути заповнену форму після її редагування без перелогіна в систему.
- Пріоритет «Низький» - помилки, які мають низький пріоритет та ніяк не впливають на виконання основних чи вторинних процесів Замовника, не впливає на працездатність системи. Звернення описує:
- незначні незручності;
- дрібні недоробки;
- інші подібні моменти, які ніяк не впливають на виконання системою основних функцій.
При неможливості вирішити питання самостійно – Служба підтримки користувачів формує запит на 3 лінію підтримки - технічне супроводження Системи.
Консультація, має три категорії звернення, які ґрунтуються на важливості її надання Замовнику:
- Пріоритет «Критичний» - Критична консультація - описує необхідність надати консультацію Замовнику, надання якої блокує виконання основних бізнес процесів. Наприклад, консультація по додаванню нового поля у форму, без якого не можна створювати картки жителів.
- Пріоритет «Високий» - Важлива консультація - описує необхідність надання консультації Замовнику, для усунення некоректної взаємодії користувача з системою. Наприклад, консультація, як коректно редагувати форму без її перестворення.
- Пріоритет «Низький» - Консультація з низькою критичністю - описує необхідність надати консультацію Замовнику з некритичних питань і функціонала. Наприклад, консультація з питань роботи фільтрів вибірки пошуку сторінки.
Побажання щодо розвитку Системи не поділяються на категорії. Дані звернення фіксуються, після чого формується Запит щодо реалізації пропозицій Користувачів Замовнику.
5. ПОРЯДОК ПОДАННЯ ТА ОБРОБКИ ЗВЕРНЕНЬ В СЛУЖБУ ПІДТРИМКИ КОРИСТУВАЧІВ
5.1. Основою для виконання робіт є звернення Користувача ІТ-Системи або Замовника. Робота із зверненнями ведеться в спеціальному розділі технічної підтримки продукту в тікет-системі Замовника або Виконавця. Звернення може бути створене будь-яким з перерахованих способів:
- з використанням форми реєстрації звернення Користувача на порталі самообслуговування (переважний спосіб);
- з використанням відправки e-mail повідомлення на адресу …@itsup.kiev.ua;
- створено вручну співробітником Служби підтримки користувачів в результаті телефонної розмови з Користувачем або при використанні інших каналів зв'язку, у разі коли Користувач не має змоги створити звернення самостійно.
5.2. У зверненні мають бути точно та докладно сформульовані питання, що вимагають роз'яснення, і описані проблеми, що вимагають рішення. Для оперативного вирішення питань, звернення повинне включати наступну інформацію:
- Опис проблеми і покроковий опис дій з відтворення проблеми (по можливості).
- Питання бажано ставити використовуючи термінологію, прийняту в продукті.
- Адреса сайту, на якому спостерігається проблема.
- Номер використовуваної версії програмного продукту і браузеру.
- Додатково, службою підтримки користувачів може бути запрошена інформація по налаштуваннях ПЗ, використовуваним версіям і налаштуванням Користувацького ПЗ.
5.3. На кожен лист або звернення, створене на сайті і прийняте Службою підтримки користувачів, автоматично генерується і висилається на адресу користувача лист з підтвердженням про прийняту проблему.
5.4. При отриманні звернення до Служби підтримки користувачів, користувач отримує повідомлення про початок її обробки і вказаному зверненню привласнюється унікальний ідентифікатор. Ідентифікатор необхідно зберігати в заголовку листа під час подальшого листування із Службою підтримки користувачів з цього питання. На підставі ідентифікатора листи автоматично додаються до початкового звернення. Повний зміст листування може бути проглянутий користувачем на сайті у порталі самообслуговування.
5.5. Підтримка користувачів НЕ надається по інших каналах (наприклад, Viber, Skype, GoogleTalk, Telegram). Питання, задані по цих каналах не є офіційними зверненнями і не реєструються в тікет-системі. Подібні засоби зв'язку розглядаються тільки як засоби спілкування і загальних консультацій.
5.6. При створенні звернення або при відправці звернення по електронній пошті можна включати скріншоти і графічні пояснення, які можуть допомогти у вирішенні проблеми. Скріншоти мають бути підготовлені у форматах: JPG, GIF, PNG. У разі використання скріншотів у форматах BMP слід їх заздалегідь запакувати з використанням програми архіватора (RAR, ZIP).
5.7. При поданні запиту по E-mail, звернення повинне містити коректну інформацію про зареєстрованого користувача продукту: адреса електронної пошти, логін в системі і ПІБ, контактний номер телефону. Вказана інформація використовується для однозначної ідентифікації користувача і привласнення відповідного рівня обслуговування (SLA).
5.8. Відповіді на стандартні, або такі що часто задаються питання, можуть бути дані у вигляді посилань на відповідну сторінку онлайнової документації по продукту, на скачування керівництва по продукту, на обговорення у форумі або розділ FAQ, сайти розробників програмного забезпечення.
5.9. Вирішення питань звернення може бути відкладене або навіть неможливе з наступних причин:
- Неможливо повторити описану проблему на аналогічній конфігурації устаткування і відсутній доступ до проекту користувача;
- Користувач не може надати достатньо інформації для вирішення проблеми;
- Питання вимагає детальної діагностики, доопрацювання функціонала і/або випуску оновлення для програмного продукту;
- Користувач виконує дії порушуючи технічні вимоги по встановленню і використанню програмного продукту, внесені зміни в ядро продукту, перевищена кількість дозволених установок програмного продукту і тому подібне;
- Питання виходить за рамки технічної підтримки користувачів;
- Питання поставлене некоректно або обговорення питання проводиться неконструктивно, і вирішення проблеми затягується із-за несвоєчасного надання інформації по зверненню.
5.10. У разі роботи по зверненню, відправленому по електронній пошті, можливе виникнення проблемних ситуацій з роботою сторонніх поштових сервісів або спам-фильтрів. Проблема вважається прийнятою, тільки якщо Ви отримали лист про реєстрацію з унікальним номером тікету. Це означає, що лист пройшов перевірку на антіспам і був зареєстрований в тікет-системі підтримки. У разі виникнення проблем з доставкою поштових повідомлень рекомендується перенести рішення проблем на веб портал Служби підтримки користувачів (Портал самооблуговування) і робити відправку повідомлень та контроль відповідей через інтерфейс Служби підтримки користувачів.
6. ПРОЦЕС КОМУНІКАЦІЇ ПО ВИКОНАННЮ ЗАДАЧ (ЕСКАЛАЦІЇ ЗАДАЧ)
Ескалація задач відбувається шляхом передачі задачі (або підзадачі) відповідальному співробітнику наступної лінії технічної підтримки (або співробітнику технічного супроводження Системи).
Алгоритм ескалації задач
6.1. Для відповідального співробітника підтримки користувачів першої лінії підтримки:
1. Актуалізувати задачу: 1.1. Встановити відповідний пріоритет. За умовчанням повинен бути виставлений середній пріоритет. 1.2. Актуалізуати поля в задачі: 1.2.1. Внести всю необхідну інформацію в опис; 1.2.2. Зазначити дії, що були зроблені по задачі; 1.2.3. Вказати додаткову інформацію по задачі. 2. Призначити задачу відповідальному користувачу другої лінії підтримки користувачів в тікет-системі. 3. Отримати зворотній зв’язок від спеціаліста другої лінії підтримки користувачів по реакції на задачу у відповідності до регламентних строків – упевнитись, що задача прийнята до роботи. 3.1. При необхідності проконсультувати співробітника другої лінії підтримки користувачів, уточнити необхідну інформацію. 3.2. У випадку, якщо немає реакції в регламентний час – зв’язатись з відповідальним співробітником по телефону та уточнити причини затримки. 4. Отримати задачу після її виконання спеціалістом другої лінії підтримки користувачів для отримання зворотного зв’язку від Замовника про коректність її виконання. 4.1. При некоректному виконанні задачі – повторно відправити на відповідального користувача.
6.2. Для відповідального співробітника другої лінії підтримки користувачів:
1. Відреагувати на отриману задачу, що отримана від першої лінії підтримки користувачів, та прийняти її до роботи в регламентний час.
1.1. При необхідності уточнити деталі або повернути задачу на перший рівень підтримки користувачів.
2. Виконати задачу в регламентний час.
2.1. При невиконанні регламентних термінів – повідомити співробітника першої лінії підтримки користувачів у вигляді коментаря до задачі або за допомогою інших каналів зв’язку.
2.2. Описати резолюцію.
2.3. Переконатись, що задача виконана коректно.
3. Якщо задача не може бути виконана силами спеціалістів другої лінії підтримки користувачів необхідно актуалізувати задачу для передачі її до організації, що займається технічним супроводом Системи (третя лінія підтримки), або, якщо дана організація відсутня - Замовнику:
3.1. Встановити відповідний пріоритет. За умовчанням повинен бути виставлений середній пріоритет.
3.2. Актуалізуати поля в задачі:
3.2.1. Внести всю необхідну інформацію в опис;
3.2.2. Зазначити дії, що були зроблені по задачі;
3.2.3. Вказати додаткову інформацію по задачі.
4. Призначити задачу відповідальному користувачу служби технічного супроводу Системи.
5. Отримати зворотній зв’язок від спеціаліста третьої лінії служби технічного супроводу Системи по реакції на задачу у відповідності до регламентних строків – упевнитись, що задача прийнята до роботи.
5.1. При необхідності проконсультувати співробітника третьої лінії технічної підтримки - технічного супроводу Системи, уточнити необхідну інформацію.
5.2. У випадку, якщо немає реакції в регламентний час – зв’язатись з відповідальним співробітником по телефону та уточнити причини затримки.
6. Отримати задачу після її виконання спеціалістом третьої лінії технічної підтримки - технічного супроводу Системи для отримання зворотного зв’язку від Замовника про коректність її виконання.
6.1. При некоректному виконанні задачі – повторно відправити на відповідального користувача.
7. Передати задачу відповідальному співробітнику першої лінії підтримки користувачів і, при необхідності, надати йому зворотній зв’язок або консультацію.
6.3. Для відповідального співробітника служби технічного супроводу Системи:
1. Відреагувати на отриману задачу та прийняти її до роботи в регламентний час.
1.1. При необхідності уточнити деталі або повернути задачу на другий рівень підтримки користувачів.
2. Виконати задачу в регламентний час.
2.1. При невиконанні регламентних термінів – повідомити співробітника підтримки користувачів нижчого рівня у вигляді коментаря до задачі або за допомогою інших каналів зв’язку.
2.2. Описати резолюцію.
2.3. Переконатись, що задача виконана коректно.
3. Передати задачу відповідальному співробітнику технічної підтримки другого рівня і, при необхідності, надати зворотній зв’язок або консультацію.
6.4. Можливість використання інших каналів зв’язку для комунікацій при ескалації задачі
1. Телефон:
1.1. При аваріях з високим пріоритетом, які повністю блокують виконання основний бізнес процесів Замовника або інших подібних випадках та вони повинні бути виконані в найшвидші терміни.
1.2. При невиконанні регламентних строків реакції і виконання задач.
1.3. При необхідності отримання консультації по нетривіальним задачам, опису яких немає в БЗ і які мають високий пріоритет.
2. Електронна пошта:
2.1. Інформування колег.
2.2. Комунікація з питань оптимізації взаємодії.
7. ОЦІНКА ЯКОСТІ РОБОТИ СЛУЖБИ ТЕХНІЧНОЇ ПІДТРИМКИ
Наша Компанія приділяє велику увагу якості роботи служби підтримки користувачів та забезпеченню високого рівня обслуговування всіх категорій користувачів програмного продукту. Після вирішення звернення, ми просимо Вас проголосувати в зверненні поставивши рівень оцінки якості виконання (за п'ятибальною шкалою). Якщо звернення закрито на Вашу думку раніше, ви можете відкрити це ж звернення повторно і уточнити питання. Також Ви можете надіслати листа керівнику Служби підтримки користувачів (____@_____.ua) з проханням прокоментувати або сприяти у прискоренні вирішення екстрених питань.
[AP1]А нужен ли тут критичный уровень?