さぽろーぐ さぽろーぐ

サポートサイトの作り方 その1

うまく行かない原因を考える
シェア
CloudGarageのサポートサイトを作り変えようという話が上がっています。せっかくなので、FAQやオンラインガイドを掲載したサポートサイトのことを「さぽろーぐ」に書いてみようかということになりました。

その話が出て数日後のことです。
ある方より、「ある会社でサポートサイトを作ろうとしているが全然進まない」という話を聞きました。どんな原因で滞るのだろう、成功させるためのこつはあるのか?を考えてみました。

サポートサイトの作成、進まない要因

「知り合いの会社のサポートサイトの構築が遅々として進まない」という話を聞きました。

たとえば、サポートサイトで採用しているCMSの仕様が要望を満たせなかったり、社内での文書更新のための手続きが煩わしかったりという理由で、サイトが先細りになることもあるかと思います。

保守面の問題であれば、バックアップを取っていなかったので一瞬にして壊れ復元できなくなったとか、ハッキングされてサイトが使い物にならなくなり、それ以降サイト公開を断念したとかというケースもあるかもしれません。

人材や労力の問題で、CMSを導入し検証できる人材がおらず、全部手書きのHTMLで作ることになり手間が大きかったとか、メインで担当するはずの人が辞職して頓挫というケースもあるでしょう。

幸運なことに私自身は「サポートサイトの更新や作成にどうしようもなく行き詰まった」という体験をしたことはありません。ひとえにCMSの選定をしてくれる人、デザインを相談でき実現してくれる人、サーバーを守ってくれる人に恵まれていたからだと思います。

ただ、足回りの環境に恵まれていても、「スタッフブログが続かない」「サポートブログが続かない」「メディアの更新のモチベーションが落ちた」というような「ひとつの情報メディアがしぼんでいってしまう」という局面に出くわしたこともありました。

そこで考えてみることにしました。

サポートサイトの構築や更新がうまく行かない理由にはどんなものがあるのでしょうか。ツールは整っていて、人手が足りないわけでもないのに、進まなかったり、更新できなかったりするのには、どういう理由があるのでしょうか。

「お勧めしないこと」をあえて考える

やった方がいいのに進まないのには、個々のモチベーションもあるのだと思います。ただ、それ以外にも「行き詰まってしまう方法」が、正しいと判断されて進んでしまっているのではないかとも考えられます。

1)他社サイトからの拝借しない

どんなサービスも特徴や癖があります。開発している自分たちでは、あまり気づけていないこともあるものです。

たとえば「購入ガイド」を作るとしたら、「自サイトの画面遷移や特有の用語で何がわかりにくいか」をあらかじめピックアップしておきます。自分たちのわかりにくさを直視するところから始めたほうが良いでしょう。

逆にサポートサイトを作ろうとして、手始めに競合他社サイトや他サービスのサイトを参考にして、カテゴリを決め、項目をリストアップしていることはあるとは思います。ただ、それはうまくいきません。

もし、すでに他社サイトのコンテンツを拝借してしまったなら、どうすれば自社のサービスに合ったものに改良できるかを考えるところからスタートし、あくまでもタタキ台として、いかに作り変えるかをがんばるしかありません。

2)新プラン導入前に「サポートの片手間」で準備しない

サポートサイトが軌道に乗ってからは、慣れた人が「片手間」で1つや2つの案内文を作ってしまうこともできるでしょう。けれども、初期の構築時や新プラン導入前は業務の一環として専任者とそれなりの時間を割り当てるべきと思います。

理想を言えば、新しいプランやサービスをリリースする前には、三週間前くらいから本番と同じような購入テストや利用テストを行い、想定される設問や手順書を準備し始めておくのがいいでしょう。

製品のデバッガー件サポートスタッフだと思って、本気の業務としてこれを行います。自社の画面に出てくるエラー文言にどんなものがあるかをチェックし、すべてメモしておきます。

もし、他社と競争力のある新しいプランを開始するということなら、自分たちのサービスに売りになるようななんらかの特徴があるはずで、わかりにくい部分が出てくるのは当然です。ここでも、他社サイトをベースにせず、こっそり綿密に時間をかけて準備するべきです。

3)編集担当を持ち回りにしない

仕事の配分などをまじめに考えすぎて、上司が「誰でもできるようにしてほしい」とサポートスタッフ全員に強制してしまうと、文書作成が苦手な人はモチベーションが下がります。慣れていない人がやっても効率が悪く時間もかかります。

とにかく編集の中心人物はひとり決めておいたほうがいいと思います。

とくに初期の段階でたくさんのページを準備しなければいけない時は、中心となる人物がほぼひとりで集中して作業や校正に当たったほうがよいと思います。

ひとりが担当すれば、カテゴリ分けの線引き、文書の重複の有無、使用する用語の揺らぎにも気づけます。そのひとりが、枝葉の部分、つまり個別のページまで作成して作りこみます。

明らかな誤字は気づいた人が直してくれていいと思うので、全部をひとりにおしつけろというのではありませんが、運用が落ち着いて、ほかの誰かが投稿することになってからも、指南役、メインの方向性を決める人がチェックした方がコンテンツとしてまとまります。

コラム:匿名であっても中心人物がサイトのコンセプトを作ってしまうという現実

例えば、あるアパレルショップの女性スタッフが「スタッフブログを書いてほしい」といわれ、書き始めたとします。匿名ではあったものの、彼女はスタッフとしての経験や知識をまとめ、何本か投稿しました。

顔出しは特にしていませんでしたが、そのショップに通うお客様は「あのブログはこの店員さんかな」と想像していました。そのブログには「持ち回り連載感」ではなく、特定のスタッフがお客様の要望を感じて代弁してくれているような心地良さがあったからです。

