Заявка, яка чудово описує роботу, але не каже, куди їхати, ще не є роботою. Виїзний сервіс тримається на двох фактах, які транскрипт чату рідко формулює чисто: місце, куди має дістатися бригада, і обладнання, що на неї там чекає. Lavenity зберігає обидва як повноцінні записи, прив’язані до клієнта, а не як речення всередині опису, бо речення не можна зіставити, перевикористати чи звірити із зоною обслуговування.
Property і asset є окремими записами не випадково
Property тримає адресні рядки, поштовий індекс, місто, країну, необов’язкову зону виїзду й нотатки доступу — код від воріт, сусіда з ключем, паркування, яке працює лише до дев’ятої. Ключем є нормалізована форма адреси, тому той самий клієнт, описавши той самий будинок двічі, не накопичує дублікатів, а заявка, створена через місяць, чіпляється до запису, який уже несе нотатки доступу, здобуті важким шляхом.
Asset належить property й описує конкретну машину: категорію, виробника, модель, необов’язковий серійний номер, унікальний у межах робочого простору, дату встановлення й нотатки. Обладнання переживає будь-який окремий візит — і в цьому суть. Другий дзвінок про той самий котел має починатися з того, що бізнес про нього вже знає, а не з клієнта, який читає шильдик у темному підвалі.
Адреса — вимога диспетчера, а не поле шаблону
Адреса потрібна диспетчеру, а не шаблону послуги, і готовність ставиться до неї саме так: її позначають відсутньою незалежно від того, обрано послугу чи ні, під маркером, форма якого навмисно унеможливлює збіг із ключем поля шаблону. Це закрило справжню прогалину. Заявки, які Ven створює з рішення, не мають адреси, а готовність раніше рахувала лише поля шаблону — тому в просторі без налаштованих зон така заявка могла дійти до ready for scheduling, бути заброньованою й підтвердженою клієнту з порожньою адресою.
Зони з’єднують дві половини планування. Ресурс несе зони, які обслуговує, і навички, якими володіє; заявка несе поштовий індекс адреси. Пошук слотів піднімає вгору тих, хто підходить, і пояснює тих, хто ні, — і різниця між цими двома причинами має операційне значення. Адреса поза звичною зоною є рішенням, яке власник може захотіти перекрити заради доброго клієнта, а відсутня кваліфікація має лишатися твердою межею незалежно від того, хто просить.
Зони, навички й те, що бриф заморожує в момент бронювання
У момент бронювання потрібні факти копіюються в технічний бриф роботи: послуга, контакт клієнта, адреса, нотатки доступу, дані обладнання, терміновість, опис заявки й відповіді кваліфікації станом на момент, коли візит прийняли. Саме знімок, а не живе з’єднання: інструкції, які хтось прийняв, не повинні тихо змінитися, якщо колега ввечері напередодні відредагує вихідну заявку. Виправлення після цієї точки додаються як явні нотатки до роботи.
Де неповній заявці дозволено лишатися неповною
Операційний список замикає цикл, показуючи порожню адресу лише там, де вона щось блокує: коли заявка готова до планування або коли робота вже існує й досі жива. Заявці, яку ще кваліфікують, дозволено бути неповною; підтвердженому візиту за адресою, якої ніхто не записав, — ні. Саме цю різницю й покликані утримувати записи property та asset: різницю між розмовою про роботу й роботою, на яку справді можна когось відправити.
Фіксуйте адресу й машину, поки клієнт ще пише
Питайте адресу так рано, як дозволяє розмова, бо це єдиний факт, якого готовність вимагає незалежно від того, яку послугу зрештою оберуть. Заявка, що дійшла до ready for scheduling без адреси, — це бронювання, яке от-от підтвердять клієнту з порожнім полем для диспетчера.
Записуйте обладнання як asset, а не як рядок в описі. Категорія, виробник, модель і серійний номер роблять наступний дзвінок про ту саму машину коротшою розмовою, а серійний номер, унікальний у межах простору, не дає двом напівзаповненим записам описувати один котел.
Усе, що впливає на прибуття, кладіть у нотатки доступу, а не в опис заявки. Код воріт, вікно для паркування й сусід із ключем подорожують разом з адресою до кожного майбутнього візиту, тоді як опис належить одній заявці й зникає з наступної.
Поширене запитання
Чому заявці потрібна адреса, перш ніж її можна запланувати?
Бо адреса потрібна диспетчеру, а не шаблону послуги, і готовність позначає її відсутньою незалежно від того, обрано послугу чи ні. Заявки, які Ven створює з рішення, не несуть адреси, а готовність раніше рахувала лише поля шаблону — тому в просторі без налаштованих зон виїзду таку заявку можна було забронювати й підтвердити клієнту з порожньою адресою.