メインコンテンツにスキップ
Apus Platform
リファレンスワークフロー

繰り返しの仕事は自動で進み、判断が必要な場面では人が決めます。

以下の各ワークフローは、一つの業務エージェントが担当します。御社専用インスタンス内のデータを読み、人の承認が必要な地点で必ず止まります。業務のイメージをつかむためのリファレンスであり、実際の範囲は導入チームと合意のうえで決めます。

リードを選別し、適切な営業担当に引き渡す

新しいリードは既存の顧客レコードに統合され、実データに基づいて評価されたうえで、短い要約とともに担当者へ渡されます。

担当エージェントAmi Sales
開始のきっかけ
CRM に新しいリードが登録されたとき
成果物
要約・優先度・担当者が付いたリード
参照するモジュール
営業・CRMマーケティング
やらないこと
見積、値引き、条件の約束は一切行いません。それは営業担当の役割です。

ステップ

  1. 既存レコードに統合電話番号やメールアドレスが一致するリードは、既存の顧客に統合されます。商談履歴や、接点のあったキャンペーンも引き継がれます。
  2. 評価業種・規模・導入準備の度合いを、御社が承認した基準と照らし合わせて優先度を決めます。
  3. 要約と次の一手の提案ニーズ、背景、未確認の点を数行にまとめ、アプローチの方法を提案します。
  4. 適切な担当者に割り当てリードは既存の割り当てルールに従って振り分けられ、御社が定めたしきい値を超える案件はチームリーダーに知らされます。
実行例
入力

営業時間外に、あるリードから問い合わせが届きます。3 店舗のチェーンを管理するシステムが必要で、まもなく 4 店舗目を開業する予定とのことです。

結果

翌朝、このリードは 3 行の要約、高い優先度、早めの電話を促すメモとともに担当者のリストの最上位にあり、誰も会話を一からやり直す必要がありません。

説明用のシナリオであり、実際のお客様データではありません。

購入後のお問い合わせを受け付け、解決する

お客様からの問い合わせを分類し、注文データや社内ナレッジと照合したうえで、根拠付きの回答案か、要約済みの案件として返します。

担当エージェントAmi Care
開始のきっかけ
購入後にお客様から問い合わせや質問が届いたとき
成果物
出典付きの回答案、または担当者向けに要約された案件
参照するモジュール
営業・CRM文書管理 – EDM
やらないこと
ポリシー外の補償や返品は約束しません。不満を抱えたお客様は必ず人が対応します。

ステップ

  1. 問い合わせを分類状況確認、クレーム、使い方の質問など、種類ごとに御社が定めた経路で処理します。
  2. 既存データで確認顧客履歴、注文、承認済みのガイドを、担当エージェント自身の権限の範囲内で参照します。
  3. 回答を提案回答には出典となる文書を明記します。委任された範囲内なら送信し、範囲外なら当番の担当者を待ちます。
  4. 経緯を添えて引き継ぎ複雑な案件、否定的な論調、守れなくなりそうなサービス上の約束は、履歴一式とともに人に引き継ぎます。
実行例
入力

営業時間外に、週の初めに注文した品物がなぜまだ届かないのかとお客様から問い合わせがあります。

結果

配送データから注文状況にそのまま回答します。お客様が苛立っている様子のため、翌朝一番にサポートチームが対応する優先案件として印を付けます。

説明用のシナリオであり、実際のお客様データではありません。

仕入先請求書:読み取り、三方向照合、仕訳の提案

仕入先の請求書を読み取り、発注書と入庫記録と照合し、経理の承認を待つ仕訳案にします。

担当エージェントAmi Documents
開始のきっかけ
新しい仕入先請求書や証憑が届いたとき
成果物
仕訳案と、確認が必要な不一致行の指摘
参照するモジュール
財務・会計購買在庫・倉庫
やらないこと
不一致の行は計上せず、判読できない証憑を推測で処理することもありません。

ステップ

  1. 証憑を読み取るスキャン画像や PDF の文字を認識し、仕入先・品目・数量・単価を御社の品目マスタと照らし合わせて抽出します。
  2. 三方向照合請求書を、購買モジュールの発注書、在庫モジュールの入庫記録と照合します。
  3. 仕訳を提案一致した行は、三つの元伝票すべてにリンクした仕訳案になります。
  4. 例外を指摘数量や単価の差異、確実に読み取れなかった箇所は、経理の確認キューに回します。
実行例
入力

仕入先の請求書は 50 ケースですが、入庫記録は 48 ケースしかありません。

