Искусство создания административных областей самообслуживания

Опубликовано: 2022-03-11

После того, как вы запустили свой сайт пассивного дохода, вы должны отпраздновать, верно?

К сожалению, жизнь не всегда такая, какой она должна быть, и вам, как правило, приходится откладывать торжества, чтобы угодить вашим клиентам, если только у вас нет правильных систем.

Я управляю сайтом с пассивным доходом более шести лет. Для меня акцент всегда был на «пассивном». Поэтому моей давней задачей было максимально оптимизировать мой бизнес.

Эффективная оптимизация онлайн-бизнеса сводится к наличию нужных функций и возможностей в административной панели.

В этой статье я подробно опишу распространенные проблемы с панелями администратора и предложу решения для каждой из них. К концу этого поста вы получите надежный сборник рекомендаций по разработке эффективной панели администратора для вашего автоматизированного бизнеса.

Учет ошибок пользователя

Пользователи ошибаются, а значит нужна админка, которая эти ошибки исправляет. Вот несколько примеров.

Один из ваших поставщиков случайно отправляет покупателю не тот товар.

Клиент заказывает не тот товар или заказывает один и тот же товар дважды.

Музыкант на вашем веб-сайте со списками музыкальных табулатур создает почти идентичные таксономии, которые уже существуют в вашей базе данных. Например, пользователи вашего веб-сайта, рассматриваемые как коллектив, распределяют табулатуры электрогитар по трем категориям: «Электрогитары», «Электронные гитары» и «Электрогитары». Они действительно должны быть одним, иначе ваша интерфейсная навигация и удобство использования будут скомпрометированы.

Оптимизируйте панель администратора для учета ошибок пользователей:

Позвольте конечным пользователям исправлять свои ошибки. Например, Amazon имеет формы на информационных панелях своих пользователей, которые позволяют клиентам изменять заказы в любой момент времени до того, как заказ будет обработан на их складе. Эта функция позволяет клиентам Amazon исправлять свои ошибки, не обращаясь в службу поддержки.

Повысить группу пользователей до статуса модератора. Форумы, такие как Reddit и StackOverflow, имеют специальный класс пользователей, известный как модераторы. Модераторы удаляют спам, исправляют опечатки, очищают сайт от оскорбительных или саморекламных сообщений и правильно классифицируют контент. Во многих случаях модераторами являются добровольцы, которые просто чувствуют себя лояльными к сообществу.

Учет неопытности пользователей

Не ожидайте, что ваши пользователи будут хорошо разбираться в вашем бизнесе. Вот несколько примеров того, что я имею в виду.

Например, ваш среднестатистический пользователь — плохой фотограф, но вам нужны элегантные фотографии сдаваемой в аренду недвижимости того же пользователя, которая указана на вашей платформе.

Возможно, средний пользователь — плохой продавец, но вам нужны дразнящие, SEO-оптимизированные описания безделушек, которые эти пользователи продают через вашу платформу.

Или, возможно, вы управляете магазином электронной коммерции, продающим обувь в Интернете, но ваш средний посетитель сайта не знает, как измерить свою ногу, что приводит к тому, что большинство клиентов заказывают неправильный размер, а затем хотят вернуть свою обувь позже.

Области администрирования, учитывающие неопытность пользователей:

Создание встроенной документации. Посоветуйте пользователям, как получить максимальную отдачу от вашего сайта. Например, вы можете написать пост типа «5 советов по копирайтингу, которые увеличат продажи». Предоставляя пользователям надежный справочный материал, вы значительно сократите потребность в помощи человека.

Полуавтоматическая помощь. Подключив внешние программные API, ваш веб-сайт может делать такие вещи, как автоматически предлагать лучшие ключевые слова для метаописаний и поощрять пользователей включать определенные ключевые слова в свою копию.

Сделай сам. Присылайте свои фотографии или пишите собственные описания продуктов. Это, конечно, требует, чтобы конечный пользователь каким-то образом сигнализировал о своей готовности к этой услуге нужному человеку в вашей организации. Здесь ваша система администрирования должна оптимизировать это общение и последующую работу эксперта.

Учет незавершенных бизнес-решений

К сожалению, все не может быть автоматизировано. Когда дело доходит до суждений, обычно необходим человек.

