セルフサービス管理エリアを構築する技術

公開: 2022-03-11

パッシブインカムサイトを立ち上げたら、祝うべきですよね?

残念ながら、人生は必ずしもそうあるべきであるとは限りません。適切なシステムが整っていない限り、通常、顧客に対応するためにお祝いを延期する必要があります。

私は6年以上パッシブインカムサイトを管理してきました。 私にとっては、常に「パッシブ」に重点が置かれてきました。 したがって、私のビジネスを可能な限り合理化することは、私の長年の優先事項でした。

オンラインビジネスを効果的に合理化することは、管理パネルに適切な機能を持たせることです。

この記事では、管理ダッシュボードの一般的な問題について詳しく説明し、それぞれに解決策を提供します。 この投稿の終わりまでに、自動化されたビジネスのための効率的な管理パネルを開発するためのベストプラクティスの強力なプレイブックを手に入れましょう。

ユーザーエラーの説明

ユーザーがミスを犯します。つまり、これらのミスを修正する管理パネルが必要です。 ここにいくつかの例があります。

サプライヤの1つが、誤って間違った製品を顧客に出荷しました。
顧客が間違った製品を注文したか、同じ製品を2回注文しました。
あなたの音楽タブ譜リストのウェブサイトのミュージシャンは、データベースにすでに存在するほぼ同一の分類法を作成します。 たとえば、あなたのWebサイトのユーザーは、「エレキギター」、「Eギター」、「エレキギター」の3つのカテゴリにまたがるエレキギターのタブ譜をまとめたものと見なしています。 これらは実際には1つである必要があります。そうしないと、フロントエンドのナビゲーションと使いやすさが損なわれます。

管理パネルを最適化して、ユーザーエラーを考慮します。

エンドユーザーが間違いを修正できるようにします。 たとえば、Amazonのユーザーのダッシュボードにはフォームがあり、顧客は注文が倉庫で処理される前であればいつでも注文を変更できます。 この機能により、Amazonのお客様は、カスタマーサポートに連絡することなく間違いを修正できます。
ユーザーのサブセットをモデレーターステータスに昇格させます。 RedditやStackOverflowなどのフォーラムには、モデレーターと呼ばれる特別なユーザークラスがあります。 モデレーターはスパムを削除し、タイプミスを編集し、サイトから不快なメッセージや自己宣伝メッセージを取り除き、コンテンツを正しく分類します。 多くの場合、モデレーターはボランティアであり、単にコミュニティに忠実であると感じています。

ユーザーの経験不足の説明

ユーザーがあなたのビジネスに精通していることを期待しないでください。 これが私が意味することのいくつかの例です。

たとえば、平均的なユーザーは貧弱な写真家ですが、プラットフォームにリストされている同じユーザーのホリデーレンタル物件の見栄えの良い写真が必要です。

おそらく、平均的なユーザーは貧弱な営業担当者ですが、それらのユーザーがプラットフォームを通じて販売する装身具について、SEOに最適化された魅力的な説明が必要です。

または、靴をオンラインで販売しているeコマースストアを運営しているが、平均的なサイト訪問者は足の測定方法を知らないため、間違ったサイズを注文し、後で靴を返品したいという顧客が圧倒的に多い可能性があります。

ユーザーの経験不足を説明する管理領域:

インラインドキュメントを作成します。 サイトでのエクスペリエンスを最大限に活用する方法についてユーザーにアドバイスします。 たとえば、「売り上げを伸ばす5つのコピーライティングのヒント」のような投稿を書くことができます。 ユーザーに堅牢な参考資料を提供することで、人間の助けの必要性を大幅に減らすことができます。
半自動支援。 外部ソフトウェアAPIを接続することにより、Webサイトは、メタディスクリプションに最適なキーワードをオートコンプリートするなどの処理を実行し、ユーザーに特定のキーワードをコピーに組み込むように促すことができます。
自分でやれ。 あなた自身の写真を送るか、あなた自身の製品説明を書いてください。 もちろん、これには、エンドユーザーが組織内の適切な担当者にこのサービスの準備ができていることを通知する必要があります。 ここで、管理システムは、このコミュニケーションと、専門家による後の作業の提供を合理化する必要があります。

