Після погодження ціна вже не просто поле, яке можна тихо переписати
До погодження замовлення менеджер може уточнювати кількість, змінювати позиції, перераховувати знижку або обговорювати інші умови.
Але після того, як компанія і клієнт уже домовилися, ціна стає частиною зафіксованої домовленості.
Якщо її просто переписати, ми втрачаємо відповідь одразу на кілька питань: яку суму бачив клієнт? За якою ціною вже могли виставити рахунок? Скільки вже оплачено? Чи змінилася маржа? Чи потрібно повторно погодити замовлення? Чи можна ще відвантажувати?
Тому я б розділяла редагування чернетки і зміну вже погодженого замовлення.
Що я б зберігала при зміні ціни
Нова ціна важлива, але без контексту вона не пояснює, що насправді сталося.
Попередня ціна
Значення, яке діяло до зміни і могло бути вже погоджене з клієнтом.
Нова ціна
Значення, яке пропонується або вже затверджене після зміни.
Причина
Знижка, помилка, зміна кількості, нові умови, коригування постачальника або інша реальна причина.
Ініціатор
Хто запропонував або виконав зміну і в який момент це сталося.
Рішення
Чи потрібне погодження і хто має право дозволити зміну такого масштабу.
Наслідки
Що сталося з оплатою, документами, маржею, резервом і можливістю відвантаження.
Як я б побудувала зміну погодженої ціни
Я б не забороняла зміни повністю. Бізнесу потрібна гнучкість, але сама зміна повинна мати зрозумілий маршрут.
Замовлення вже погоджене
Поточні позиції, кількість, ціни та загальна сума вважаються підтвердженою версією домовленості.
Виникає потреба змінити ціну
Користувач не просто переписує значення, а запускає зміну із зазначенням причини.
Система визначає масштаб зміни
Перевіряється різниця в ціні, загальній сумі, знижці, маржі або іншому показнику, важливому для бізнесу.
Перевіряється право на зміну
Невелике коригування може бути дозволене менеджеру, а значна знижка вимагати іншого рівня погодження.
За потреби створюється повторне погодження
Відповідальна людина бачить старе і нове значення, різницю та причину, а не лише кнопку "погодити".
Нова ціна стає чинною
Лише після дозволеного рішення нове значення використовується як актуальна комерційна умова.
Перераховуються фінансові наслідки
Система визначає нову суму до оплати, залишок, переплату або іншу різницю.
Перевіряються документи
Якщо рахунок або інший документ уже створено, система не повинна мовчки залишити його з попередньою сумою.
Перевіряється можливість відвантаження
Якщо після зміни ціни фінансова умова більше не виконана, подальший процес повинен це бачити.
Історія зміни зберігається
Залишається зрозуміло, що було до зміни, що стало після неї і хто прийняв рішення.
| Ситуація | Що я б дозволила | Що перевіряла б додатково |
|---|---|---|
| Виправлення очевидної помилки до оплати | Може бути просте коригування | Причина та історія зміни |
| Невелика знижка в межах повноважень менеджера | Без окремого погодження | Ліміт знижки та маржа |
| Знижка понад ліміт | Після погодження | Різниця в сумі та причина |
| Ціна збільшилася після погодження клієнтом | Потребує окремої уваги | Повторне погодження з клієнтом |
| Замовлення вже частково оплачено | Зміна можлива за правилами бізнесу | Новий залишок або переплата |
| Частина товару вже відвантажена | Не переписувати минулу операцію | До якої кількості застосовується нова ціна |
Особливо важливо продумати, що відбувається, якщо клієнт уже заплатив.
Замовлення було на 10 000, клієнт сплатив 5 000, а після зміни нова сума стала 9 000. Тепер залишок до оплати не 5 000, а 4 000.
Якщо нова сума стала 4 500, виникла вже інша ситуація: клієнт фактично переплатив 500.
Я б не дозволяла менеджеру вручну виправляти окреме поле "залишок до оплати". Воно повинно бути наслідком підтвердженої ціни та фактичних оплат.
Ціна змінює домовленість. Оплата залишається фактом.
Зміна ціни може впливати і на відвантаження.
Наприклад, бізнес вимагає 100% передоплати. Замовлення було на 10 000 і клієнт уже заплатив 10 000. Потім після погодженої зміни сума стала 11 000.
Формально оплата вже є, але нова фінансова умова більше не виконана повністю.
Я б не покладалася на пам’ять менеджера, який повинен написати складу "почекайте". Після зміни ціни система сама повинна повторно перевірити умови, від яких залежить наступний етап.
Я б розділяла право редагувати і право змінювати домовленість
Технічний доступ до поля ще не означає, що людина повинна мати необмежене право змінити комерційну умову.
Менеджер
Може працювати в межах погодженого діапазону знижок або інших визначених правил.
Керівник продажів
Може погоджувати більші відхилення або нестандартні комерційні умови.
Фінанси
Не обов’язково визначають комерційну ціну, але повинні бачити вплив на оплату та фінансові документи.
Система
Перевіряє правила, фіксує історію і не дозволяє непомітно обійти необхідне погодження.
Коротко про зміну ціни після погодження
Головний принцип - не заборонити бізнесу змінювати умови, а зробити такі зміни контрольованими.
Чи потрібно погоджувати кожну зміну ціни?
Чи можна просто зберігати стару і нову ціну?
Що робити, якщо клієнт уже частково оплатив замовлення?
Що робити, якщо рахунок уже створено?
Що робити, якщо частину замовлення вже відвантажено?
З чого почати перевірку поточного процесу?
Як я б побудувала цей процес
У цій серії я беру реальні бізнес-процеси і показую, як зробити важливі зміни, рішення та їх наслідки видимими замість тихого редагування даних.
У ваших замовленнях теж можна змінити ціну так, що потім ніхто не знає чому?
Візьміть кілька реальних замовлень зі зміненою ціною і перевірте: чи видно попереднє значення, причину, автора зміни, погодження та вплив на оплату і документи. Якщо доводиться відновлювати це з переписок, процес уже варто розібрати.