Например, что происходит, когда вам нужно подтвердить личность вашего последнего претендента на няню на вашей платформе с высоким уровнем доверия?

Или что происходит, когда вы единственный, кто может оценить последний представленный цифровой продукт от автора платформы?

Примеры экономии времени для администратора, связанной с ожидающими бизнес-решениями:

Используйте существующие группы пользователей. Веб-сайт знакомств Plenty Of Fish отдает модерацию потенциально оскорбительных фотографий профиля группам пользователей-добровольцев, которые тратят бесчисленные часы на проверку этих фотографий, не говоря уже о какой-либо оплате. В отличие от традиционных модераторов форума, они не модерируют контент после его публикации. Вместо этого они проверяют отправленные пользователями фотографии перед публикацией, таким образом гарантируя, что неуместные фотографии профиля никогда не будут опубликованы.

Подключайтесь к API-интерфейсам «человек как услуга». Например, Facebook подключает свои панели администратора к облачным API, таким как Amazon Turk (или их внутренние аналоги), и массово передает модерацию на аутсорсинг более дешевым работникам. В случае с Facebook профессиональные модераторы составляют треть его сотрудников. Действительно, наличие модерации помогает гарантировать, что комментарии Facebook будут относительно безобидными по сравнению с чудовищными комментариями, появляющимися на сравнительно немодерируемых веб-сайтах.

Учет потребности пользователя в общении с администрацией сайта

Когда вы ведете бизнес, ожидаются вопросы. Эффективно планируя заранее, вы можете значительно сократить время, необходимое для ответа на них, и, возможно, уменьшить количество запросов клиентов, которые вы получаете в первую очередь.

Области администрирования, которые учитывают потребности пользователей в общении:

Планируйте заранее. Анализируя прошлые вопросы по обслуживанию клиентов, вы можете определить общие темы и заранее ответить на них. Ярким примером этого может быть разработка страницы часто задаваемых вопросов со списком этих вопросов и ответов.

Спешите вернуть деньги клиентам. Предложение быстрого возмещения в ответ на жалобу клиента — довольно эффективный способ удовлетворить разочарованных клиентов. Не беспокойтесь — это не приведет к уменьшению прибыли; на самом деле, это может даже привести к большему.

Создавайте форумы для запутавшихся посетителей. Google печально известен практически отсутствующей службой поддержки клиентов. Вместо людей Google создал форумы по продуктам, где запутавшиеся пользователи могут получить помощь от других пользователей. В редких случаях, когда сотрудник Google отвечает на вопрос на одном из этих форумов, его ответ сохраняется, легко индексируется Google и становится доступным для будущих пользователей с той же проблемой. Хотя это может показаться жестоким для конечных пользователей, это вполне оправдано, если учесть, что большинство неподдерживаемых предложений Google бесплатны.

Используйте готовые ответы и виртуальных помощников (VA). Просмотрите свои тикеты обслуживания клиентов за прошлый год и извлеките постоянно задаваемые вопросы. Создавая шаблонные ответы для каждого из них, вы сэкономите себе массу времени. Пишите свои ответы в легкодоступном Google Doc или, что еще лучше, используйте плагин для электронной почты, например Canned Responses. Затем наймите VA, чтобы он пересылал эти шаблоны клиентам по мере возникновения вопросов.

Учет пользователей, передумавших

Один мудрый человек однажды сказал: «Изменения — единственная постоянная в жизни». Он был прав. Вещи меняются.

Может быть, пользователь женится, и у него уже не та фамилия.

Или, возможно, клиент, который подписался на вашу ежемесячную службу доставки, переехал и ему нужно обновить свой адрес.

Это всего лишь два примера неизбежных изменений, которые вы должны планировать заранее.

Примеры экономии времени для администратора в результате изменения обстоятельств/мысли пользователя:

Вашим пользователям нужны возможности редактирования. Если вы не предоставляете функции редактирования на своих пользовательских панелях, рано или поздно вашей команде поддержки клиентов и программистам вашей базы данных придется вручную вносить изменения, подобные упомянутым выше.

