Ситуація та правила
Клієнт інтернет-магазину повідомляє, що карткова оплата недоступна, але оплата при отриманні працює. Проблему перевірили з кількох пристроїв, кошти з карток не списуються. Ці деталі важливі: слово «оплата» саме по собі не визначає, яка команда має розглядати звернення.
У навчальному правилі збої сайту належать технічній команді, списання та рахунки — фінансовій, доставка — логістичній. Масовий збій способу оплати потребує термінової перевірки людиною. Правило входить до контексту, щоб його можна було перевірити разом із фактами.
Розділіть команду, вплив і перевірку
Питання team обирає маршрут. Питання impact оцінює вплив за шкалою, у якій відрізняються проблема одного клієнта, блокування одного способу оплати та зупинка всіх замовлень. Питання human_review перевіряє твердження про необхідність термінового розгляду людиною.
Нижче — питання з реального прикладу в Playground. Це вхідні дані, які ви можете редагувати. Відповідь з’явиться після виконання запиту; тут ми не підставляємо результат заздалегідь.
{
"team": {
"type": "choice",
"instructions": "Яка команда має розглянути це звернення? Оберіть за головною причиною проблеми.",
"criteria": {
"engineering": "Технічна команда: збій сайту або інтеграції",
"finance": "Фінансова команда: рахунки, повернення списаних коштів",
"logistics": "Логістична команда: відправлення та доставка"
}
},
"impact": {
"type": "score",
"instructions": "Оцініть вплив описаної проблеми на оформлення замовлень.",
"criteria": [
"Не перешкоджає оформленню",
"Ускладнює оформлення одному клієнту",
"Блокує один спосіб оплати для багатьох клієнтів",
"Блокує всі способи оформлення для всіх клієнтів"
]
},
"human_review": {
"type": "noul",
"instructions": "За наведеним правилом це звернення потребує термінової перевірки людиною."
}
}Перевірте, що змінює рішення
За описаним правилом очікуваний маршрут — технічна команда: звернення описує збій сторінки, а не списання коштів. Працює альтернативний спосіб оплати, тому твердження про повну зупинку всіх замовлень не підтримується контекстом. Це ручний розбір правила, а не зафіксована відповідь моделі.
Тепер змініть одну обставину: кошти списано двічі, доставка запізнюється або масштаб проблеми невідомий. Для кожної версії зафіксуйте очікуване рішення до запуску. Так ви перевірите межі сценарію та побачите, чи достатньо однозначно описані критерії.
- Збережіть факти окремо від припущень оператора.
- Не прирівнюйте незручність одного клієнта до масового збою.
- Передбачте шлях до людини, коли потрібних фактів бракує.