保留中のビジネス上の決定の会計

残念ながら、すべてを自動化することはできません。 ジャッジメントコールに関しては、通常、人間が必要です。

たとえば、信頼性の高いプラットフォームで最新のベビーシッター申請者の身元を確認する必要がある場合はどうなりますか?

または、プラットフォーム作成者からの最新のデジタル製品の提出に価格を設定できるのがあなただけの場合はどうなりますか?

保留中のビジネス上の決定から生じる管理者の時間節約の例:

既存のユーザーグループを活用します。 出会い系サイトのPlentyOfFishは、不快感を与える可能性のあるプロフィール写真のモデレートを、何も言わずにこれらの写真をチェックするのに数え切れないほどの時間を費やすボランティアユーザーのバンドにアウトソーシングしています。 従来のフォーラムモデレーターとは異なり、公開後にコンテンツをモデレートしません。 代わりに、公開前にユーザーが投稿した写真を精査し、不適切なプロフィール写真が公開されないようにします。
Humans-as-a-ServiceAPIに接続します。 たとえば、Facebookは管理パネルをAmazon Turk(または社内の同等のもの)などのクラウドAPIに接続し、モデレーションをまとめて安価なワーカーにアウトソーシングします。 Facebookの場合、プロのモデレーターが従業員の3分の1を占めています。 確かに、Facebookのコメントが、比較的モデレートされていないWebサイトに表示される巨大なコメントと比較して、比較的良性であることを保証するのに役立つのは、モデレートの存在です。

ユーザーの会計はウェブサイトの管理者と通信する必要があります

あなたがビジネスを運営しているとき、質問が予想されます。 事前に効果的に計画を立てることで、それらに対応するのにかかる時間を劇的に短縮し、最初に受け取る顧客の要求の数を減らすことができます。

ユーザーコミュニケーションのニーズを説明する管理領域:

事前に計画してください。 過去のカスタマーサービスの質問を分析することで、共通のテーマを見つけて、事前に答えることができます。 この典型的な例は、これらの質問と回答のリストを含むFAQページを設計することです。
迅速に顧客に返金します。 顧客の苦情に応じて迅速な払い戻しを提供することは、失望した顧客を満足させるための非常に効果的な方法です。 心配しないでください。これによって利益が減少することはありません。 実際、それはさらに多くにつながる可能性があります。
混乱した訪問者のためのフォーラムを作成します。 Googleは、実質的に存在しないカスタマーサービスで有名です。 人間の代わりに、Googleは製品フォーラムを作成しました。そこでは、混乱しているユーザーが他のユーザーから助けを得ることができます。 まれに、Googleの従業員がこれらのフォーラムのいずれかで質問に回答した場合、その回答は保存され、Googleによって簡単にインデックスに登録され、同じ問題を抱える将来のユーザーが利用できるようになります。 これはエンドユーザーには残酷に思えるかもしれませんが、Googleのサポートされていないサービスの大部分が無料であることを考えると、かなり正当なことです。
既定の応答と仮想アシスタント(VA)を利用します。 過去1年間のカスタマーサービスチケットを確認し、一貫して尋ねられる質問を抽出します。 それぞれにテンプレート化された応答を作成することで、時間を大幅に節約できます。 簡単にアクセスできるGoogleドキュメントに回答を書き込んでください。さらに、CannedResponsesなどのメールプラグインを使用してください。 次に、VAを雇って、質問が発生したときにこれらのテンプレートを顧客に転送します。

心を変えるユーザーの会計

賢い人はかつて、「変化は人生で唯一の不変のものです」と言いました。 彼は正しかったです。 物事は変わります。

たぶん、ユーザーが結婚し、彼らはもはや同じ姓を持っていません。

または、毎月の配達ボックスサービスに加入している顧客が引っ越して、住所を更新する必要があるかもしれません。

これらは避けられない変更の2つの例にすぎず、事前に計画する必要があります。

状況/心のユーザーの変化から生じる管理者の時間節約の例:

ユーザーには編集機能が必要です。 ユーザーダッシュボード内に編集機能を提供しない場合、遅かれ早かれ、カスタマーサポートチーム(およびデータベースプログラマー)は、上記のように手動で変更を加える必要があります。
編集機能をフリーズしないでください。 コメントのあるフォーラムやサイトの場合、削除のために投稿を凍結するためのポリシーを検討するか、代わりに通常のポリシーの例外を要求するボタンを配置する必要があります。 このソリューションは、サポートチームとエンドユーザーの間でやり取りされるメッセージの数を減らすことで時間を節約します。

ユーザーの心配に起因する行動の説明

実店舗とは異なり、オンラインビジネスには、実際の人から直接購入するという安心感がありません。

考えてみてください。 Best Buyで何かを購入したとき、どのように感じますか? 明日の朝、苦情や払い戻しのために戻ってきた場合でも、BestBuyは引き続き存在することを知っているのでおそらく自信があります。

この確実性の感覚は、明らかな理由でオンラインで失われます。 人々はオンラインコミュニケーションを簡単に無視することができます。そのため、見込み客は誰かが彼らに戻ってくるのではないかと考えます。 この疑念は、ウェブサイトがブランドエクイティのない未知のスタートアップである場合にのみ高まります。

ユーザーの心配に起因する管理者の時間節約の例:

懸念に先制的に対処します。 自信を高めるために、誰かがあなたから購入したら、1〜2通のメールを送信します。 たとえば、Amazonやほぼすべてのeコマースビジネスでは、注文が発送されるとすぐにメールが送信されます。 また、製品が配信されるまでユーザーを更新する一連の電子メールを提供するものもあります。

潜在的なあいまいさを解決する

立ち上げから1年が経ち、収益のおかげで、ウェブサイトの管理を専任のチームメンバーに委任できるようになりました。

しかし、ある日、この管理者は予期せず病気になり、その管理者が先週何をしていたかについての説明なしに、管理作業を再開する必要があります

管理パネル内の情報に基づいて、管理者がどこで中断したか、つまり、どのタスクを処理し、どのタスクを取り消したかを知る必要があります。

見えない(または未処理)と考慮される(または処理される)を確実に区別しない設計が不適切なステートマシンのため、これが常に可能であるとは限りません。 たとえば、次のような管理ステートマシンを想像してみてください。

何が起こるのですか状態の変化
アーティストがあなたのアート販売プラットフォームで彼らのアートを販売することを申請しますアーティストエントリは、開始状態が「適用済み」で管理パネルに表示されます
管理チームの誰かがこのアーティストを受け入れ、アートを販売できるようにします管理者が状態を「承認済み」に変更します
あなたのチームはこのアーティストを拒否します。確かに、そのアーティストを望んでいないことを知っているからです。 管理者が状態を「拒否」に変更します
あなたのチームはこのアーティストについての危機に瀕しており、決定を延期したいと考えています何もしない


システム管理者の観点から見たこの管理フローの問題は、管理パネルが、目に見えない新しいアーティスト、すでに見られた/検討されたが完全に拒否されることなく延期されたアーティストの両方に対して「受け入れられた」と表示することです。

アーティストが不在の管理者の心の中にのみ存在し、リードを「延期」としてマークする方法がないことを考慮(または処理)したという事実は、この情報が失われるため、仕事を引き継ぐ人は作業を繰り返す必要がありますすでに完了。

優れたアクティビティフィードは、このタイプのあいまいさを修正します。

透明性を最大化

多くの管理パネルアクションは、舞台裏で一連の手順を実行します。

たとえば、「申請者を受け入れる」ボタンを押すと、問題の申請者は承認メールを受け取り、アカウントに100ドルの登録ボーナスが入金され、データベース内のステータスが「申請済み」から「承認済み」に変更されます。 ソフトウェアエンジニアリングの用語では、これらは副作用です。

あなた(プログラマー)がこれらの機能を開発したことを考えると、「申請者を受け入れる」を押した場合の結果に気付いているでしょう。

少なくとも、ソースコードエディタまたはお気に入りのIDEを開いて、コードを参照して答えを得ることができます。

