建立自助管理区的艺术

本文概述

• 解决潜在的歧义
• 最大化透明度
• 显示最相关的管理员信息和操作
• 预期, 缓解和从管理员错误中恢复
• 期待意外

启动被动收入网站后, 你应该庆祝一下吧？

不幸的是, 生活并不总是应该如此, 你通常不得不推迟庆祝活动以迎合客户的需求-除非你拥有正确的系统。

我管理被动收入网站已有六年多了。对我而言, 重点始终是”被动”。因此, 尽可能简化我的业务一直是我的长期任务。

有效简化在线业务归结为在管理面板中具有正确的功能。

在本文中, 我将详细介绍管理信息中心的常见问题, 并为每个问题提供解决方案。在这篇文章的结尾, 你将掌握最佳实践的丰富经验, 以为自动化业务开发高效的管理面板。

解决用户错误

用户会犯错误, 这意味着我们需要一个管理面板来修复这些错误。这里有几个例子。

你的供应商之一不小心将错误的产品运送给客户。

客户订购错误的产品或两次订购同一产品。

你的音乐目录列表网站上的一位音乐家创建了几乎相同的分类法, 这些分类法已经存在于你的数据库中。例如, 你网站的用户(被认为是集体用户)将电吉他制表分散在以下三个类别中：”电吉他”, “电子吉他”和”电子吉他”。这些实际上应该是其中之一, 否则你的前端导航和可用性会受到损害。

优化管理面板以解决用户错误：

允许最终用户纠正错误。例如, 亚马逊在其用户的仪表板上有表格, 客户可以使用该表格在仓库中处理订单之前的任何时间更改订单。此功能使Amazon客户无需与客户支持联系即可纠正错误。

将一部分用户提升为主持人状态。论坛(例如Reddit和StackOverflow)具有一个特殊的用户类, 称为主持人。主持人删除垃圾邮件, 编辑错字, 清除令人反感或自我宣传的信息的网站, 并对内容进行正确分类。在许多情况下, 主持人是志愿者, 他们只是忠于社区。

考虑用户经验不足

不要指望你的用户精通你的业务。这是我的意思的几个例子。

例如, 你的普通用户是一位贫穷的摄影师, 但你希望获得平台上列出的同一位用户的度假租赁物业的精美照片。

也许普通用户是一个糟糕的销售人员, 但是你想要诱人的, SEO优化的描述这些用户通过你的平台销售的小装饰品。

或者, 也许你经营着一家电子商务商店, 在线销售鞋子, 但你的普通网站访问者不知道如何测量自己的脚, 导致大量顾客订购了错误的尺码, 然后希望以后再归还鞋子。

导致用户缺乏经验的管理区域：

创建内联文档。为用户提供有关如何充分利用他们在你的网站上的经验的建议。例如, 你可以写一篇文章, “增加销售的5个写作技巧”。通过为用户提供功能强大的参考资料, 你将大大减少他们对人工帮助的需求。

半自动协助。通过连接外部软件API, 你的网站可以执行某些操作, 例如自动建议用于元描述的最佳关键字, 并鼓励用户将某些关键字合并到其副本中。

自己做。发送你自己的照片或写下你自己的产品说明。当然, 这最终用户必须以某种方式向组织中的合适人员传达他们准备好此项服务的信息。在这里, 你的管理系统需要简化这种交流以及专家以后的工作交付。

待决业务决策会计

不幸的是, 一切都无法自动化。在进行判断调用时, 通常需要一个人。

例如, 当你需要在高度信任的平台上验证最新保姆申请人的身份时, 会发生什么？

或者, 当你是唯一可以向平台作者提供最新数字产品提交价格的人时, 会发生什么？

因未决业务决策而导致管理员节省时间的示例：

利用现有的用户组。约会网站Plenty Of Fish将可能令人反感的个人资料照片的审核工作外包给了志愿者用户, 这些用户花费了无数小时来检查这些照片, 而无须多言。与传统论坛版主不同, 他们不会在发布内容后对内容进行审核。相反, 他们会在发布之前审核用户提交的照片, 从而确保不会发布不适当的个人资料照片。

连接到即服务型API。例如, Facebook将其管理面板连接到诸如Amazon Turk(或内部等效产品)之类的云API, 并将适当的批量管理外包给便宜的工人。就Facebook而言, 专业版主占其员工总数的三分之一。的确, 与在相对未经审核的网站上出现的骇人听闻的言论相比, 存在适度的内容有助于确保Facebook的评论相对温和。

用户需要与网站管理进行沟通的核算

开展业务时, 会出现问题。通过有效的提前计划, 你可以大大减少响应时间, 并且可以减少你一开始就收到的客户请求的数量。

满足用户交流需求的管理区域：

