В даному документі регламентовано процес взаємодії за допомогою каналів зв’язку між службою підтримки користувачів (друга лінія) та службою технічного супроводу Системи або Замовником (якщо служба технічного супроводу Системи не передбачена). Регламент призначений для управління заявками, що:

• формуються в Службі підтримки користувачів Системи (далі Підтримка) від Користувачів ІТ-Системи або Замовника;
• сервісних та регламентних робіт, що плануються для виконання Службою підтримки користувачів та Службою технічного супроводу Системи.

Регламентований процес взаємодії на підставі зон відповідальності і термінів реакції та усунення інцидентів та запитів.
2.1. Зони відповідальності Таб.1. Зони відповідальності

2.2. Типи заявок:

• Відмова або Недолік – заявка, що описує некоректну або несподівану поведінку системи із-за помилок на рівні програмного коду.
• Побажання щодо розвитку Системи - звернення Користувачів або Замовника із запитом про проведення додаткових робіт, необхідних для зміни поточної конфігурації системи з метою внесення змін до процесів Замовника.
• Консультація - комунікація між учасниками взаємодії в письмовій, усній або демонстративній формі з метою пояснення ситуацій і рішення пов'язаних з ними проблем.
• Планові або регламентні роботи – періодичні роботи, що проводяться в Системі за визначеним графіком.

2.3. Канали комунікації Канали комунікації – засоби передачі інформації, по яким повинна проходити комунікація з робочих питань між підрозділами. Офіційні канали зв’язку по яким повинна проводитись комунікація приведені в Таблиці 2. Таб.2. Канали комунікації

Основним каналом комунікації є система обліку заявок (тікет-система). Комунікація повинна відбуватись в тікет-системі шляхом делегування задач або їх коментування. Детальніше про процес комунікації у розділі 6 даного документа.

3.1. Регламент надання Послуги та технологічні обмеження Послуги.

3.2. Терміни реакції та вирішення  заявок У цьому розділі описані терміни реакції Служби технічного супроводу на заявки від Служби підтримки користувачів, що делегуються на них. Термін реакції - час, за який Служба технічного супроводу зобов'язана відреагувати на запит\задачу залежно від типу заявки, тобто надати зворотний зв'язок за запитом або прийняти завдання в роботу. Терміни усунення\виконання - час, за який Служба технічного супроводу зобов'язана усунути інцидент або реалізувати виконання доопрацювання, надання консультації або усунення помилки і за фактом виконання завдання повідомити Заявника. Терміни можуть коригуватися залежно від блокуючих чинників або пріоритету запиту. Таб.3. Строки реакції та усунення\виконання.

3.3. Порядок проведення планових та аварійних робіт стосовно ІТ-Системи Планові регламентні роботи на апаратному та програмному забезпеченні ІТ-Системи, які можуть призвести до повної або часткової недоступності Системи, проводяться Службою підтримки користувачів або Службою технічного супроводу (Виконавець робіт) виключно в час найменшого навантаження за умови погодження із Замовником. Дії Виконавця робіт при виконанні планових робіт, які можуть призвести до повної або часткової недоступності Системи, повинні відбуватися у наступному порядку:

• Планування робіт.
• Погодження з Замовником часу початку та тривалості робіт.
• Оформлення заявки типу «Зміна» в системі реєстрації заявок (тікет-системі).
• Виконання регламентних робіт.
• Інформування Замовника про час відновлення доступності ІТ-Системи та результати проведення робіт, якщо такі роботи пов’язані із внесенням змін до ІТ-Системи.

Аварійні роботи на будь-яких компонентах ІТ-Системи проводяться Виконавцем робіт з часу визначення причини Аварії до повного її усунення без погодження з Замовником.

Усі звернення, які фіксуються в тікет-системі поділяються на 3 основні типи. У кожного з типів є своя внутрішня категорія. Тип звернення - атрибут запиту, який використовується для розрізнення запитів, що поступають в Службу підтримки користувачів. Категорія - внутрішній атрибут запиту, який використовується для розмежування завдань за конкретним типом, виходячи із складності, глобальності і пріоритету звернення. Визначення типів звернень вказано в розділі 2. Загальні положення цього Регламенту.

• Відмова або Недолік – заявка служби підтримки користувачів, яке описує некоректну або несподівану поведінку системи з причини помилок на рівні програмного коду.
• Побажання щодо розвитку Системи - звернення Користувачів або Замовника із запитом про проведення додаткових робіт, необхідних для зміни поточної конфігурації системи з метою внесення змін до процесів Замовника.
• Консультація - комунікація із Замовником або Службою підтримки користувачів в письмовій, усній або демонстративній формі з метою пояснення ситуацій і рішення пов'язаних з ними проблем.