ただし、カスタマーサービス担当者にはこのような贅沢はありません。 そのため、ボタンを押したときに何が起こるかわからない可能性があります。 また、ボタンを押した後、申請者に承認されたことを通知するのか、それとも申請者に通知する手動の電子メールを送信する必要があるのか​​疑問に思うかもしれません。

この不確実性により、プロセス全体の速度が低下します。これは、管理者が管理者やエンジニアリングの質問をして、その応答を待つ必要があるためです。 言うまでもなく、これは簡単に重複作業につながり、そうでなければスムーズに運営されているビジネスにエラーをもたらす可能性があります。

理想的には、この例では、「申請者を受け入れる」ボタンのある管理ページに、ボタンを押したときに何が起こるかを正確に説明するインラインの説明段落があります。

代わりに、または追加で、ボタンが押された後にメッセージが表示され、次に何が起こるかを説明することができます。

これまで、幸せなケース、つまり、すべてが正常に実行されているときに発生するバックグラウンドアクションについて見てきました。 トリッキーな状況は、何かがうまくいかなかった後の不透明性に対処することです。 どの副作用が完了し、どの副作用が取り残されましたか? 完全に設計されたシステムでは、失敗すると「申請者を受け入れる」ボタンが管理者(およびクリーンアップを行う技術チーム)に受け入れメールが配信されたが、100ドルのサインアップボーナスがそのユーザーのPaypalアカウントに送信されなかったことを通知します。 この情報により、会社は部分的なトランザクションを修正できます。 実装の詳細については、このフィードバックは、すべての小さなステップを追跡する詳細なステートマシンを使用するか、または、正常に実行されたコマンドと実行に失敗したコマンドの両方を戻り値にリストするサービスオブジェクト内に管理アクションをラップすることによって実行できます。

私の経験では、情報が管理者にどのように表示されるかとエンドユーザーにどのように表示されるかの間のギャップは、イライラするほど不透明になる可能性があります。

顧客の電子メールまたはバグレポートに回答するには、管理チームが顧客のログインダッシュボードの外観、特定の自動化された電子メールの内容、またはユーザー向けダッシュボードがユーザーに支払うべき金額を知る必要がある場合があります。

この情報にアクセスできると、ユーザーが問題を経験するときにチームが問題を理解するのに役立ちます。

この機能を実装する1つの方法は、「ユーザーとして表示」管理機能を構築することです。

これは、通常のユーザーにすでに存在する機能を再実装する個別の管理画面を作成する代わりになり、既存のコードを大量に再利用するという追加のボーナスが得られます。

自動化された電子メールについては、軽量の管理領域の電子メールレンダラーを構築して、スタッフがユーザーに送信される、または送信されたメッセージを読み取れるようにすることを検討してください。

システム外のイベントは責任です

管理可能な管理は自己完結型です。

それは、散らばったスクラップではなく、単一の閉じたシステム内に箱詰めされています。

たとえば、どのような払い戻しを行ったかに関する情報がExcelスプレッドシート、テーブル上の黄色いポストイット、および会計士への電子メールに分散している場合、手に混乱が生じます。

適切な解決策は、管理ダッシュボード内のデータベーステーブルに払い戻しの包括的なリストを含めることです。 あなたが真実の単一の神託を持っているとき、あなたはあなたによって作成されたどんな報告も決定的で信頼できることを知っているので安心することができます。

これは当たり前のように思えますが、ビジネスを管理するスクランブルではしばしば無視されます。

それが私に起こったので、私は知っているでしょう。

私が最初にeコマース注文システムの管理パネルを設計したとき、私は売り上げを記録するためだけにそれを準備し、売り上げだけを準備しました。

発売から数か月後、払い戻し、チャージバック、景品、割引、支払い調整など、自分が考慮していなかったすべての追加トランザクションに気づきました。

最初の設計ではこれらのトランザクションを予測していなかったため、管理パネルにそれらを実行または報告するためのコードはありませんでした。

払い戻しをしなければならないときはいつでも、私は通常、時間に追われていたため、その時点で最も簡単な方法で、通常はPaypalのWebインターフェイス(Webサイトの注文データベースをスキップ)を介して実行しましたが、サードパーティのiPhoneを介して実行することもありました。 PaypalのAPIと通信したアプリ。

