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