Не замораживайте возможности редактирования. В случае с форумом или сайтом с комментариями вы должны учитывать свою политику замораживания сообщений для удаления или вместо этого размещать кнопку с запросом на исключение из обычной политики. Это решение экономит время за счет уменьшения количества обменных сообщений между вашей службой поддержки и конечным пользователем.

Учет действий, связанных с беспокойством пользователя

В отличие от обычных магазинов, онлайн-бизнесу не хватает уверенности в том, что он покупает у реального человека лично.

Подумай об этом. Что вы чувствуете, когда покупаете что-то в Best Buy? Вероятно, уверены, потому что вы знаете, что завтра утром Best Buy все еще будет там, если и когда вы вернетесь с жалобами или за возмещением.

Это чувство уверенности отпадает онлайн по понятным причинам. Люди могут легко игнорировать онлайн-общение, что заставляет потенциальных клиентов задуматься, ответит ли им кто-нибудь когда-нибудь. Это чувство подозрения только усиливается, когда веб-сайт представляет собой какой-то неизвестный стартап без капитала бренда.

Пример экономии времени администратора из-за беспокойства пользователя:

Упреждающее решение проблем. Отправьте электронное письмо или два, как только кто-то купит у вас, чтобы повысить доверие. Например, Amazon и почти все предприятия электронной коммерции отправляют электронное письмо сразу после отправки заказа. Другие также предоставляют серию электронных писем, которые информируют пользователя до тех пор, пока продукт не будет доставлен.

Устранение возможных неясностей

Прошел год после запуска, и, благодаря хорошему доходу, теперь вы делегируете администрирование своего веб-сайта выделенному члену команды.

Однако однажды этот администратор неожиданно заболевает, и теперь вам нужно возобновить его административную работу, без какого-либо брифинга о том, что этот администратор делал на прошлой неделе.

Основываясь на информации внутри административной панели, вам нужно знать, на чем остановился ваш администратор — какие задачи он обработал, а какие оставил невыполненными.

Это не всегда возможно из-за плохо спроектированных конечных автоматов, которые не могут надежно различать невидимое (или необработанное ) и рассматриваемое (или обработанное ). Например, представьте конечный автомат администратора следующим образом:

Что просходит	Изменения состояния
Художник подает заявку на продажу своего искусства на вашей платформе для продажи произведений искусства.	Запись исполнителя появляется в панели администратора с начальным состоянием «применено».
Кто-то из вашей команды администраторов принимает этого художника, что позволяет им продавать свои работы.	Администратор меняет статус на «принято»
Ваша команда отвергает этого артиста, потому что точно знает, что этот артист ей никогда не понадобится.	Администратор меняет статус на «отклонено»
Ваша команда сомневается в этом исполнителе и хочет отложить решение	Ничего не делать

Проблема с этим потоком администрирования, с точки зрения системного администратора, заключается в том, что панель администратора говорит «принято» как для невидимых новых исполнителей, так и для исполнителей, которые уже были просмотрены/рассмотрены, но были отложены без прямого отклонения.

Факт рассмотрения (или обработки ) этого исполнителя существует только в сознании отсутствующего администратора, и без какой-либо возможности пометить лид как «отложенный» эта информация теряется, поэтому человек, принимающий работу, должен повторить работу. уже закончено.

Хорошая лента активности устраняет эту двусмысленность.

Максимальная прозрачность

Многие действия административной панели выполняют ряд шагов за кулисами.

Например, после нажатия кнопки «принять кандидата» соответствующий заявитель получает электронное письмо с подтверждением, на его счет зачисляется бонус за регистрацию в размере 100 долларов, а его статус в вашей базе данных изменяется с «применен» на «принят». С точки зрения разработки программного обеспечения, это побочные эффекты .

Учитывая, что вы — программист — разработали эти функции, вы, вероятно, знаете о последствиях нажатия кнопки «принять кандидата».

По крайней мере, вы можете открыть редактор исходного кода или свою любимую IDE и обратиться к коду за ответом.

Однако у представителей службы поддержки нет такой роскоши. Поэтому они, вероятно, не будут уверены в том, что происходит, когда они нажимают кнопку. Кроме того, они, вероятно, зададутся вопросом, будет ли заявитель предупрежден о том, что они были приняты, или им следует отправить электронное письмо вручную, предупреждая заявителя после того, как они нажмут кнопку.

