SoRからSoAへ：レコードを持つ企業が「次の行動」へ移行する設計
SoRからSoAへ移行する時代になるとして、既存の顧客レコード、案件レコード、請求レコード、問い合わせ履歴を持っている企業は、何から始めればよいのでしょうか。
前提として、SoRは捨てません。
移行の本質は「記録システムを置き換える」ことではありません。SoRを信頼できる事実源として残したまま、その上に「次に何をするか」を決めて実行する SoA層 を作ることです。
この記事では、SoAを System of Action として扱います。CRMや業務システムに保存されたレコードを、実際の業務アクションへ変換するための設計です。
要点: SoR中心の会社は「データを正しく持つ」ことがゴールでした。SoA中心の会社は「正しいタイミングで正しい行動が起きる」ことがゴールになります。
私が考えていること
最近、CRMというものを、単なる「顧客管理ツール」として見るのは少し狭いのではないかと考えています。
CRMは本来、会社が顧客と出会い、話し、提案し、失敗し、学び、また次の関係を作っていくための 企業の記憶装置 です。
顧客名や電話番号を保存するだけなら、CRMは台帳です。けれども、本当に大事なのは、その顧客とどんな会話をして、何に困っていて、前回どんな判断をして、次に何をすべきなのかが、会社の中に残っていることです。
人が辞めても、担当が変わっても、会社として顧客との関係を思い出せる。さらに、その記憶をもとに次の行動が起きる。これが、これからのCRMの役割だと思っています。
つまり、CRMは「記録する場所」から「行動を起こすための記憶装置」へ変わっていくべきです。
移行設計の全体像
SoRからSoAへの移行は、次の5つに分けると整理しやすくなります。
- レコード: 判断に使う事実を特定する
- 判断条件: そのレコードが業務上どんな状態を意味するか決める
- 推奨アクション: 次に取るべき行動を出す
- 実行先: メール、Slack、CRM、LINE、請求システムなどへつなぐ
- 成果指標: 実行した結果を見て、次の改善に戻す
この流れを作ると、CRMは「記録を見る場所」から「次の行動を動かす場所」へ変わります。
1. SoRを棚卸しする
最初にやることは、SoRを捨てることではなく、既存のレコードを棚卸しすることです。
たとえば、次のようなレコードがあります。
- 顧客レコード
- 案件レコード
- 商談レコード
- 請求レコード
- 契約レコード
- 在庫レコード
- 問い合わせ履歴
- 対応履歴
ここで重要なのは、データ項目そのものよりも、各レコードが業務上どんな状態を意味するかです。
たとえば「最終連絡日」という項目は、単なる日付ではありません。営業フォローの文脈では「次回連絡すべきか」を判断する材料になります。
「請求期限」は、単なる日付ではありません。経理業務では「督促すべきか」「担当者に確認すべきか」を判断する材料になります。
SoA化では、レコードをデータとして眺めるのではなく、行動の起点として見直します。
2. レコード単位ではなく、業務アクション単位で見る
SoRの発想では、「どの情報を保存するか」が中心になります。
SoAの発想では、「その情報から何をするか」が中心になります。
たとえば、同じCRMの顧客レコードでも、SoAでは次のように見ます。
| SoRにあるレコード | SoAで考える問い |
|---|---|
| CRMの顧客レコード | 次回連絡すべきか |
| 商談レコード | 見積、フォロー、失注防止のどれをすべきか |
| 請求レコード | 督促すべきか、社内確認すべきか |
| 問い合わせ履歴 | エスカレーションすべきか |
| 契約レコード | 更新案内や条件確認をすべきか |
| 在庫レコード | 発注、販売停止、代替提案のどれをすべきか |
この変換ができると、SoRは単なる台帳ではなく、SoAの判断材料になります。
3. 最初は「提案」から始める
SoA化というと、すぐに自動実行を想像しがちです。
しかし、最初から完全自動化する必要はありません。むしろ、最初は 提案 から始めるほうが現実的です。
たとえば、AIやルールエンジンが次のように出します。
- この顧客は30日間フォローがないため、連絡を推奨
- この請求は期限を過ぎているため、確認タスクを推奨
- この問い合わせは重要顧客からの内容のため、担当者への通知を推奨
- この商談は見積提示後に動きがないため、フォロー文面の作成を推奨
最初の段階では、AIやシステムが推奨し、人間が承認して実行します。
この形にすると、現場は「何を勝手にされるかわからない」という不安を持ちにくくなります。また、どの提案が有効で、どの提案が不要だったかを学習できます。
4. Action Ledgerを作る
SoAでは、「何が記録されているか」だけでは不十分です。
重要になるのは、誰が、いつ、なぜ、そのアクションを起こしたかです。
そのため、SoRとは別に Action Ledger のような履歴を持つべきです。
Action Ledgerには、たとえば次の情報を残します。
- 対象レコード
- 判断条件
- 推奨されたアクション
- 推奨した主体
- 承認した人
- 実行された日時
- 実行先
- 実行結果
- 次に取られた行動
これがあると、SoAの品質を検証できます。
どの推奨が採用されたのか。どの自動実行が成果につながったのか。どの条件は誤判定が多かったのか。こうした改善ができるようになります。
SoAは一度作って終わりではありません。実行結果を見ながら判断条件とアクションを改善する仕組みです。
5. API経由で実行できる業務から自動化する
SoA化では、実行先が重要です。
いくら良い推奨アクションを出しても、実行する経路がなければ業務は動きません。
最初は、APIや標準連携で実行しやすい業務から始めるのが現実的です。
- メール送信
- Slack通知
- CRM更新
- タスク作成
- 請求リマインド
- LINE送信
- カレンダー登録
- チケット作成
このような実行先がある業務は、SoA化しやすいです。
逆に、実行が人の口頭確認や紙の書類に依存している業務は、まず実行経路を整える必要があります。
移行レベルで考える
SoAへの移行は、成熟度を5段階で見るとわかりやすくなります。
| レベル | 状態 | 説明 |
|---|---|---|
| Level 1 | SoRを見るだけ | レコードはあるが、次の行動は人が個別に判断する |
| Level 2 | 次アクションを提案する | AIやルールが推奨アクションを出す |
| Level 3 | 人間の承認後に実行する | 担当者が承認すると、メール、通知、タスク作成などが実行される |
| Level 4 | 条件を満たすものだけ自動実行する | 低リスクで条件が明確な業務だけ自動化する |
| Level 5 | 結果を見て次の行動まで回す | 実行結果をもとに次の判断条件やアクションを更新する |
多くの企業は、Level 1からLevel 2、Level 3へ進むだけでも大きく変わります。
最初からLevel 5を目指す必要はありません。まずは、人間が承認する前提で「提案の質」を上げることが大切です。
Zohoだと、こう実現する
Zohoでこの考え方を実現するなら、まず Zoho CRMを企業の記憶装置の中心 に置きます。
顧客、商談、問い合わせ、活動履歴、担当者、ステータス、次回アクションをCRMに集めます。ここがSoRです。つまり、Zoho CRMは「正しい事実を置く場所」として使います。
その上で、SoA層を少しずつ作ります。
| 役割 | Zohoで使うもの |
|---|---|
| 記録を残す | Zoho CRM |
| ステータスに応じて動かす | Workflow |
| 業務手順を標準化する | Blueprint |
| 複雑な条件や外部連携を処理する | Functions / CRM API |
| 問い合わせ接点を作る | SalesIQ |
| 補助画面や業務アプリを作る | Creator |
| 予約や面談へつなげる | Bookings |
| データ整理や提案を補助する | Zia |
| エージェントとして業務を動かす | Zia Agents / Agent Studio |
たとえば営業フォローなら、次のように作れます。
- 商談、顧客、最終接触日、ステージをZoho CRMに残す
- 見積提示後に一定期間動きがない商談をWorkflowで検知する
- Ziaやルールで次のフォロー内容を提案する
- 担当者にCRMタスクや通知を出す
- 必要であればメール下書きや面談予約へつなぐ
- 実行結果をCRMの活動履歴やAction Ledgerに戻す
問い合わせ対応なら、SalesIQやフォームから入った内容をCRMに残し、AIで要約し、重要度や担当者を補助判定し、必要なタスクを作る流れになります。
採用や面談のような業務なら、SalesIQ、CRM、Creator、Bookings、外部AI APIを組み合わせて、候補者対応、内容整理、担当者通知、次回予約までを一つの業務フローにできます。
大事なのは、最初から全部を自律実行させないことです。まずは、CRMに残す、AIが整理する、人が確認する、承認後に実行する。この順番で作るのが現実的です。
Zohoだけではない動きも出てきている
一方で、こうした考え方はZohoだけの話ではありません。
いまは、CRM、カスタマーサポート、営業支援、業務自動化、ナレッジ管理の領域で、AIエージェントを前提にした新しいツールが次々に出てきています。
これまでのSaaSは、人間が画面を開き、項目を入力し、ボタンを押すことを前提にしていました。これからは、AIエージェントがレコードを読み、状況を判断し、必要なアクションを提案し、一部の業務では実行まで進める設計が増えていくはずです。
つまり、これからの競争は「どのCRMを使うか」だけではありません。
どのシステムを事実源にするのか。どのAIに何を読ませるのか。どこまで自動実行させるのか。どこで人間が確認するのか。実行結果をどう記憶として戻すのか。
この設計そのものが重要になります。
私はZohoを中心に実装していますが、Zohoだけを見ていればよいとは考えていません。AIエージェント、Agent Studio、Copilot系の仕組み、業務アプリ生成、RAG、ナレッジ管理、ワークフロー自動化など、周辺の動きも日々学んでいます。
ZohoでできることはZohoで堅実に作る。Zohoでは足りない部分や、より適した外部ツールがある部分は、APIや連携を前提に考える。
この姿勢が、これからのCRM/AI設計では大事だと思っています。
最初に選ぶべき業務
移行戦略としては、全社変革から始めないほうがよいです。
まずは、レコードはあるのに行動が遅れている業務を1つ選びます。
候補になりやすいのは、次のような業務です。
- 営業フォロー
- 未回収請求
- 問い合わせ対応
- 休眠顧客の掘り起こし
- 見積後フォロー
- 契約更新案内
- 採用候補者対応
選ぶ基準はシンプルです。
「データはある。でも、そのデータから次の行動が安定して起きていない」
この条件に当てはまる業務は、SoA化の効果が出やすいです。
1枚で整理する
最初の具体アクションは、対象業務を1つ選び、次の形で1枚に整理することです。
| 項目 | 書くこと |
|---|---|
| レコード | 判断材料になるSoR上のデータ |
| 判断条件 | どの状態なら動くべきか |
| 推奨アクション | 次に何を提案するか |
| 実行先 | どのシステム、チャネル、担当者へつなぐか |
| 成果指標 | 実行後に何を見て良し悪しを判断するか |
たとえば営業フォローなら、次のようになります。
| 項目 | 例 |
|---|---|
| レコード | 商談、顧客、最終接触日、ステージ、見積日 |
| 判断条件 | 見積提示後7日以上動きがない |
| 推奨アクション | フォローメール案を作成し、担当者へ確認依頼 |
| 実行先 | CRMタスク、メール下書き、Slack通知 |
| 成果指標 | 返信率、次回商談化、失注理由の回収率 |
この1枚ができると、SoA化はかなり具体的になります。
この記事のポイント
- SoRは捨てない。信頼できる事実源として残す。
- CRMは、顧客管理ツールというより企業の記憶装置として考える。
- 移行の本質は、SoRの上にSoA層を作ること。
- レコード単位ではなく、業務アクション単位で設計する。
- 最初は自動実行ではなく、推奨アクションの提案から始める。
- 誰が、いつ、なぜ実行したかを残すAction Ledgerが必要。
- ZohoではCRM、Workflow、Blueprint、Functions、Creator、SalesIQ、Bookings、Zia系機能を組み合わせる。
- Zoho以外にも新しいAIエージェント系の仕組みが出てきているため、日々学びながら設計を更新する。
まとめ：SoA化は「正しい行動が起きる会社」への移行
SoR中心の会社は、データを正しく持つことを重視してきました。
しかし、これから重要になるのは、正しいデータを持っているだけではなく、そこから正しいタイミングで正しい行動が起きることです。
SoRからSoAへの移行は、既存システムの置き換えではありません。
SoRを事実源として残し、その上に判断条件、推奨アクション、実行先、成果指標をつなぐことです。
そして、その実装先としてZohoはかなり現実的な選択肢です。Zoho CRMを記憶の中心に置き、WorkflowやBlueprintで業務手順を整え、FunctionsやAPIで外部とつなぎ、ZiaやZia Agentsで提案や実行を少しずつ補助していく。
ただし、Zohoだけで世界が閉じるわけではありません。AIエージェントを前提にした新しいツールや設計思想は、今も次々に出てきています。
だからこそ、Zohoでできることを堅実に実装しながら、周辺の新しい動きも学び続ける。そうやって、顧客との記憶が次の行動につながる会社を作っていきたいと考えています。
著者: 泉田幸太郎
最終更新: 2026年5月5日
