顧問先対応が増えてくると、いちばん先に限界が来るのは「資料を集める」「状況を伝える」「確認の行き違いを潰す」の3つです。
メール添付が当たり前のままだと、最新版がどれか分からない、未提出が誰なのか見えない、担当者が替わると経緯が消えるが起きがちです。
そこで、顧問先向けに“やること”がまとまったポータルを用意すると、事務所側の消耗がかなり減ります。
顧問先ポータルを失敗させる原因のひとつが、「チャットもファイルも全部ここで」と詰め込みすぎることです。
最初は、ポータルの役割を次に絞った方が運用が安定します。
チャットは既存ツール(Teams/Chatwork等)で足りるケースが多く、最初から抱えない方が現実的です。
顧問先側の画面は、迷わせないのが正義です。基本は次の3画面だけでも回ります。
事務所側が見たいのは、「A社の状況」よりも「未提出がどれだけあるか」「差し戻しが溜まっていないか」です。
そのため、一覧の切り口は“顧問先別”に寄せすぎない方が回ります。
この「一覧で回す」発想は、問い合わせ管理のステータス運用に近いです(考え方だけなら ステータス運用ルール が参考になります)。
顧問先は法人なら担当者が複数います。社長・経理・総務で見たいものが違うこともあります。
そこで、最初から「顧問先=1アカウント」にはしない方が安全です。
税務資料は個人情報も含みます。だからこそ、セキュリティは当然気にしますが、現場が使えない強度にすると放置されます。
現実的には、次を押さえるだけで事故はかなり減ります。
ログ設計の観点は、一般論として 権限・ログ設計 の延長で考えると整理しやすいです。
顧問先ポータルは、豪華な機能より「資料依頼」「提出」「差し戻し」「進捗」の4点を揃える方が先です。
インテンスで作る場合も、最初は“提出物タスク+アップロード+進捗”の骨格を作り、年末調整や期限カレンダー(期限アラート)のような季節業務から拡張する形が相性が良いです。
士業向けの全体像は 士業事務所向けシステム開発例 もあわせて見るとイメージがつきます。