Що таке угода про рівень обслуговування та з чим її їдять?

Коли я говорю про SLA (Угода про рівень обслуговування), то зазвичай бачу в очах співрозмовників байдужість. Запитують, та хто їх читає?

Ніхто не читає навіть більш важливі контракти, а цей то й поготів. Та мушу сказати, що є люди, які читають. Уявіть собі той момент, коли ви хочете вийти зі свого стартапу або залучити серйозного інвестора. Юрист покупця або інвестора точно прочитає. І прочитавши він має сказати щось типу: ви реально маєте аж такий крутий рівень сервісу і дотримуєтеся всього цього?

Ваша впевнена та ствердна відповідь точно підвищить ваш рейтинг. Або уявіть, що ваші клієнти — це не мільйони індивідуальних користувачів, а відносно невелика кількість гігантів (банків, корпорацій, державних установ). В цьому випадку SLA будуть читати і навіть ставитимуть власні вимоги до рівня та якості обслуговування.

А якщо ви надаєте якусь дуже серйозну послугу, то до вашого продукту можуть ставитися додаткові регуляторні вимоги, які ви маєте включити в свою SLA. Такими можуть бути умови захисту даних, прозорість фінансування і т.д.

Тож сьогодні ми поговоримо про угоду, яку навіть не завжди виносять в окремий документ, але яка часто має вирішальне значення для життєдіяльності продукту на ринку.

Опис

Опис послуги, опис сервісу, опис того, для чого взагалі існує ця угода. Деталізація опису залежить значною мірою від того, чи є ваша SLA самостійним документом, чи це частина основного договору.

Часто це не про сам сервіс, а про технічний опис (як загалом і вся SLA). Опишіть функціональні можливості (перелічіть функції, що входять до складу послуги), технічні характеристики (технічні специфікації послуги, системні вимоги, протоколи зв’язку і тому подібне), рівні обслуговування (якщо вони у вас є), обмеження (за потреби описувати саме тут).

Показники продуктивності

Показники продуктивності (Performance Metrics) мені видається чи не найважливішим розділом цієї історії. Тут ви маєте бути максимально конкретними. Зазирнувши в цей розділ технічно підкований клієнт повинен чітко розуміти, що на нього чекає. А технічно непідкований клієнт, мабуть, повинен дивлячись на цей пункт подумати щось типу «ну начебто круто».

Опишіть конкретними цифрами доступність. Це відсоток часу, протягом якого послуга доступна та працює. Бажано, щоб цей відсоток був вищим за 99%, інакше це клієнтам не сподобається. Вкажіть час відповіді. Це час протягом якого ваша служба підтримки надасть відповідь на запит та/або усуне проблему. Зафіксуйте пропускну здатність, тобто чітко вкажіть кількість даних, які ви обробите або передасте за одиницю часу. Визначте прийнятні порогові значення для кожного показника, вказавши прийнятні рівні продуктивності.

Підзвітність

Ваша звітність і моніторинг вашим клієнтом — то запорука довіри у будь-якому сервісі. Мені про це достеменно відомо, бо звіти працюють навіть у юридичному бізнесі. Ви повинні забезпечити клієнту можливість реально відстежувати, чи дотримуються показники, які ви визначили як параметри своєї роботи.

Кредити

«Credits» — це не про позичання грошей в цьому випадку. Мабуть, найбільш популярний спосіб сатисфакції претензій клієнтів — це видача їм «кредитів» (не зміг знайти більш влучного відповідника в українській мові). Тобто коли ви працюєте погано (гірше ніж пообіцяли в своєму договорі), то ви можете зробити клієнту знижку на майбутнє користування своїм сервісом.

Наприклад ви можете написати, що в разі, коли ваш сервіс доступний не 99,5% часу, а 99,0%, то на наступний місяць клієнт отримує 10% знижки. Що більше недоопрацювання, то більша знижка (більший кредит). При цьому варто встановити верхню межу. Типу «скільки б ми не лажали в цьому місяці, а знижки більше 50% на наступний не буде». Але тут звісно все дуже індивідуально. Якщо ви зберігаєте інформацію про клієнтів банку, або у вас платіжна система, то обмеження відповідальності вам звісно конче необхідно, хоча воно може і не спрацювати.

До слова, часто власник продукту визначає надання кредитів як єдиний спосіб правового захисту в частині дотримання SLA. Не в усіх випадках це може спрацювати, але намагатися убезпечитися від юридичних ризиків звісно варто.

Повідомлення

Способи обміну повідомленнями мають бути формалізованими. «Якщо у вас виникла проблема, то пишіть в технічну підтримку на taka-to_adresa@techpidtrymka.comsor. Якщо проблема не вирішена до місячного затемнення, то бийте в набат. Якщо і це не допомогло, то тяпніть віскаря і перехрестіться, бо більше ніяк до нас не достукатися.» Клієнт має чітко розуміти, як йому діяти в разі виникнення проблем і де шукати допомогу.

Різне та важливе

Є ще повно речей, які можна додавати в SLA. Ви для себе маєте розуміти, чи прописані у вас положення про захист персональних даних та інші умови конфіденційності в основній угоді, чи їх варто додати сюди. Чи треба тут умови її припинення, чи вона автоматично припиняється з основною угодою. А яким має бути порушення для того, щоб воно вважалося істотним і було підставою для розірвання угоди (в тому числі основної)?

Можливо такі речі краще прописати самому ніж лишити в подальшому на розсуд суду (до речі вибір застосовного права та спосіб вирішення спорів теж одне з питань, на які краще мати відповідь). Те саме стосується форс-мажору (бо як ви надаватимите послуги, якщо вторгнення позаземної цивілізації знищить ваші сервери).

Підсумки

Service Level Agreement часто значно більше про клієнтський сервіс та про технічні параметри роботи вашого продукту ніж про право. Не факт, що ваші клієнти користуватимуться запропонованими вами «кредитами» (адже ви можете поставити їх використання в залежність від своєчасного звернення клієнтів за ними). Але факт полягає в тому, що ви маєте розуміти свої SLO (Service level objectives) і у вас має бути SLA. І ваша SLA повинна бути якісною.