私の散在する行動、したがってデータのために、私のすべての会計はさまざまな外部ソースで無計画に報告されました。 さらに悪いことに、私の生産データベースの記録は、私の完全な注文履歴と完全に一致していませんでした。

必然的に、問題が発生しました。 収入と手数料に関する管理者の報告は、経済の現実を反映していませんでした。 私の著者の何人かは、誤った財務報告を含む財務報告を送られました。 そして何よりも悪いことに、私は自分の税務報告を過大評価し、それが超過税の支払いにつながりました。

私はすべての払い戻しを割り引いていなかったので、これすべて。

注文情報と会計情報をメインのソフトウェアシステムの内部と外部に部分的に保存することで、そもそもソフトウェアの利点の多く、つまりその正確性と精度を奪いました。 私はもはやそれを信頼することができませんでした、それは私がもはやそれを自動化することができなかったことを意味しました。

これらの問題に対応して、私は会社のデータをコアソフトウェアシステムの外部に保持することへの嫌悪感を抱きました。

必要なすべての情報をコアに統合するのに最初は費用がかかるとしても、長期的には、メリットはハーフアスハックのコストをはるかに上回ります。

とは言うものの、自動化するという私の最善の意図にもかかわらず、それが実現できない場合もあります。

多くのソフトウェア会社は、ユーザーがアカウントをアクティブ化するか購入する時点に向けて、ユーザーをインチ単位で転送する自動販売メールを持っています。これらはすべて、理想的には人間の支援なしで行われます。

リードがこれらのドリップキャンペーンのいずれかの途中でスタッフに特別なリクエストを送信すると、問題が発生します。

リードが2週間休暇をとると答えたとしますが、後で連絡を取り、契約を結びます。

私たちのシステムがわずか5日後に自動リマインダーメールを送信するようにプログラムされている場合、私たちはリードの希望を無視し、おそらく強引で、注意を怠り、ロボットとして出くわすことで関係を悪化させました。

では、この状況で何をするのでしょうか?

1つの答えは半自動です。

管理インターフェースは、どの電子メールを送信するかを尋ねる可能性があり、必要に応じてボックスにチェックマークを付けてスケジュールを解除できます。

確かに、これはエンジニアリングのやり過ぎかもしれないので、時には唯一の現実的なオプションは、自動化された電子メールが時々物事を間違えることを受け入れることです。

最も関連性の高い管理者情報とアクションを表示する

顧客があなたのビジネスに連絡するとき、それは多くの場合、注文、アカウント、またはオファリングに関連しています。

保存されたデータ、ログインCookie、および追跡レイヤーからのデータのおかげで、アプリケーションはおそらく顧客とその相互作用の履歴について多くのことを知っています。

これらの情報ソースをアルゴリズムでプルし、関連するデータを抽出して管理者の応答を容易にすることで、カスタマーサービスの要求に答える時間を大幅に節約できます。

たとえば、連絡先フォームメッセージは、受信トレイに送信される電子メールに変換される前に、注文の支払いステータス、配送ステータス、広告申込情報などを含む情報ボックスが自動的に追加される場合があります。

さらに、これらの強化された電子メールには、払い戻しダッシュボードや配送トラッカーなど、管理領域で最も頻繁に使用される(および関連する)部分への便利なリンクも含まれている可能性があります。

管理者エラーの予測、軽減、および回復

他のみんなと同じように、管理者は人間であり、時々間違いを犯します。

彼らがあなたのデータを管理していることを考えると、彼らの過ちは取り返しのつかない損害を引き起こす可能性があります。

災害を防ぐために実施するいくつかの対策は次のとおりです。

