Клієнт просить ще одну дрібницю. І так уже третій тиждень

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

Тут клієнт пише: «А можна ще одну дрібницю?»

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

Клієнт може щиро не розуміти, скільки це займає. А ти можеш щиро хотіти допомогти. Проблема виникає, коли ці два добрі наміри стають способом планувати роботу.

Вихід починається з простого питання: що саме людина зараз просить — виправити погоджений результат чи додати новий?

Уявімо умовну студію, яка готує меню для кав’ярні. Вони погодили перелік позицій, дві мовні версії й файл для друку.

У готовому макеті студія помилилася в ціні. Виправити її — частина доведення погодженого результату до належного стану. Виставляти окремий рахунок за власну помилку було б дивним способом показати індивідуальний підхід.

Якщо клієнт приносить новий розділ меню, просить третю мову й окремі екрани для телевізора, ситуація інша. З’являються результати, яких не було в попередній домовленості.

Між цими випадками є сіра зона. Наприклад, клієнт змінює назву позиції після погодження тексту. Чи входить це у правки? Залежить від того, про що ви домовилися. Якщо межі не визначили, спочатку їх треба з’ясувати, а не оголошувати людині борг заднім числом.

Перед відповіддю звір прохання з погодженим завданням, умовами співпраці й уже виконаною роботою. У статті про послугу «під ключ» ми розбирали, чому назва пакета не пояснює його меж. Тут саме ці межі й знадобляться.

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

На екрані може бути одна кнопка. За нею — інший сценарій, перевірка даних і налаштування повідомлень. Клієнт бачить кнопку, бо саме її хоче отримати. Тобі треба побачити роботу, яка за нею стоїть.

Тому корисна перша відповідь без обіцянки виконання:

Тут немає відмови. Є пауза між проханням і зобов’язанням. Вона дозволяє оцінити задачу до початку роботи. У прикладі з меню спершу з’ясовуємо: потрібно виправити готовий макет чи підготувати новий формат для екранів?

Особливо важливо передавати це правило всім, хто спілкується з клієнтом. Якщо менеджер обіцяє «сьогодні доробимо», а виконавець дізнається про це через годину, межі замовлення існують тільки в голові виконавця.

У нашому умовному прикладі студія запланувала чотири години на адаптацію готового меню. Протягом роботи надійшло дванадцять додаткових прохань, кожне з яких зайняло приблизно десять хвилин.

Це ще дві години. Без урахування того, як виконавець повертався до завдання, шукав потрібну версію й повторно перевіряв результат. Цифри тут вигадані для прикладу; у твоїй роботі їх потрібно виміряти.

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

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

Важливо рахувати й власні доробки через помилки окремо від нових побажань. Інакше під виглядом «складного клієнта» можна приховати проблеми свого процесу.

Коли з’явилося нове завдання, клієнту потрібна відповідь, що з ним можна зробити.

Повернімося до меню. Якщо телевізійні екрани потрібні для відкриття, їх можна додати до поточної роботи й переглянути строк. Якщо відкриття вже завтра, можна спершу завершити погоджений друкований варіант, а екрани підготувати наступним етапом. Іноді новий матеріал можна зробити замість менш важливої частини — якщо обидві сторони погодять таку заміну.

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

У шаблоні залишені поля для заповнення. Вписуй суму й дату після оцінки, а не замість неї. Потрібно врахувати доступність команди, залежності та час на перевірку.

У матеріалі PMI про керування змінами обсягу роботи зміни розглядають разом із їхнім впливом на очікування, бюджет, строки й ризики. Для невеликого замовлення це корисний принцип: спочатку пояснити наслідки, потім погодити виконання. Форму такого погодження можна зробити короткою й посильною для вашої співпраці.

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

Запропонуй зібрати повний перелік до погодженого моменту. Наприклад: «Давайте зберемо зміни в одному списку. Я перевірю їх разом і повернуся з оцінкою». Це особливо корисно, коли матеріал переглядає кілька людей.

Але пакет має бути конкретним. «Усі правки до п’ятниці» не допоможе, якщо клієнт не знає, хто всередині його команди має їх звести. Домовтеся, хто передає остаточний список і підтверджує рішення.

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

Не перетворюй «пакет правок» на спосіб відкласти очевидну помилку, яку треба виправити зараз. Мета — зібрати побажання, а не змусити клієнта чекати, поки у нього накопичиться достатньо приводів для звернення.

Це неприємна розмова, але краще провести її спокійно. Не починай із рахунку, якого клієнт не очікував. Поясни, що відбулося, покажи додатковий обсяг і повернися до умов вашої співпраці.

Можна написати так:

Це не означає, що попередня додаткова робота автоматично безкоштовна або автоматично має бути оплачена. Питання треба вирішувати за вашими домовленостями й обставинами, а за наявності спору — окремо з відповідним фахівцем. Повідомлення встановлює зрозумілий порядок для наступних кроків.

Якщо безоплатні доповнення стали постійними, корисно розібрати й ширшу проблему: як перестати працювати для клієнта без оплати. Межі варто пояснювати до роботи, поки вони ще не звучать як претензія.

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

Потім дайте команді право сказати: «Спершу перевіримо». Якщо у вас будь-яку паузу вважають поганим сервісом, усі списки залишаться декоративними.

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

Сьогодні відкрий одне активне замовлення. Порахуй, скільки додаткових запитів уже виконали й скільки часу вони зайняли. Потім зафіксуй порядок наступних змін. Одного такого прикладу може вистачити, щоб команда побачила, куди зникає робочий день.

вплив змін на очікування, бюджет і строки. Побутові приклади, тексти повідомлень і запропонований порядок роботи — авторська адаптація для малого бізнесу; вони не замінюють ваші погоджені умови.