未雨绸缪。通过分析过去的客户服务问题, 你可以发现常见的主题, 并提前回答它们。一个典型的例子是设计一个FAQ页面, 其中列出了这些问题和答案。

快速退款给客户。提供快速退款以回应客户的投诉是一种让失望的客户满意的有效方法。不用担心-这不会减少利润；实际上, 它甚至可能导致更多。

为困惑的访客创建论坛。 Google因其几乎不存在的客户服务而臭名昭著。 Google代替了人类, 创建了产品论坛, 在这里, 困惑的用户可以从其他用户那里获得帮助。在极少数情况下, 当Google员工在这些论坛之一中回答问题时, 他们的回答会被保存下来, 并由Google轻松将其编入索引, 并可供具有相同问题的未来用户使用。尽管这对于最终用户来说似乎很残酷, 但是当你考虑到Google不支持的大多数产品都是免费的时, 这是完全合理的。

利用罐装响应和虚拟助手(VA)。回顾一下过去一年的客户服务票证, 并提取出始终问到的问题。通过为每个响应精心设计模板化响应, 你可以节省大量时间。将答案写在易于访问的Google文档中, 或者使用更好的电子邮件插件(如罐装回复)来编写。然后在出现问题时雇用VA将这些模板转发给客户。

为用户改变想法核算

一位智者曾经说过：”改变是生活中唯一不变的东西。”他是对的。事情会改变的。

也许用户结婚了, 他们的姓氏不再相同。

或者, 订阅了你的每月送货服务的客户搬家了, 需要更新其地址。

这些只是不可避免的更改的两个示例, 你必须提前计划。

用户因环境/思想的变化而节省时间的示例：

你的用户需要编辑功能。如果你没有在用户仪表板中提供编辑功能, 则客户支持团队和你的数据库程序员迟早将不得不手动进行更改, 例如上述更改。

不要冻结编辑功能。对于论坛或带有评论的网站, 你必须考虑冻结其帖子以将其删除的策略, 或者放置一个按钮来请求对常规策略进行例外处理。该解决方案通过减少支持团队和最终用户之间来回消息的数量来节省时间。

归因于用户担忧的行动

与实体店不同, 在线业务缺乏向真实人物, 当面购买的保证。

想一想。当你在百思买购买商品时, 你感觉如何？可能有信心, 因为你知道明天早晨, 当你投诉或退款时, 百思买仍会在那里。

这种确定性的感觉由于明显的原因而在网上消失了。人们可以轻松地忽略在线交流, 这使潜在客户怀疑是否有人会与他们联系。这种怀疑的感觉只有在该网站是一家不知名的, 没有品牌资产的初创公司时才会增加。

管理员因用户担忧而节省时间的示例：

抢先解决问题。一旦有人向你购买, 请发送一两封电子邮件, 以增强信心。例如, 亚马逊以及几乎所有电子商务企业都在订单发送后立即发送电子邮件。其他人还提供了一系列电子邮件, 这些电子邮件会更新用户, 直到产品交付为止。

解决潜在的歧义

推出一年后, 由于收入丰厚, 你现在将网站的管理委派给了专门的团队成员。

但是, 有一天, 该管理员意外生病, 现在你需要恢复他们的管理工作, 而无需简要介绍该管理员上周的工作。

根据管理面板内的信息, 你需要知道管理员从何处退出—他们处理了哪些任务以及未完成的任务。

由于状态机设计不良, 无法可靠地区分未见(或未处理)与已考虑(或已处理)之间, 因此这并非总是可能的。例如, 想象一个管理状态机, 如下所示：

从系统管理员的角度来看, 这种管理流程的问题在于, 管理面板对未见过的新艺术家以及已被看到/考虑但被推迟而没有被完全拒绝的艺术家说”接受”。

考虑过(或处理过)艺术家的事实仅存在于缺席管理员的脑海中, 并且无法以任何方式将潜在客户标记为”已推迟”, 因此该信息会丢失, 因此接管工作的人必须重复工作已经完成。

良好的活动供稿可解决此类歧义。

最大化透明度

许多管理小组的操作在后台执行了一系列步骤。

例如, 按下”接受申请者”按钮后, 有问题的申请者会收到接受电子邮件, 他们的帐户会获得$ 100的注册奖金, 并且他们在数据库中的状态也会从”已申请”变为”已接受”。用软件工程术语来说, 这些都是副作用。

假设你(程序员)开发了这些功能, 那么你很可能意识到点击”接受申请人”的后果。

至少, 你可以打开源代码编辑器或你喜欢的IDE, 然后参考代码获取答案。

你的客户服务代表却没有那么奢侈。因此, 他们可能不确定按下按钮时会发生什么。此外, 他们可能会想知道是否会在按按钮后向申请人发出警报, 通知他们是否已被接受, 或者是否应该发送手动电子邮件提醒申请人。