結果

発注書と一致する 48 ケース分の仕訳案を作成し、2 ケースの差異は関連する三つの伝票とともに指摘して、経理の判断を仰ぎます。

説明用のシナリオであり、実際のお客様データではありません。

定期的な売掛金の督促

記録済みの入金から債権年齢を更新し、承認済みのテンプレートで督促文を作成し、介入が必要な項目は経理責任者に上げます。

担当エージェントAmi Receivables
開始のきっかけ
毎日のスケジュール、または入金状況の変化
成果物
顧客レコード上の督促履歴と、要注意項目のウォッチリスト
参照するモジュール
財務・会計営業・CRM
やらないこと
支払期限の延長、債権の償却、債務の交渉は行いません。

ステップ

  1. 債権年齢を更新記録済みの入金をもとに、各売掛金の期日と年齢区分を再計算します。
  2. リスクを格付け顧客ごとの支払履歴から、早めに督促すべき項目と、人が電話すべき項目を見極めます。
  3. 督促文を作成督促は承認済みのテンプレートと頻度に従い、すべて顧客レコードに保存されます。
  4. 人の対応が必要なものを上げる支払猶予の依頼、通常と異なる項目、遅延を繰り返す顧客は経理責任者に回します。
実行例
入力

本日が期日の請求書に入金記録がありません。この顧客は過去に 2 回、支払いが遅れています。

結果

テンプレートから初回の督促文を作成してレコードに保存します。支払遅延の履歴があるため、この項目は経理責任者のウォッチリストに加わります。

説明用のシナリオであり、実際のお客様データではありません。

朝の経営ブリーフィング

数値はすでに一つのデータ層にあるため、スプレッドシートから集める必要はありません。会議の前にエージェントがブリーフィングを作成して送ります。

担当エージェントAmi Analytics
開始のきっかけ
毎朝、経営会議の前
成果物
主要数値・変化・警告を 1 ページにまとめたブリーフィング(各数値に出典付き)
やらないこと
経営層に代わって結論を出すことも、警告に基づいて自ら動くこともありません。

ステップ

  1. 確定済みの数値を読む前日の売上・在庫・売掛金を、受信者それぞれの権限の範囲内でモジュールから直接読み取ります。
  2. 比較して検知先週や前年同期と比較し、御社が定めたしきい値を超える変化に印を付けます。
  3. ブリーフィングを作成主要数値、動いた点、数値が変わった理由を 1 ページにまとめます。
  4. 適切な相手に送る受信者は自分の担当範囲だけを見ます。支店長が他の支店の数値を見ることはありません。
実行例
入力

毎朝、経営陣の朝会前の決まった時刻。

結果

主要数値、7 日間の比較、2 件の異常をまとめた 1 ページのブリーフィング。各数値にはどのモジュールから取得したかが明記されています。

説明用のシナリオであり、実際のお客様データではありません。

応募書類を要約し、面接に招待する

応募書類を職務記述書の基準に沿って要約します。選ぶのは採用担当者で、エージェントは案内文や返信文の下書きを作成します。

担当エージェントAmi Hiring
開始のきっかけ
採用ラウンドに新しい応募が届いたとき
成果物
基準に沿った要約、人が選んだ候補者リスト、案内文の下書き
参照するモジュール
人事 – HRM
やらないこと
センシティブな基準は使わず、採用・不採用の判断もしません。

ステップ

  1. 応募書類を集約一つの採用ラウンドの応募書類を人事モジュールの一覧にまとめ、重複を統合します。
  2. 基準に沿って要約各応募書類を、職務記述書の承認済み基準に沿って要約します。合否のスコアは付けません。
  3. 候補者は人が選ぶ採用担当者が要約を読み、誰を招待するかを決めます。エージェントが候補者を順位付けすることはありません。
  4. メッセージの下書き面接の案内と、今回見送る応募者への丁寧な返信を下書きし、承認を経てから送信します。
実行例
入力

経理職の採用ラウンドに、1 週間で 40 件の応募が届きます。

結果

同じ 5 つの基準に沿った 40 件の要約。採用担当者が 6 名を選び、案内文は承認待ちの下書きとして用意され、その他の応募者にも返信が用意されています。

説明用のシナリオであり、実際のお客様データではありません。

御社の実際のワークフローを一つ、デモにお持ちください。

サンプルデータで再現します。どのエージェントが担当し、どこで承認のために止まり、監査ログに何が残るのかをご覧いただけます。

noindex