Опис категорій: В Відмовах і Недоліках існують три категорії, які базуються на критичності реалізації основних бізнес-процесів Замовника:

• Пріоритет «Критичний» – необхідність негайного виконання дій, пов'язана з неможливістю реалізації процесів, що виконуються Замовником. Звернення описує:
  • блокування взаємодії користувача з системою;
  • невиконання основних функцій системи;
  • збої;
  • втрати даних;
  • порушення логіки роботи;
  • інші подібні моменти пов'язані з порушенням виконання основних функцій системи

Прикладом такої відмови може бути некоректна робота пошуку по сторінці - видає некоректні результати; втрата інформації при збереженні форми та інше.

• Пріоритет «Високий» – запит на виконання дій в Системі, що потребують прискореного виконання для своєчасного виконання процесів Замовника. Звернення описує:
• незручності в роботі системи;
• неможливістю виконання системою деяких функцій.
• інші подібні моменти, які не пов'язані з порушенням основних функцій системи, але надають незручності в роботі.

Прикладом такої помилки може бути неможливість переглянути заповнену форму після її редагування без перелогіна в систему.

• Пріоритет «Низький» - помилки, які мають низький пріоритет та ніяк не впливають на виконання основних чи вторинних процесів Замовника, не впливає на працездатність системи. Звернення описує:
• незначні незручності;
• дрібні недоробки;
• інші подібні моменти, які ніяк не впливають на виконання системою основних функцій.

Консультація, має три категорії звернення, які ґрунтуються на важливості її надання Замовнику:

• Пріоритет «Критичний» - Критична консультація - описує необхідність надати консультацію Службі підтримки користувачів, надання якої блокує виконання основних бізнес процесів. Наприклад, консультація по додаванню нового поля у форму, без якого не можна створювати картки жителів.
• Пріоритет «Високий» - Важлива консультація - описує необхідність надання консультації Службі підтримки користувачів, для усунення некоректної взаємодії користувача з системою. Наприклад, консультація, як коректного редагування форми без її перестворення.
• Пріоритет «Низький» - Консультація з низькою критичністю - описує необхідність надати консультацію Службі підтримки користувачів з некритичних питань і функціонала. Наприклад, консультація з питань роботи фільтрів вибірки пошуку сторінки.

 Побажання щодо розвитку Системи не поділяються на категорії. Дані звернення фіксуються, після чого формується Запит щодо реалізації пропозицій Користувачів Замовнику.

5.1. Основою для виконання робіт є заявка Служби підтримки користувачів Системи або Замовника. Робота з заявками ведеться в спеціальному розділі технічної підтримки продукту в тікет-системі Замовника або Виконавця. Звернення може бути створене будь-яким з перерахованих способів:

• В тікет-системі Замовника, Служби підтримки користувачів або Служби технічного супроводу Системи;
• З використанням відправки e-mail повідомлення на адресу Служби технічного супроводу Системи;

5.2. У заявці мають бути точно та докладно сформульовані питання, що вимагають роз'яснення, і описані проблеми, що вимагають рішення. Для оперативного вирішення питань, заявка повинна включати наступну інформацію:  

• Опис проблеми і покроковий опис дій з відтворення проблеми (по можливості).
• Питання бажано ставити використовуючи термінологію, прийняту в продукті.
• Адреса сайту, на якому спостерігається проблема.
• Номер використовуваної версії програмного продукту і браузеру.
• Додатково, службою технічного супроводу може бути запрошена інформація по налаштуваннях ПЗ, використовуваним версіям і налаштуванням Користувацького ПЗ, системні логи ПЗ та інше.

5.3. Технічний супровід Системи НЕ ведеться по інших каналах (наприклад, Viber, Skype, GoogleTalk, Telegram). Питання, задані по цих каналах не є офіційними зверненнями і не реєструються в тікет-системі. Подібні засоби зв'язку розглядаються тільки як засоби спілкування і загальних консультацій.
5.4. При створенні звернення або при відправці звернення по електронній пошті можна включати скріншоти і графічні пояснення, які можуть допомогти у вирішенні проблеми. Скріншоти мають бути підготовлені у форматах: JPG, GIF, PNG. У разі використання скріншотів у форматах BMP слід їх заздалегідь запакувати з використанням програми архіватора (RAR, ZIP).
5.5. У якості додатків до Запитів можуть надаватися різноманітні матеріали: опис операційного системного середовища, інформація стосовно програмного забезпечення інших виробників, фрагменти вмісту відповідних log-файлів, інших системних файлів, метаданих, копії екранів персональних комп’ютерів користувачів та інше, що можуть свідчити або надати інформацію стосовно Відмови, Недоліку або причин їх виникнення.
5.6. При поданні запиту по E-mail, звернення повинне містити коректну інформацію про зареєстрованого користувача продукту: адреса електронної пошти, логін в системі і ПІБ, контактний номер телефону. Вказана інформація використовується для однозначної ідентифікації користувача і привласнення відповідного рівня обслуговування.
5.7. Відповіді на стандартні, або такі що часто задаються питання, можуть бути дані у вигляді посилань на відповідну сторінку онлайнової документації по продукту, на скачування керівництва по продукту, на обговорення у форумі або розділ FAQ, сайти розробників програмного забезпечення. 
5.8. Вирішення питань звернення може бути відкладене або навіть неможливе з наступних причин:

• Неможливо повторити описану проблему на аналогічній конфігурації устаткування і відсутній доступ до проекту користувача;
• Служба підтримки користувачів не може надати достатньо інформації для вирішення проблеми;
• Питання вимагає детальної діагностики, доопрацювання функціонала і/або випуску оновлення для програмного продукту;
• Користувач виконує дії порушуючи технічні вимоги по встановленню і використанню програмного продукту, внесені зміни в ядро продукту, перевищена кількість дозволених установок програмного продукту і тому подібне;
• Питання виходить за рамки технічного супроводження Системи;
• Питання поставлене некоректно або обговорення питання проводиться неконструктивно, і вирішення проблеми затягується із-за несвоєчасного надання інформації по зверненню.

Ескалація задач відбувається шляхом передачі задачі (або підзадачі) зі Служби підтримки користувачів до Служби технічного супроводження Системи (або у випадку її відсутності – Замовнику).
Алгоритм ескалації задач = 6.1. Для відповідального співробітника другої лінії підтримки користувачів: = 1.     Якщо задача не може бути виконана силами спеціалістів другої лінії підтримки користувачів необхідно актуалізувати задачу для передачі її до організації, що займається технічним супроводом Системи (третя лінія підтримки), або, якщо дана організація відсутня - Замовнику: 1.1. Встановити відповідний пріоритет. За умовчанням повинен бути виставлений середній пріоритет. 1.2. Актуалізувати поля в задачі: 3.2.1. Внести всю необхідну інформацію в опис; 3.2.2. Зазначити дії, що були зроблені по задачі; 3.2.3. Вказати додаткову інформацію по задачі. 2.     Призначити задачу відповідальному користувачу служби технічного супроводу Системи. 3.     Отримати зворотній зв’язок від спеціаліста третьої лінії підтримки - служби технічного супроводу Системи по реакції на задачу у відповідності до регламентних строків – упевнитись, що задача прийнята до роботи. 3.1. При необхідності проконсультувати співробітника технічного супроводу Системи, уточнити необхідну інформацію. 3.2. У випадку, якщо немає реакції в регламентний час – зв’язатись з відповідальним співробітником по телефону та уточнити причини затримки. 4.     Отримати задачу після її виконання спеціалістом технічного супроводу Системи для отримання зворотного зв’язку від Замовника про коректність її виконання. 4.1. При некоректному виконанні задачі – повторно відправити на відповідального користувача. 5.     Передати задачу відповідальному співробітнику першої лінії підтримки користувачів або Заявнику і, при необхідності, надати йому зворотній зв’язок або консультацію.
= 6.2. Для відповідального співробітника служби технічного супроводу Системи: = 1.     Відреагувати на отриману задачу та прийняти її до роботи в регламентний час. 1.1. При необхідності уточнити деталі або повернути задачу на другий рівень підтримки користувачів. 2.     Виконати задачу в регламентний час. 2.1. При невиконанні регламентних термінів – повідомити співробітника підтримки користувачів нижчого рівня у вигляді коментаря до задачі або за допомогою інших каналів зв’язку. 2.2. Описати резолюцію. 2.3. Переконатись, що задача виконана коректно. 3.     Передати задачу відповідальному співробітнику підтримки користувачів другого рівня і, при необхідності, надати зворотній зв’язок або консультацію.
= 6.3. Можливість використання інших каналів зв’язку для комунікацій при ескалації задачі = 1.     Телефон: 1.1. При аваріях з високим пріоритетом, які повністю блокують виконання основний бізнес процесів Замовника або інших подібних випадках та вони повинні бути виконані в найшвидші терміни. 1.2. При невиконанні регламентних строків реакції і виконання задач. 1.3. При необхідності отримання консультації по нетривіальним задачам, опису яких немає в БЗ і які мають високий пріоритет. 2.     Електронна пошта: 2.1. Інформування колег. 2.2. Комунікація з питань оптимізації взаємодії.