顧客から提出してもらう書類から始める
顧客ポータルを使うと、顧客が書類を提出し、作業の進み具合や次の対応を確認できます。事務所に専用ポータルが必要かどうかは、実際の業務と閲覧できる人によって変わります。安全なファイル共有で十分な場合もあります。既存の業務管理製品を適切に設定すれば、一連の流れをカバーできることもあります。
選ぶ前に、チームから顧客へ送る依頼が、顧客の対応を経てチームに戻るまでをたどってください。届いた書類を確認する担当者も含めます。アップロードボタンだけでは、その仕事の一部しか解決しません。
仮の例として、同じ顧客組織に二つの案件があるとします。経理担当者は案件Aの書類を提出し、別の権限を持つ担当者は案件AとBの両方を管理します。経理担当者には案件Aで必要な資料を見せる一方、案件Bは見せないようにします。同じ顧客組織に所属していることだけでは、同じアクセス権を持つ根拠にはなりません。
依頼から修正までをたどる
チームの担当者が経理担当者に案件Aの書類を依頼します。何が必要か、どの案件に関係するか、質問がある場合の連絡先を依頼に記します。顧客にもう一度入力を求める前に、事務所がすでに持っている情報を確認します。確認や更新が必要なら、その理由を明確に伝えます。
顧客がファイルをアップロードした後、職員側では何が起こるでしょうか。誰かが到着に気づき、正しい案件を開いて、依頼内容を満たしているか確認する必要があります。ページが一つ不足していたとします。確認担当者が修正内容を分かりやすく伝え、顧客が揃った版を提出します。
ここで両者に最新の版を探してもらいます。顧客は差し替え版が届いたと分かりますか。確認担当者はそれを不完全なファイルと区別できますか。以前の版をどれだけ残すか、誰が見られるか、業務上いつまで必要かを決めてください。
「アップロード済み」はファイルが届いたという意味です。「確認済み」と「受理済み」はその後の判断を表します。それぞれの状態の意味を明確にし、次の対応を誰が担うか決めてください。
その後の流れも確認します。確認担当者が受理するか、再度修正を依頼し、顧客が次に何をすればよいか分かる状態にします。通知に失敗したときや、通常の確認担当者が対応できないときに、誰が未処理の仕事に気づき、引き継ぐのかも決めてください。日常的な中断にもポータル側の答えが必要です。
一人ひとりが何を見られるかを決める
経理担当者、両方の案件を管理する担当者、対応する職員それぞれのアクセス範囲を書き出します。書類、メッセージ、状況、ダウンロードも含めてください。例に別の顧客組織を加え、その組織の資料がどちらの担当者にも表示されないことを確認します。
顧客に見せる情報も決めます。顧客はチームが書類を確認中だと分かればよく、社内での話し合いまで見る必要がない場合があります。内部の案件記録全体を公開すると、顧客に不要な情報まで見せてしまうことがあります。共有する情報と、その正確さを保つ方法を選んでください。
ログインにより本人を確認できます。それでも、どの案件やファイルを閲覧できるかというルールが必要です。たとえば Microsoft のPower Pages のセキュリティ概要では、本人確認、Webロール、ページ権限、基盤となるレコードの権限を区別しています。これは一つの提供元による制御の説明であり、その製品の購入を勧めるものではありません。
メニューに表示されないページにもURLがある場合があります。ファイルに直接ダウンロードリンクがあることもあります。ポータルを閲覧しているときだけでなく、ページやファイルを直接リクエストされたときにもアクセスルールが適用される必要があります。
Microsoft のセキュリティのベストプラクティスは、サーバー側の認可とファイルの直接ダウンロードを明確に扱っています。提案された設定が顧客組織と案件の境界をどう守るのか、提供元に確認してください。画面が整っていることやログインに成功することだけでは確認になりません。
三つの選択肢に同じ仕事をさせる
上の依頼、不完全な提出、修正という例を使って選択肢を比較します。どのデモでも必要なアクセス権と職員の作業を同じにしてください。一方の製品では単なるアップロード、別の製品では一連の確認作業を比べると、公平に評価できません。
安全な共有を続ける
主なニーズが少数の明確な書類のやり取りなら、この方法で足りる可能性があります。それに加え、依頼、修正、最新版、権限を職員がどう管理するかも示してもらい、比較に含めてください。
既存ポータルを設定する
業務管理製品または顧客ポータルの提供元に、提案された設定で一連の流れを実演してもらいます。組織ごと、案件ごとの権限が合っているか、変更に継続的な支援が必要かを確認します。
個別開発を依頼する
適した既存製品でも業務の重要な部分やアクセスルールを満たせない場合は、個別開発を検討します。何が不足しているか、導入後にどのような保守が必要かを合意前に明確にしてください。
双方にかかる作業時間を数えます。顧客にとって使いやすい画面でも、職員がアップロードのたびに別のシステムへコピーしているかもしれません。社内の手順を一つ変えるだけで、既存製品が依頼を十分扱えることもあります。ポータルの機能数だけで判断せず、こうした違いを記録してください。
英国政府の技術調達ガイダンスでは、利用者のニーズ、既存製品、継続費用、購入した製品を支える能力を検討します。事務所にとっても参考になる問いですが、英国政府の調達要件があなたの購入に自動的に適用されるわけではありません。
架空のデータで、許可された範囲のデモを行う
合意したテスト範囲のもとで、別のテスト環境に架空の顧客、案件、書類を設定してもらいます。各担当者と職員の役割に対応するアカウントを使います。実際の顧客情報や、本番の顧客への操作はテストに使いません。
経理担当者が許可された案件Aの資料を開ける一方、案件Bや別の顧客組織の資料は開けないことを示してもらいます。両方の案件を担当する人は、それぞれで合意した資料にアクセスできる必要があります。権限外のページやダウンロードリンクを直接開こうとしたとき、想定どおり拒否されることも確認します。提供元は、許可されたテストの中でこれらを準備し、実演してください。
次に、ページ不足の修正を最後まで行います。顧客役と職員の確認担当者に依頼を探してもらい、差し替え版を提出し、最新のファイルを識別して、次に誰が対応するか説明してもらいます。顧客側の権限を持つ担当者が変わった場合も試し、前任者が不要になったアクセスを失うことを確認します。
うまくいったこと、失敗したこと、専門家の確認が必要なことを記録してください。範囲を限定したデモは、提案された流れとアクセスルールの不足を見つける助けになります。ただし、ポータル全体の安全性を認証するものでも、あらゆる顧客情報を登録すべきだと示すものでもありません。
導入後の担当者を決める
新しい顧客アカウントの承認、案件アクセスの変更、権限の削除を誰が行うか決めます。誤ったファイルの報告、通知の失敗、ポータルを利用できない場合の担当者も決め、解決まで緊急の業務をどう続けるか確認します。ソフトウェアを保守し、変更後に権限を点検する人も確認してください。
終了時の対応も尋ねます。保存が必要な書類、メッセージ、有用な履歴、案件との関連情報について、サンプルのエクスポートを求めます。案件や契約が終わった際、アカウント、保存されたコピー、アクセス権がどうなるか確認してください。安全な共有、設定済みの製品、個別開発のどれを選ぶ場合も、契約条件と継続作業を比較します。
専門サービス事務所の購入要件では、実演した業務の流れを明確にすることが大切です。誰が何を依頼し、誰が閲覧でき、どう修正し、次に誰が対応するのかを記します。職員の時間と継続的な保守も含め、その流れを許容できる形で支える選択肢を選んでください。重要な不足を個別開発ソフトウェアで埋める必要があれば、その範囲を相談できます。ライセンス、引き渡し、サポート、取引条件は案件ごとに合意します。
顧客ポータルを選ぶ前によくある質問
安全なファイル共有だけで十分なことはありますか?
あります。必要な書類交換とアクセス範囲を満たし、職員が依頼、修正、版、次の対応を確実に管理できるなら十分かもしれません。ポータルが必要だと決める前に、全体の流れを実演してください。
顧客のログインだけで案件を分けて管理できますか?
できません。本人のログインと、特定の案件やファイルを閲覧する権限は別です。担当者ごとのアクセス範囲を定義し、架空のデータを使って、直接のページやダウンロードリンクを含め、許可された範囲で確認します。デモは全体の安全性を認証するものではありません。
不足のあるアップロードは誰が処理しますか?
提出内容を確認し、必要な修正を説明し、受理した版を識別する職員を決めます。顧客に次の流れを伝え、確認担当者が対応できないときや通知に失敗したときの引き継ぎ先も決めてください。