IT-адвокат Максим Носарєв написав для AIN.UA колонку про те, як правильно задокументувати роботу саппорта, щоб захистити свох інтереси і не втратити клієнта.
SLA (Service Level Agreement) потрібен IT-компаніям, які надають послуги саппорту своїм клієнтам. Він вносить ясність у ваші стосунки із замовником і захищає від непередбачених витрат. Клієнти часто запитують, чи є в нас якийсь темплейт контракту SLA, який вони могли б адаптувати під себе і спокійно за ним працювати. І відповідь тут однозначна — ні, такого темплейту немає і бути не може.
Адже в рамках цього контракту замовник і виконавець можуть домовитися буквально про будь-що: які послуги ви будете надавати, яким чином, як часто, як замовник це буде контролювати, які показники якості вашої роботи будуть застосовуватися і т.д. І все це визначається суто бізнес-процесами, вашими і ваших клієнтів.
І хоча ми не можемо дати вам шаблон такого контракту, у цій статті ділимося його структурою. Вона дасть вам розуміння, з яких пунктів має складатися SLA, аби убезпечити вас від більшості неприємних ситуацій в роботі з замовником саппорту.
Переваги укладення SLA при наданні послуг саппорту
SLA — це договір про рівень надання послуг між їх замовником і виконавцем. Характерні риси цього виду договору:
- описує не просто послугу, а і деталі її реалізації (час реакції на запит клієнта, час на вирішення проблемної ситуації тощо),
- кастомність — всі положення визначаються виключно бізнес-задачами і бізнес-процесами сторін.
Основні переваги укладення правильного, якісно розробленого, SLA:
1. Прозорість і однозначність у стосунках замовник-виконавець
Кожне положення SLA формулюється в результаті детального проговорення сторонами, хто чого хоче, і хто що може. Без цього ваш SLA — проста формальність, а не по-справжньому робочий інструмент.
Уявімо ситуацію: ви підписали формальний SLA, потихеньку саппортите клієнта. І тут вночі його мобільний додаток перестає приймати платежі! Вірніше, це у вас ніч, а у клієнта в Америці — розпал робочого дня. Клієнт вимагає термінового усунення проблеми. Ви шукаєте, хто з ваших працівників не спить і може з цим допомогти. Знаходите Андрія. Андрій приїжджає, дивиться і говорить, що сам він це зможе полагодити максимум годин через 6. Клієнт у розпачі і гніві!
І тут ви такі: а знаєте, взагалі-то в нашому договорі не вказано, що ми надаємо послуги цілодобово. А у вас, і правда, в договорі про час надання послуги взагалі нічого не вказано — ви були впевнені, що це означає “послуги тільки в робочий час”, а клієнт був впевнений, що це ж саме означає “надаємо послуги цілодобово”. Ніби ви і праві за договором. Але клієнта втратили.
2. Визначеність обов’язків обох сторін
Важливо, щоб замовник чітко розумів, яким чином і якої якості послуги ви будете надавати — і скільки це йому коштуватиме.
3. Захищає виконавця від нових, раптово виникаючих вимог до якості саппорту
Наприклад, ви домовилися, але не зафіксували контрактом, що на запити середнього рівня критичності будете реагувати протягом 5 годин. І тут раптово замовник вимагає,щоб ви все кинули і почали займатися його питанням як можна скоріше. Можливо, він забув чи зрозумів, що помилився, погоджуючись на ту умову. Але якщо це правило вашої співпраці не було зафіксовано контрактом, щось довести людині в стані стресу (бізнес стоїть) буде дуже складно. І завжди — не на користь собі.
4. Дає замовнику чітке розуміння, як швидко буде вирішено проблему — що дозволить і йому більш точно планувати власну діяльність. Все разом це помітно зменшує кількість приводів для незадоволення клієнта і конфліктів з ним.
Як бачите, якісний SLA можна розробити тільки у співпраці з клієнтом. Кожного разу вам потрібно занурюватися у продукт, який плануєте саппортити, у бізнес-процеси компанії замовника. Тільки так ви зможете максимально правильно передбачити кількість і якість проблем, що потенційно можуть виникати у вашого клієнта. І що не менш важливо — адекватно оцінити їх критичність та час, потрібний для усунення багів та інших неприємностей.
Обов’язкові пункти договору SLA
Не дивлячись на те, що кожен SLA — абсолютно унікальна історія, на практиці виробився перелік важливих положень цього договору, які можна використовувати як каркас, основу. Тому, якщо доведеться складати або вирішили передивитися ваш існуючий договір SLA, радимо включити в нього перераховані нижче питання.
1. Перелік послуг
В SLA цей пункт набуває особливого значення, його варто прописувати максимально детально. Завдяки цьому у замовника буде розуміння, що ви взагалі можете робити в рамках договору. Він буде чітко розуміти, з чим до вас можна звертатися, і з чим — не до вас взагалі. В той же час ви як виконавець будете мати однозначну відповідь на питання “на що ми взагалі підписуємося, що обіцяємо клієнту”.
З огляду на це в даному розділі доцільно також зробити глосарій — надати визначення основним термінам, які будете застосовувати в рамках співпраці (які проблеми вважати критичними, що входить в конкретну послугу і т.д.)
2. Рівні критичності запитів від клієнта
Найчастіше їх поділяють на: високий, середній і низький. Але у вас може бути і інша класифікація. Детально проговоріть, які проблеми до якого рівня варто віднести, і зафіксуйте це в контракті.
3. Час реакції виконавця на запит і час вирішення проблеми в залежності від рівня її критичності
Тобто, як швидко відреагували на те, що дізналися. І як швидко зобов’язуєтеся вирішити проблему після того, як про неї дізналися.
4. Що вважається результатом вирішення запиту клієнта
Це важливо для ситуацій, коли ви, наприклад, виправили непрацюючий вхід користувачів на сайті замовника, але цей процес триває 5 хвилин. Ви виправили? Так. Чи задоволений клієнт результатом? Навряд. Цей пункт зменшує кількість потенційно конфліктних ситуацій між вами і замовником. Звісно, неможливо передбачити все різноманіття проблемних ситуацій, що можуть виникати. Але є якісь очікування, важливі точки в роботі продукту клієнта — хоча б їх пропишіть детально.
5. Час надання послуг — коли і скільки
Це важливо узгодити і прописати, щоб замовник розумів, чи зможе він розраховувати умовно на підтримку о 3 годині ночі за українським часом, у вихідні і т.д.
6. Вартість послуг
Тут має бути детальна відповідь на питання, за що саме платить клієнт, і скільки. Варіанти і принципи способів оплати можуть бути найрізноманітніші. Наприклад, якщо ви здатні надавати послуги цілодобово, це коштує дорожче, ніж сервіс тільки у робочий час. Або, якщо клієнт готовий збільшити час очікування на вирішення некритичних запитів, вартість послуг можна зменшити (тільки у випадку збереження вигоди і для вас) і таке інше.
В цьому пункті також можна обрати і зафіксувати способи оплати ваших послуг. Це може бути абонентська плата, оплата витрачених ресурсів (людино-годин по суті) або інший спосіб розрахунку.
7. Метрики якості послуг
Їх важливо разом з клієнтом обрати і домовитися про те, як ви їх розумієте. Це дисциплінує вас як виконавця. А також дає можливість замовнику розуміти, ви працюєте добре чи не дуже — і таким чином вносить прозорість у ваші стосунки (що завжди вкрай важливо). Це можуть бути: час реакції на заявку, час на усунення проблеми, зменшення кількості багів протягом місяця і ще безліч параметрів, які ви можете визначити разом з клієнтами.
8. Перелік команди саппорта
Цей пункт не обов’язковий — часто замовнику все одно, хто буде лагодити поломки в його продукті. Але іноді буває, що клієнт хоче, аби з ним працювали конкретні спеціалісти. А у випадку, коли вони потрібні йому на фултайм, вже можуть з’являтися елементи контрактів dedicated team або оutstaff, і все, що з цього витікає (відпустки, лікарняні, способи заміни персоналу і т.д.).
9. Періодичність перегляду умов SLA
Часто на старті ви можете невірно оцінити потребу клієнта, доцільність тих чи інших умов договору або ж ці потреби можуть змінитися в результаті вашої роботи. Тому важливо періодично переглядати умови вашого договору.
Наприклад, замовник готовий платити більше за обслуговування в нічний час. Ви виділили команду, яка чергує вночі — відповідно платите їм більше. Але за 3 місяці жодного запиту від клієнта на послуги в нічний час не було. Оплата за договором з ним — за фактично витрачений ресурс. Тобто по суті — ви даремно тримаєте більш дорогу команду на роботі вночі, втрачаючи таким чином кошти. Просто так зняти команду з нічного чергування — не варіант, адже зобов’язання реагувати вночі залишається. Зробивши це, у випадку “нічного” запиту ви не зможете виконати умови договору. А значить — саме час їх переглянути.
SLA — це завжди про бізнес-процеси
Щоб ефективно заробляти на послугах саппорту, важливо:
- глибоко розуміти бізнес-процеси в продукті, який плануєте обслуговувати,
- адекватно оцінювати свої ресурси,
- мати налаштовані процеси в своїй компанії.
Тільки за цих умов ви зможете прорахувати економічний ефект роботи за даним напрямком — знайти адекватне співвідношення “затрати ресурсів – прибуток”. Без цього є велика ймовірність, що окрім головного болю і збитків компанія нічого не отримає.
Щоб процес надання послуг саппорту був однаково комфортним і вигідним для обох сторін, важливо обговорити максимум деталей майбутнього співробітництва і зафіксувати їх в вашому SLA.
Оскільки в IT не існує двох однакових продуктів, то і однакових умов саппорту бути не може. Пам’ятайте про це, розробляючи власні SLA! Або звертайтеся до нас за посиланням — ми вміємо робити так, щоб ваші справи були в порядку.
Автор: Максим Носарєв, IT-адвокат, засновник юридичної компанії Tretten Lawyers
