Зібрати контекст для моделі під одну задачу означає покласти перед нею три речі в такому порядку: стабільні правила, кілька фактів з датою або версією і одну задачу, сформульовану одним-двома реченнями. Усе інше лишається в архіві, навіть якщо воно правдиве і колись знадобиться. Контекст я уявляю як робочий стіл: у нього є бюджет місця, і кожна зайва річ відсуває вбік ту, яка потрібна саме зараз. Критерій відбору в мене один: чи змінює цей шматок рішення надіслати або не надіслати відповідь клієнту в такому вигляді. Якщо рішення від нього не залежить, на столі йому робити нічого. А нова розмова на нову справу дає змогу щоразу починати з порожнього столу, замість того щоб розбирати завали попередніх задач.
Менеджерка невеликого магазину кормів для тварин третій тиждень готує відповіді клієнтам в одному й тому самому чаті з моделлю. Там лежить стара претензія по доставці з минулого місяця, де клієнту компенсували частину вартості й перенаправили посилку в інше відділення. Там же вчорашня чернетка з прайсу, де мішок корму коштував на сто двадцять гривень менше, бо з понеділка ціни оновилися. А сьогодні власник докинув ще й скрін сторінки каталогу, "щоб модель знала бізнес". Новий клієнт питає, скільки коштує той самий мішок і коли він буде у відділенні біля дому. Відповідь виходить бездоганно чемною і хибною в трьох місцях: ціна взята зі вчорашньої чернетки, відділення перекочувало зі старої претензії, а наприкінці стоїть обіцянка компенсувати доставку, якої в правилах магазину для звичайних замовлень немає. Менеджерка встигла помітити ціну і пропустила решту. Ми зупинилися, відкрили нову розмову і поклали туди короткий пакет: правила відповіді клієнтам на пів сторінки, три факти з датою (ціна з прайсу від понеділка, відділення з картки саме цього клієнта, умови доставки з чинної версії правил) і одне речення задачі. Правильна відповідь вийшла з першого разу. Замість ще одного файлу в архіві зʼявився пакет, який можна збирати знову для кожного наступного клієнта.
Коротко
- Контекст працює як стіл з обмеженим бюджетом місця, тому на нього кладуть лише те, що потрібне для цієї задачі.
- Робочий порядок пакета: стабільні правила, потім факти з датою або версією, потім одна задача.
- Факти беруться щоразу з джерела істини, а не з історії чату, де поруч лежать їхні застарілі версії.
- Критерій відбору звучить як надіслати / не надіслати: якщо шматок не впливає на це рішення, він зайвий.
- Нова розмова на нову справу дає чистий стіл, а правила переходять у неї готовим блоком.
Стіл з бюджетом місця
Вісімнадцять років на фінансових ринках навчили мене однієї речі про звіти: сорок сторінок аналітики майже завжди програють одній сторінці з трьома цифрами, біля кожної з яких стоїть дата. Коли інвестиційний комітет мав ухвалити рішення, ніхто не приносив туди всі листи з клієнтом за пʼять років. Приносили політику фонду, актуальні цифри на конкретний день і питання, на яке треба відповісти "так" або "ні". З моделлю працює та сама логіка, і саме її найчастіше порушують.
Інстинкт власника зрозумілий. Йому здається, що чим більше модель знає про бізнес, тим краще вона відповість. Тому в чат летять прайси за пів року, переписка з постачальником, скріни каталогу, старі претензії. Кожен із цих файлів колись був правдою. Проблема в тому, що на одному столі опиняються три різні ціни на той самий товар, два відділення для того самого клієнта і обіцянка, яку дали один раз у виняткових обставинах. Модель бачить усе це поруч і мусить сама вгадати, що з цього чинне сьогодні. Іноді вгадує. Клієнт отримує відповідь саме в той день, коли вона не вгадала.
Тому я перестав питати себе, що ще можна додати, щоб модель краще розуміла бізнес. Тепер я питаю, як зібрати контекст для моделі під задачу, яка стоїть переді мною саме зараз, і що треба прибрати зі столу, щоб на ньому лишилося лише потрібне. Це питання дає зовсім інший результат, бо воно починається з рішення, яке ухвалить людина, а не з обсягу того, що компанія встигла накопичити.
Пакет правил факти задача
Робоча формула, яку я даю командам, звучить як пакет правил факти задача, і порядок у ній має значення.
Першими йдуть правила. Це те, що змінюється рідко і стосується кожної відповіді: тон, умови доставки, політика повернення, межі того, що менеджер має право пообіцяти. У того магазину правила вмістилися на пів сторінки, і в них окремим рядком записано, коли компенсація доставки можлива, а коли ні. Правила мають свою версію, і коли вони змінюються, змінюється весь блок одразу, а не дописується ще один абзац поверх старого.
Другими йдуть факти з датою або версією. Ціна з прайсу від понеділка. Відділення з картки клієнта станом на сьогодні. Наявність товару на складі на девʼяту ранку. Дата біля факту виконує дві функції. Вона показує моделі, що ця цифра чинна, а будь-яка інша в її памʼяті застаріла. І вона показує людині, яка перевіряє відповідь, звідки взялася цифра і чи можна їй довіряти. Факт без дати я вважаю підозрілим, поки не перевірю.
Третьою йде одна задача. Не "допоможи з клієнтами", а "склади відповідь клієнту на питання про ціну і строк доставки, у два-три речення, без обіцянок понад правила". Одна задача в пакеті відповідає одному рішенню, яке ухвалить людина: надіслати цю відповідь чи ні. Коли в одному повідомленні просять і відповісти клієнту, і переписати опис товару, і порахувати знижку на наступний місяць, модель розподіляє увагу між трьома справами, і кожна з них виходить гіршою.
Надіслати або не надіслати як критерій відбору
У пакеті важко вирішити, що з архіву взяти, а що лишити. Тут мені допомагає критерій помилки. Перш ніж збирати пакет, я формулюю, які помилки в цій відповіді коштують дорого. Для відповіді клієнту про замовлення їх зазвичай три: неправильна ціна, неправильне місце доставки, обіцянка, якої правила не дозволяють. Далі кожен шматок, що претендує на місце на столі, проходить одне питання: якщо його не буде або він буде застарілим, чи може модель зробити одну з цих помилок?
Ціна з чинного прайсу проходить: без неї модель візьме цифру звідки завгодно. Відділення з картки клієнта проходить. Правило про компенсацію доставки проходить, бо саме воно не дає пообіцяти зайвого. Стара претензія іншого клієнта не проходить: вона нічого не додає до цієї відповіді, а помилку з відділенням спровокувала саме вона. Скрін каталогу "щоб знала бізнес" теж не проходить, бо ціни на ньому вже інші.
Звідси практичне правило, яке я повторюю на кожному впровадженні: не кидати весь архів у чат. Архів залишається архівом, і з нього під кожну справу дістається рівно те, що впливає на рішення надіслати / не надіслати. Решта може бути цікавою, корисною для загальної картини і навіть правдивою, але для цієї відповіді вона працює як шум.
Джерело істини і нова розмова на нову справу
Звідки брати факти, важить так само, як і які саме. Для кожного типу факту в компанії має бути одне джерело істини: ціни живуть у чинному прайсі, адреса й відділення в картці клієнта, умови доставки в поточній версії правил. Історія чату джерелом істини бути не може за визначенням, бо в ній лежать усі версії одночасно. Вчорашня чернетка з прайсу була правильною вчора, і саме тому вона така небезпечна сьогодні: виглядає переконливо і стоїть близько.
Коли факти щоразу беруться з джерела істини, стає природною і нова розмова на нову справу. Новий клієнт отримує новий стіл. Блок правил переноситься туди готовим, бо він однаковий для всіх. Три факти змінюються під конкретну людину. Задача формулюється заново одним реченням. Збирання такого пакета забирає хвилину-дві, і ця хвилина повертається з запасом, коли не треба розплутувати, звідки у відповіді взялося чуже відділення.
У тому магазині після кількох днів роботи за цією схемою менеджерка перестала шукати помилки рядок за рядком. Вона дивиться на три факти з датою в пакеті, потім на відповідь, і за пів хвилини вирішує, надсилати чи ні. Якщо цифра у відповіді збігається з цифрою в пакеті, перевірка закінчена. Якщо ні, вона бачить це одразу, бо порівнювати треба з трьома рядками, а не з тритижневою перепискою.
Такий підхід добре масштабується. Коли пакет під одну задачу зібрано кілька разів, з нього виходить шаблон: правила лежать окремим файлом з версією, перелік потрібних фактів записаний, формулювання задачі має сталу форму. Нова людина в команді може зібрати пакет у перший же день, бо їй не треба знати історію всіх попередніх розмов.
Що робити далі
- Візьміть одну повторювану задачу, наприклад відповідь клієнту про ціну й доставку, і запишіть, які три помилки в ній коштують найдорожче.
- Зберіть для неї блок правил на пів сторінки, поставте біля нього номер версії і змінюйте блок цілком, коли змінюються правила.
- Визначте для кожного потрібного факту джерело істини і щоразу беріть факт звідти, ставлячи поруч дату або версію.
- Сформулюйте задачу одним-двома реченнями так, щоб на виході людина могла ухвалити одне рішення: надіслати або не надіслати.
- Для кожної нової справи відкривайте нову розмову і кладіть туди лише пакет, а архів лишайте там, де він лежить.
Про цей матеріал
Цей текст має навчальний характер. Сцени й приклади в ньому ілюстративні, узагальнені з досвіду впроваджень і знеособлені. Вони не є індивідуальною порадою для вашого бізнесу: склад правил, фактів і задач залежить від ваших процесів і ціни помилки, тому кожен пакет варто перевіряти на власних даних.