Эта неопределенность замедляет весь процесс, поскольку теперь администратору необходимо задавать вопросы руководству и/или инженерам и ждать их ответов. Не говоря уже о том, что это может легко привести к дублированию работы и внесению ошибок в хорошо работающий бизнес.

В идеале, в этом примере, страница администратора с кнопкой «принять кандидата» должна иметь встроенный описательный абзац, объясняющий, что именно происходит, когда они нажимают кнопку.

Альтернативно или дополнительно после нажатия кнопки может появиться сообщение, объясняющее, что происходит дальше.

До сих пор мы рассматривали счастливый случай, т. е. фоновые действия, которые происходят, когда все работает как надо. Более сложная ситуация связана с непрозрачностью после того, как что-то пошло не так . Какие побочные эффекты были устранены, а какие остались незадействованными? В идеально спроектированной системе в случае сбоя кнопка «принять кандидата» информировала бы администратора (и техническую группу, проводящую очистку), что электронное письмо с подтверждением было доставлено, но бонус за регистрацию в размере 100 долларов не был отправлен на учетную запись Paypal этого пользователя. Эта информация позволяет компании исправить частичную транзакцию. Что касается деталей реализации, эта обратная связь может осуществляться либо с помощью подробных конечных автоматов, которые отслеживают каждый крошечный шаг, либо, в качестве альтернативы, путем включения административных действий в сервисные объекты, возвращаемые значения которых перечисляют как успешно выполненные команды, так и те, которые не удалось выполнить.

По моему опыту, разрыв между тем, как информация представляется администратору, и тем, как она представляется конечным пользователям, может быть удручающе непрозрачным.

Иногда для ответа на электронное письмо клиента или отчет об ошибке требуется, чтобы ваша административная группа знала, как выглядит панель входа клиента, что говорит конкретное автоматическое электронное письмо или какие гонорары, по словам панели управления, обращенной к пользователю, он должен пользователю.

Доступ к этой информации помогает вашей команде понять проблемы, с которыми сталкиваются ваши пользователи.

Одним из способов реализации этой функции является создание административной функции «Просмотр от имени пользователя».

Это было бы вместо создания отдельных экранов администратора, которые повторно реализуют функции, уже существующие для обычных пользователей, тем самым предоставляя вам дополнительный бонус повторного использования большого количества существующего кода.

Что касается автоматических электронных писем, рассмотрите возможность создания облегченного средства обработки электронной почты в административной области, чтобы ваши сотрудники могли читать сообщения, которые будут или были отправлены пользователям.

События вне вашей системы — это ответственность

Управляемое администрирование является автономным.

Он упакован в единую закрытую систему, а не в разбросанные обрывки.

Например, если информация о том, какие возмещения вы предоставили, рассредоточена по электронной таблице Excel, желтым стикерам на вашем столе и в электронных письмах вашему бухгалтеру, то у вас на руках беспорядок.

Правильное решение — иметь полный список возвратов в таблице базы данных на панели администратора. Когда у вас есть единственный оракул истины, вы можете быть уверены, что любые отчеты, созданные вами, являются окончательными и заслуживающими доверия.

Хотя это кажется очевидным, этим часто пренебрегают в борьбе за управление бизнесом.

Я бы знал, потому что это случилось со мной.

Когда я изначально проектировал панель администратора своей системы заказов электронной коммерции, я подготовил ее только для записи продаж и только продаж.

Через несколько месяцев после запуска я обнаружил все дополнительные транзакции, которые я не учёл, такие как возмещение, возвратные платежи, халява, скидки и корректировки платежей.

Поскольку я не предусмотрел эти транзакции в своем первоначальном проекте, в моей панели администратора не было кода для выполнения или сообщения о них.

Всякий раз, когда мне приходилось делать возмещение, я обычно был настолько ограничен во времени, что делал это любым способом, который был самым простым в то время — обычно через веб-интерфейс Paypal (пропуская базу данных заказов на моем веб-сайте), но иногда через сторонний iPhone приложение, которое связывалось с API Paypal.

Из-за моих разрозненных действий и, следовательно, данных, вся моя отчетность бессистемно сообщалась в различных внешних источниках. Хуже того, записи в моей производственной базе данных не совсем соответствовали моей полной истории заказов.