一貫性のあるバックアップを自動的にスケジュールする:これは、考えられるすべてのデューデリジェンス対策の中で最も粗雑で、最も些細なことですが、最も重要です。 しかし、適切なバックアップがあったとしても、SQLダンプをいじくり回す必要がある場合は、すでに傷ついた世界にいます。 したがって、スケジュールされたバックアップが唯一の復元ソースであってはなりません。
ユーザーを怖がらせるように設計されたボタン:取り返しのつかない結果をもたらす可能性のあるアクションの場合は、明るい赤に色を付け、放射性崩壊のアイコンを叩き、「警告:ハード削除は核のオプションです:不明な場合は使用しないでください」のようなタイトルを付けてください。結果。" (明らかに、これらの結果がこのボタンのすぐ隣にあることを表示する必要があります。)
JavaScript確認ポップアップを使用する:管理者の指が滑って、「戻る」ボタンを押す代わりに、2ピクセル下にある「すべてを完全に削除する」ボタンを誤って押してしまうことがあります。 不幸な管理者は、CSSをレンダリングするときに、不器用なUIデザインや厄介なブラウザーの癖に最終的な責任を負わせることで、この事故にまったく責任がない可能性があります。 これがばかげて過度に劇的な例だと思うなら、あなたは間違っています。 金融サービス業界は、ファットフィンガーエラーと呼ばれるものによって数百万を失いました。 その結果、彼らはこれらのタイプのエラーを防ぐためのソフトウェアを設計します。 非常に簡単な修正の1つは、「すべての注文履歴を削除してもよろしいですか?」です。 Javascriptポップアップ。 Javascriptの確認にエンティティ固有のデータ(「すべての注文履歴」)を含めたことに注意してください。 これは、単に「よろしいですか」と尋ねるよりも優れています。 管理者が注文履歴の1つのエントリを削除しようとしたが、誤ってすべての注文履歴を削除するためのボタンを押した場合、Javascript確認ポップアップにこれを明確に記載しておくと、管理者が自分のことを理解したときの「OMG」の瞬間を回避できます。誤って行った。
データのバージョン管理とリビジョン管理を利用する:標準のSQLデータベーステクノロジでは、データを編集すると古い値が上書きされます。 これは、編集が誤って行われた場合、二重に、元のデータを検索または再作成するのが難しい場合に問題になります。たとえば、書き込みに数時間かかる長い説明フィールドや、再度要求するのが恥ずかしい顧客情報などです。 ウィキペディアのようなリビジョン管理ライブラリは、これらの状況に対する頼りになる修正です。 必要に応じて、古いバージョンのデータを簡単に保存および復元できます。 これらのライブラリは通常、データベースの変更を追跡し、以前の値のタイムスタンプ付きバージョンを保持することで機能します。 残念ながら、リビジョン管理ライブラリは通常、写真やPDFなどの大きなバイナリファイルを処理できません。 したがって、これらのデータ型については、AmazonのS3バージョン管理などを使用して、古いバージョンを維持できます。
削除禁止ポリシーの実装を検討してください。これは、一部のテーブルのレコードが削除されないようにすることです。 この背後にある理由は次のとおりです。最新のデータストレージの価格を考えると、古いレコードを削除しても得られるものはほとんどなく、データの整合性の低下、不完全なレポート、またはレコード保持の不一致の点で失われるものはたくさんあります。 削除禁止ポリシーは、すべての主要なテーブルに「deleted_at」日付列を配置することによって実装されます。 以前にレコードを削除するコードがあった場合は、そのレコードの「deleted_at」列を現在の時刻に設定するコードに置き換えます。 コードの他の場所では、ビジネスニーズに応じて、「削除された」レコードを選択的に表示または非表示にします。 たとえば、「削除された」デジタルダウンロードは、「deleted_at」の日付より前にその特定のものを購入した過去の顧客の管理領域、および「常時」の販売レポートに引き続き表示されます。 ただし、フロントエンドショップは、このデジタル製品を見込み客が利用できるものとして表示しないようにする必要があります。

予想外を期待する

上記の一連の問題に対して多数の解決策を提供しましたが、これらは決して厳格なルールではなく、学習して参照するための堅牢なプレイブックです。

最終的な目標は、ビジネスを合理化するために管理パネルを最適化することです。 管理領域を微調整するための時間を確保しておくと、長期的には収益性が向上し、価値のある投資になります。

人生のあらゆるものと同様に、ルールには常に例外があります。そのため、管理パネルを最適化するときは、適切な判断を下すようにしてください。 そして、あなたはついに祝うことができます。