这种不确定性减慢了整个过程的速度, 因为现在管理员需要询问管理和/或工程问题并等待他们的响应。更不用说这很容易导致重复的工作并将错误引入本来可以顺利运行的业务中。

理想情况下, 在此示例中, 带有”接受申请人”按钮的管理页面将包含一个内联的描述性段落, 以准确解释当他们按下按钮时会发生什么。

替代地或附加地, 在按下按钮之后可能会出现一条消息, 说明接下来会发生什么。

到目前为止, 我们已经研究了一个令人满意的案例, 即在一切正常运行时发生的后台操作。棘手的情况是出现问题后要处理不透明性。哪些副作用已经完成, 哪些副作用没有解决？在一个设计完善的系统中, 如果出现”失败”, “接受接受者”按钮将通知管理员(和正在进行清理的技术团队)已收到接受电子邮件, 但100美元的注册奖金并未发送到该用户的Paypal帐户。该信息使公司能够纠正部分交易。至于实现细节, 此反馈可以通过跟踪每个微小步骤的详细状态机来完成, 也可以通过将管理操作包装在服务对象中来完成, 这些服务对象的返回值列出了成功运行的命令和失败运行的命令。

以我的经验, 在管理员看来信息和最终用户看起来如何之间的差距是令人沮丧的不透明。

有时, 要回答客户的电子邮件或错误报告, 你的管理团队需要了解客户的登录信息显示板的外观, 特定的自动电子邮件的内容或面向用户的信息显示板所欠用户的使用费。

有权访问此信息可帮助你的团队在用户遇到问题时理解问题。

实现此功能的一种方法是构建”以用户身份查看”管理功能。

这将代替创建单独的管理屏幕来重新实现普通用户已经具有的功能, 从而为你提供重复使用大量现有代码的额外好处。

至于自动电子邮件, 请考虑构建一个轻量级的管理区域电子邮件渲染器, 以便你的员工可以阅读将要或已经发送给用户的邮件。

系统外的事件属于责任

可管理的管理是独立的。

它装在一个封闭的系统中, 而不是分散在废料中。

例如, 如果有关你退款的信息分散在Excel电子表格中, 桌上有一些黄色的便条纸, 以及发给会计师的电子邮件中, 那么你手头一团糟。

正确的解决方案是在管理信息中心内的数据库表中包含退款的完整列表。当你只有一个真理的预言时, 你可以放心知道你产生的任何报告都是权威可靠的。

虽然这似乎很明显, 但通常在管理业务的争夺中被忽略了。

我会因为发生在我身上而知道。

最初设计电子商务订购系统管理面板时, 我只为记录销售和仅销售做准备。

推出几个月后, 我意识到我没有考虑到的所有其他交易, 例如退款, 退款, 赠品, 折扣和付款调整。

由于我在最初的设计中并未预见到这些交易, 因此管理面板中没有用于实现或报告这些交易的代码。

每当我必须退款时, 我通常都会受时间的束缚, 以当时最简便的方式进行付款-通常通过Paypal的网络界面(跳过网站的订单数据库)-但有时会通过第三方iPhone与Paypal的API通信的应用程序。

由于我分散的行动以及因此而来的数据, 我的所有会计工作都偶然地从各种外部来源报告了。更糟糕的是, 我的生产数据库记录并没有完全记录我的全部订单历史记录。

不可避免地出现了问题。管理员的收入和佣金报告未反映经济现实。我的一些作者收到的财务报告中包含错误的财务报告。最糟糕的是, 我高估了我的纳税报告, 从而导致支付了过多的税款。

所有这些都是因为我没有对所有退款进行折现。

通过将订单和记帐信息部分存储在我的主软件系统内部, 部分将其存储在我的主软件系统之外, 我一开始就剥夺了软件的许多优势–准确性和准确性。我不再信任它, 这意味着我不再能够使其自动化。

针对这些问题, 我厌恶将任何公司数据保留在核心软件系统之外。

从长远来看, 即使最初将所有必要的信息集成到核心中的成本很高, 其收益也远远超过了半骗子的损失。

就是说, 尽管我最想实现自动化, 但有时还是无法实现。

许多软件公司都有自动化的销售电子邮件, 可以将用户逐寸引导到他们激活帐户或进行购买的地步-理想情况下, 所有这些操作都无需任何人工协助。

当主管在这些滴灌活动之一中途向你的员工发出特殊要求时, 就会产生复杂性。

假设潜在客户做出回应, 说他们将休假两个星期, 但请稍后与他们联系以达成交易。

如果将我们的系统编程为仅在五天后发送一封自动提醒电子邮件, 那么我们就忽略了潜在客户的意愿, 也许会遇到急躁, 不专心和机器人的关系, 从而消除了这种关系。

那么在这种情况下该怎么办？

一个答案是半自动化。

管理界面可能会询问你应该发送哪些电子邮件, 并且你可以在方框中打勾以根据需要取消计划。