Неизбежно возникли проблемы. Административные отчеты о доходах и комиссионных не отражали экономическую реальность. Некоторым из моих авторов были отправлены финансовые отчеты с неправильными финансовыми отчетами. И что хуже всего, я завысил свои налоговые отчеты, что привело к уплате лишних налогов.

Все это потому, что я не обесценил все свои возмещения.

Храня информацию о заказах и бухгалтерском учете частично внутри, а частично вне моей основной программной системы, я в первую очередь лишил себя многих преимуществ программного обеспечения — его точности и аккуратности. Я больше не мог ему доверять, а значит, больше не мог его автоматизировать.

В ответ на эти проблемы у меня появилось отвращение к хранению любых данных компании за пределами моей базовой программной системы.

Даже если поначалу интегрировать всю необходимую информацию в ядро дорого, в долгосрочной перспективе выгоды намного превышают затраты на половинчатые взломы.

Тем не менее, несмотря на мои лучшие намерения автоматизировать, иногда это просто не может произойти.

Многие компании-разработчики программного обеспечения имеют автоматизированные электронные письма о продажах, которые дюйм за дюймом направляют пользователей к моменту, когда они активируют свою учетную запись или совершат покупку — и все это в идеале без какой-либо помощи человека.

Сложности возникают, когда лид отправляет специальные запросы вашим сотрудникам в середине одной из этих капельных кампаний.

Предположим, что лид отвечает, говоря, что он будет в отпуске в течение двух недель, но, пожалуйста, свяжитесь с ним позже, чтобы заключить сделку.

Если наша система была запрограммирована на отправку автоматического электронного письма с напоминанием всего через пять дней, то мы проигнорировали пожелания потенциального клиента и, возможно, испортили отношения, произведя впечатление настойчивого, невнимательного и роботизированного.

Так что же делать в этой ситуации?

Один ответ - полуавтоматический.

Интерфейс администратора может спросить вас, какие электронные письма следует отправлять, и вы можете поставить галочку, чтобы отменить их по мере необходимости.

По общему признанию, это может быть инженерным излишеством, поэтому иногда единственный реалистичный вариант — признать, что автоматические электронные письма иногда ошибаются.

Отображайте самую актуальную информацию и действия администратора

Когда клиент связывается с вашей компанией, это часто связано с заказом, учетной записью или предложением.

Благодаря сохраненным данным, файлам cookie входа и данным, полученным от ваших уровней отслеживания, ваше приложение, вероятно, много знает о своих клиентах и истории их взаимодействия.

Вы можете значительно сэкономить время, отвечая на запросы в службу поддержки клиентов, алгоритмически извлекая эти источники информации и извлекая соответствующие биты данных, чтобы упростить ответы ваших администраторов.

Например, к сообщениям контактной формы, прежде чем они будут преобразованы в электронные письма, отправляемые в ваш почтовый ящик, может автоматически добавляться информационное поле, которое включает статус оплаты заказа, статус доставки, позиции и многое другое.

Кроме того, эти защищенные электронные письма также могут содержать удобные ссылки на наиболее часто используемые (и важные) части административной области, такие как панель управления возвратом средств или средство отслеживания доставки.

Предвидение, смягчение и восстановление после ошибки администратора

Как и все остальные, администраторы тоже люди и иногда допускают ошибки.

Учитывая их контроль над вашими данными, их ошибки потенциально могут нанести непоправимый ущерб.

Вот несколько мер, которые необходимо предпринять, чтобы предотвратить катастрофу:

Автоматическое планирование последовательного резервного копирования: это самая грубая, самая тривиальная, но самая важная из всех мыслимых мер должной осмотрительности. Но, даже если у вас есть хорошие резервные копии, вам уже будет больно, если вам нужно возиться с дампами SQL. Поэтому резервное копирование по расписанию не должно быть вашим единственным источником восстановления.

