Исполнители разбирают заявки сами. Звонков становится меньше, реакция быстрее — но есть условия, без которых схема разваливается.
В классической схеме заявка проходит через человека: диспетчер принимает её, прикидывает, кто свободен и кто ближе, звонит, уточняет, договаривается, перезванивает клиенту. Пока людей трое, это работает. Когда их десять, диспетчер превращается в узкое место, через которое проталкивается весь поток.
Хуже того, диспетчер принимает решения на основе устаревших сведений. Он не знает, что первый исполнитель задержался на предыдущем объекте, а второй как раз освободился и стоит в двух кварталах от адреса. Он распределяет по картине, которая была верна полчаса назад.
Альтернатива устроена иначе: новые заявки складываются в общий список, видимый всем исполнителям, и каждый берёт ту, которую реально может выполнить. Человек на месте знает о своей загрузке, маршруте и компетенции больше, чем любой диспетчер.
Практические следствия появляются быстро. Время между появлением заявки и началом работы сокращается, потому что из цепочки исчезает согласование. Пропадает значительная часть звонков. Растёт удовлетворённость исполнителей — возможность выбирать воспринимается совсем не так, как назначение сверху.
Пул перекладывает решение туда, где больше всего сведений для его принятия, — на человека, который сейчас в поле.
Есть техническая деталь, которую легко упустить и дорого исправлять. Двое исполнителей открывают список одновременно и видят одну и ту же свободную заявку. Оба нажимают «взять». Если система проверяет доступность и затем записывает исполнителя двумя отдельными действиями, между ними существует промежуток, в котором успевает вклиниться второй.
Результат — заявка, назначенная двоим. Оба выезжают, один узнаёт об этом на месте. Клиент видит неразбериху, компания оплачивает лишний выезд, доверие к системе подорвано, и дальше исполнители всё равно начинают перезванивать диспетчеру — «на всякий случай». То есть схема возвращается к тому, от чего уходили.
Правильное решение — делать проверку и назначение одной неделимой операцией на стороне базы данных: назначить исполнителя при условии, что заявка всё ещё свободна. Если условие не выполнилось, значит кто-то успел раньше, и второй получает честный отказ вместо мнимого успеха. Проверять это нужно специально — сценарий одновременного взятия должен входить в тесты, потому что в обычной эксплуатации он проявляется редко и всегда не вовремя.
Схема не универсальна, и честнее назвать её границы.
На практике жизнеспособна смешанная модель: часть заявок распределяется адресно, остальные уходят в пул. Возможность вернуть заявку обратно, пока работа не начата, тоже важна — без неё человек боится брать и предпочитает дождаться назначения.