诚然, 这可能是工程学上的过大手段, 因此有时唯一现实的选择是接受自动发送的电子邮件有时会把事情弄错。

显示最相关的管理员信息和操作

客户与你的公司联系时, 通常与订单, 帐户或产品有关。

通过存储的数据, 登录cookie和跟踪层中的数据, 应用程序可能对客户及其交互历史了解很多。

你可以通过算法提取这些信息源并提取相关的数据位来简化管理员的响应, 从而节省大量时间来回答客户服务请求。

例如, 联系表格消息在转换为发送到收件箱的电子邮件之前, 可能会自动附加一个信息框, 其中包括订单的付款状态, 运输状态, 订单项等。

此外, 这些强化电子邮件还可以包含指向管理区域最常用(和相关)部分的便捷链接, 例如退款仪表板或运输跟踪器。

预期, 缓解和从管理员错误中恢复

像其他所有人一样, 管理员是人为的, 有时会犯错误。

有了他们对你数据的控制权, 他们的错误就有可能造成无法弥补的损失。

以下是为防止灾难而采取的一些措施：

自动安排一致的备份：这是所有可能的尽职调查措施中最粗糙, 最琐碎但最重要的。但是, 即使你拥有良好的备份, 如果你需要修改SQL转储, 也已经蒙受了很大的麻烦。因此, 计划的备份不应成为还原的唯一来源。

设计用来吓users用户的按钮：对于可能造成无法弥补的后果的操作, 请将其涂成红色, 在其放射性图标上打一巴掌, 并标上标题, 例如”警告：硬删除是核选项：请勿对其使用不确定。结果。” (显然, 你应该在此按钮旁边显示这些后果。)

使用JavaScript确认弹出式窗口：有时, 管理员的手指滑动了, 而没有按”返回”按钮, 而是不小心按了位于下方两个像素的”永久删除所有内容”按钮。不幸的管理员对于这种不幸可能完全没有错, 最终的罪魁祸首是渲染CSS时笨拙的UI设计或讨厌的浏览器怪癖。如果你认为这是一个荒谬且过于戏剧化的例子, 那你错了。金融服务业因所谓的”胖手指”错误而损失了数百万美元。结果, 他们设计了防止此类错误的软件。一个简单的解决方法是”你确定要删除所有订单历史记录吗？” JavaScript弹出窗口。请注意, 我如何在Javascript确认中包括特定于实体的数据-“所有订单历史记录”？这比仅询问”你确定吗？”要好。如果管理员打算删除订单历史记录中的单个条目, 但是不小心按下了删除所有订单历史记录的按钮, 则在Javascript确认弹出窗口中明确说明这一点有助于避免管理员意识到” OMG”时刻的情况。错误地做了。

利用数据版本控制和修订控制：在标准SQL数据库技术中, 对数据的编辑将覆盖旧值。当编辑被错误地进行时, 这是成问题的, 而当原始数据难以再次找到或创建时, 这是双重的。冗长的描述字段可能要花几个小时才能写出来, 或者客户信息会令人尴尬地再次询问。像Wikipedia一样, 版本控制库是这些情况的最佳解决方案。它们使你可以根据需要轻松地存储和还原旧版本的数据。这些库通常通过跟踪数据库中的更改并保留先前值的带有时间戳的版本来工作。不幸的是, 版本控制库通常无法处理较大的二进制文件, 例如照片和pdf。因此, 对于这些数据类型, 你可以使用Amazon S3版本控制保留旧版本。

考虑实施不删除策略：这是关于防止删除某些表中的记录的所有操作。这是背后的原因：考虑到现代数据存储的价格, 删除旧记录几乎无济于事, 而在数据完整性受损, 报告不完整或记录保存不匹配方面损失了很多。通过在每个主表上放置一个” deleted_at”日期列来实施无删除策略。无论以前在何处有删除记录的代码, 都可以使用将该记录的” deleted_at”列设置为当前时间的代码替换。在整个代码的其他地方, 你可以根据业务需要有选择地显示或隐藏”已删除”记录。例如, 对于过去的客户, “已删除”的数字下载将继续出现在管理区域中, 这些客户在” deleted_at”日期之前和”历史记录”销售报告中购买了该特定商品。但是, 前端商店不应再将此数字产品显示给潜在客户。

期待意外

尽管我为上述一系列问题提供了多种解决方案, 但这些规则绝非一成不变的规则, 而是一本可供学习和参考的强大手册。

请记住, 最终目的是优化你的管理面板, 以简化你的业务。从长远来看, 留出一些时间来调整你的管理区域应该可以提高盈利能力, 这是值得的投资。

与生活中的任何事物一样, 规则总是会有例外, 因此在优化管理面板时请确保使用良好的判断力。然后, 你终于可以庆祝了。