Кнопки, предназначенные для того, чтобы напугать пользователей: для действий с потенциально непоправимыми последствиями закрасьте их ярко-красным цветом, нанесите на них значок радиоактивности и пометьте их заголовками, например: «ВНИМАНИЕ: УДАЛЕНИЕ АВАРИЙНОГО УДАЛЕНИЯ ЯВЛЯЕТСЯ ЯДЕРНЫМ ВАРИАНТОМ: НЕ ИСПОЛЬЗУЙТЕ, ЕСЛИ НЕ УВЕРЕНЫ В ЕГО ПОСЛЕДСТВИЯ." (Очевидно, вы должны отображать эти последствия прямо рядом с этой кнопкой.)

Используйте всплывающие окна с подтверждением JavaScript: иногда пальцы администраторов соскальзывают, и вместо нажатия кнопки «назад» они случайно нажимают кнопку «удалить все навсегда», расположенную двумя пикселями ниже. Незадачливый администратор может быть совершенно невиновен в этой неудаче, а главная вина лежит на неуклюжем дизайне пользовательского интерфейса или неприятных причудах браузера при рендеринге CSS. Если вы думаете, что это абсурдный и слишком драматичный пример, вы ошибаетесь. Индустрия финансовых услуг потеряла миллионы из-за того, что они называют грубыми ошибками. В результате они разрабатывают программное обеспечение для предотвращения подобных ошибок. Одно очень простое решение — «Вы уверены, что хотите удалить всю историю заказов?» Всплывающее окно Javascript. Обратите внимание, как я включил специфические для объекта данные — «вся история заказов» — в подтверждение Javascript? Это лучше, чем просто спросить «Вы уверены?» Если администратор намеревался удалить одну запись в истории заказов, но случайно нажал кнопку удаления всей истории заказов, четкое указание этого во всплывающем окне подтверждения Javascript помогает избежать момента «Боже мой», когда администратор понимает, что он [s] он ошибочно сделал.

Воспользуйтесь преимуществами управления версиями и версиями данных: в стандартных технологиях баз данных SQL изменения данных перезаписывают старые значения. Это проблематично, когда изменения были сделаны неправильно, и вдвойне, когда исходные данные трудно найти или создать снова — например, поля с длинным описанием, на написание которых уходят часы, или информация о клиенте, которую было бы неловко запрашивать снова. Библиотеки управления версиями, такие как Википедия, являются идеальным решением для таких ситуаций. Они позволяют легко хранить и восстанавливать старые версии данных по мере необходимости. Эти библиотеки обычно работают, отслеживая изменения в вашей базе данных и сохраняя версии предыдущих значений с метками времени. К сожалению, библиотеки контроля версий обычно не могут работать с большими двоичными файлами, такими как фотографии и PDF-файлы. Таким образом, для этих типов данных вы можете сохранить старые версии, используя что-то вроде управления версиями Amazon S3.

Рассмотрите возможность реализации политики запрета на удаление: это все о предотвращении удаления записей в некоторых таблицах. Вот причина этого: учитывая современные цены на хранение данных, удаление старых записей мало что даст, но можно многое потерять с точки зрения нарушения целостности данных, неполной отчетности или несоответствия ведения записей. Политика запрета на удаление реализуется путем размещения столбца даты «deleted_at» в каждой основной таблице. Везде, где у вас ранее был код для удаления записи, вы заменяете его кодом, который устанавливает для столбца «deleted_at» для этой записи текущее время. В другом месте кода вы выборочно отображаете или скрываете «удаленную» запись в зависимости от потребностей бизнеса. Например, «удаленные» цифровые загрузки будут по-прежнему отображаться в области администрирования для прошлых клиентов, которые купили эту конкретную вещь до даты «deleted_at», а также в отчетах о продажах «за все время». Тем не менее, внешний магазин больше не должен показывать этот цифровой продукт как доступный для потенциальных клиентов.

Ожидать неожидаемое

Хотя я предложил множество решений множества проблем выше, это ни в коем случае не жесткие и быстрые правила, а скорее надежный учебник, из которого можно учиться и на который можно ссылаться.

Помните, что конечной целью является оптимизация панели администратора для оптимизации вашего бизнеса. Выделение некоторого времени для настройки ваших административных областей должно повысить прибыльность в долгосрочной перспективе, что делает это стоящим вложением.

Как и во всем в жизни, всегда будут исключения из правил, поэтому обязательно используйте здравый смысл при оптимизации ваших панелей администратора. И тогда вы, наконец, можете праздновать.