ある日、そのブログもプロモーションのサイト再編の波の中統合されることになりました。それまでは、「今度はこういう記事を書いたらどうか」ということを決定する話し合いがあれば、彼女も声をかけてもらい出席していましたが、ある時から彼女は呼ばれなくなりました。

サイト改変後は彼女が関わらなくても記事が更新される状況になりました。平たく言えば、頼まれなくなったからやめたわけですが、彼女は多少なりとも寂しく思うでしょう。

ここで重要なのは、プロジェクトの管理者と彼女の後を引き継いだ担当者の側に、それまで作られてきたブログメディアへの愛情とそれまで同様のお客様に対しての目線があるかどうかです。

彼女本人は気づいていなくても、サイトのコンセプトを作りあげて来ていたのです。だからその良い部分をきちんと継承できているかどうかが大事です。

サイト再編後、元のコンセプトを継承しないのならば、過去に彼女が書いた記事も含め、一旦削除し別のものを作り直してしまったほう良いのです。

また、これはプロジェクト管理者の方へ向けてのメッセージですが、随時更新されるようなメディアを作るならば、最初から公の役割として担当者を明言しておいたほうがいいと思うのです。「誰でも平等に編集できるからからみんながんばって書け」というのもやめましょう。

そうしておけば、知らないうちに担当者を外してしまい、「誰でもできる」とよくも悪くも錯覚させてしまうことを防げます。

サポートサイトは、スタッフブログなどよりももっと匿名性が高いものです。だから「誰だって更新できる」と思うかもしれません。

ただサポートサイトも、共通したコンセプト、マインドが貫けているからこそ、利用者も使いやすくなることを忘れてはいけません。また、サポートサイトであっても、場合によってはサービスの顔になり、広報的な役割を担うこともあるのです。

4)1枚の大作ガイドを作って酔いしれない

「すべてが説明されている1枚のページを作っておいて、このURLをお客さんに案内すればすべてOKとなるようにしたい」と思う気持ちはよくわかります。けれども、関連する枝葉の部分のFAQをリストアップしておき、それぞれを個別のページに掲載するほうが、いろいろなシーンで使いまわしが利くものが出来上がります。

自分の利用しているサーバーのグローバルIPアドレスを確認したり、契約の金額を確認したり、契約終了日を確認したり、お客様はたくさんの小さな基礎知識を必要としています。切り出しておいたほうがいいのです。

5)バグや制約を隠さない、後回しにしない、完璧を求めない

サポートサイトは紙媒体で配布している印刷物とは違います。ウェブなので後で修正もできます。

たとえばおもちゃ屋さんで販売するゲームソフトの手引書には、「現時点で不明です」とか「 詳細はわかり次第更新します」とは絶対に書けません。しかし、ホスティングサービスのサポートサイトにはそれをあえて書いたほうがいいこともあります。

お手元のパソコンのOSも、ウェブブラウザなどのソフトウェアもアップデートが当たり前という中、完璧でなくてもリリースせざるを得ないのが昨今です。

こちらが販売しているホスティングサービスや、提供している管理画面も不具合もあれば、メインテナンスしてアップデートを行うこともあります。

もし、開発中の管理画面のバグや、一定条件下で不具合が発生する事象を見つけたとして、改修を待っていても良いことはありません。「障害」までいかなくても、ある一定の条件があれば直面する不具合があれば、サポートサイトにも載せることをおすすめします。

また、お客様のお問い合わせがきっかけとなってサイトを更新した場合、「サポートサイトに反映させました」とお客様にもフィードバックするのも良いと思います。お客様からの情報があってこそ、サイトやサービスそのものが成長するからです。

5つのやったほうがいいこと

今回に挙げた5つは、「これだとうまくいかないな」と思うことでしたが、言い換えれば

1)お客様の立場で確かめながら、オリジナルのサイトを作ること

2)人と時間をしっかり割り当てて、正式な業務として事前準備をすること
(特に新プランリリース前)

3)メインの編集は固定のひとりが担当すること
(記事作成が匿名であっても社内ではコンセプト策定に関わる人物は公式に決めておくこと)

4)必要な知識を切り分けて、短いページを作ること

5)可能な限りオープンに、迅速に、正直に書くこと、そしてお客様からもたくさん情報をいただけるようにすること

が「やったらいいな」と思うことになります。
 

ピックアップフレーズ

「メディアへの愛情を持続させるのは難しいが、壊すのはとても簡単」

サポートサイトはひとつの独立したメディアです。機械的に作ることも更新することもできません。

青影青影
私自身、下調べにいろいろなサポートページを見る機会が多いですが、読んでも理解できない言葉にぶつかっては、さらに検索をかけて調べたりもします。だれでも、わかりやすく案内するのは難しいことです。

また、一斉通知メールやお知らせブログを書く機会がありますが、わかりやすくと思うと、回りくどくなり、簡潔にと思うとこれで伝わるだろうかと不安になったりもします。

なお、お問い合わせの返信はお客様に合わせて、説明を簡潔にしたり細かくしたりと調節できますが、サポートページはたくさんの人が見るものなのでそうはいかず、難しいところではあるかと思います。

やはり、お客様が知っておく必要のあることは、どんな形でも早めに公開し、どんどん情報を更新して、わかりにくい点は個別にお問い合わせいただくよう促し、お客様の利用しやすいものにしていくのがよいのかなと思います。
シェア
赤影
赤影
生まれも育ちもこちらの事業部というサポートスタッフです。平素より筆ペンとGimpを愛用しています。
おすすめの記事