YetiForceCRMは標準で「見積」「請求」「契約」などを管理できるモジュールを備えており、さらにワークフロー(Workflow)機能やアクセス権管理を活用することで、**見積・請求・契約書などの“申請・承認プロセス”**を構築できます。以下では、具体的な手順や設定例を整理してご紹介します。
1. 全体像:承認フロー構築の考え方
承認システムを実装するには、申請対象のデータ(見積や契約書など)に「承認ステータス」や「承認者情報」を持たせ、それを元にワークフローや権限制御で“承認→否認→再申請”などの動きを作ります。大まかな流れとしては、下記のステップで進めるとよいでしょう。
- 対象モジュールの整備
- 見積書や契約書を管理する標準モジュール(例:見積、請求、ドキュメント、プロジェクトなど)を活用、または新規カスタムモジュールで管理対象を定義。
- 承認ステータス用のフィールド設定
- たとえば「Draft(ドラフト)」「申請中」「承認済み」「却下」のようなピックリストを追加する。
- 承認者の割り当て・通知方法の設計
- どの役職・ユーザーが承認権限を持つのか。複数段階の承認が必要かどうか。
- ワークフローによる自動化
- ステータス変更時のメール通知、承認作業完了時の次のフロー自動起動などを設定。
- アクセス権限・監査ログ
- 下書き段階は申請者のみ編集できる、承認後は編集不可、などロールベースで制限。ログを残して改ざんリスクを低減。
2. 対象モジュールの準備
2-1. 標準モジュールを利用する場合
- 見積モジュール / 請求モジュール
YetiForceCRMに最初から備わっている見積書や請求書のモジュールをそのまま使い、必要に応じて以下をカスタマイズするだけで対応可能です。 - 契約モジュール
YetiForceCRM には「サービス契約」や「契約書」管理用のモジュールがある場合があります(バージョンによる)。ない場合は、カスタムモジュールを追加する形で対応できます。
2-2. 新規カスタムモジュールを作る場合
契約書(基本契約・個別契約)を細かく管理したい場合は、カスタムモジュールを作成するのも手です。ノーコードで「契約番号」「契約種別」「契約期間」「承認ステータス」などのフィールドをGUI上から追加し、レイアウトを自由に設計できます。
3. 承認ステータスや関連フィールドの追加
3-1. 「承認ステータス」ピックリストの作成
モジュールの設定画面(レイアウトエディタ等)で、以下のようなステータス項目を追加します。
- Draft(下書き)
- Pending(承認申請中)
- Approved(承認済み)
- Rejected(却下)
承認プロセスが複数段階ある場合は、「一次承認」「二次承認」などステータスを細分化すると、ワークフロー設計がしやすくなります。
3-2. 承認者情報フィールド
承認者が特定のユーザーやロール(役職)である場合、
- 承認担当者フィールド(ユーザーフィールド or リレーション)
- 承認日時フィールド
- 承認コメントフィールド
などを用意しておくと、誰がいつ承認したのか履歴を残せます。
4. ワークフローで承認フローを自動化
YetiForceCRMのワークフロー(Workflow / Business Processes)機能を使うと、ステータスや条件に応じて自動アクションを設定できます。
4-1. 申請時のフロー例
- 申請(Draft → Pending)
- ユーザーがレコードのステータスを「Draft」から「Pending」に変更したら、トリガーが発動。
- ワークフローの設定例
- 条件:ステータスが「Pending」に変更された
- アクション:承認担当者へメール通知(レコードへのリンク、申請内容の明記)
- アクション:レコードの編集権限を申請者から取り除き、承認担当者のみが編集できるように変更(ロールベース権限または共有ルールの更新)
- 承認作業(Pending → Approved or Rejected)
- 承認担当者がレコードを開き、「承認」または「却下」のボタン操作・ステータス変更を行う。
- ワークフローの設定例
- 条件:ステータスが「Approved」に変更された
- アクション:申請者へ“承認されました”のメール通知
- アクション:最終的にPDF化してドキュメントモジュールに自動添付する or システム内で承認済フラグを立てる。
- 条件:ステータスが「Rejected」に変更された
- アクション:申請者へ“却下されました”のメール通知、却下理由を入力するダイアログを表示(カスタム拡張が必要な場合あり)
4-2. 複数段階承認
もし2段階以上の承認が必要な場合は、フェーズを分けたステータスを設計し、それぞれにワークフローを紐づける方法が一般的です。
- 一次承認:ステータス「Pending1」 → 承認担当Aが「Approved1」にするとトリガー
- 二次承認:ワークフローで自動的にステータスを「Pending2」に変更 → 承認担当Bが最終承認
- 最終承認完了:ステータス「Approved2」に遷移 → システム上で承認済フラグを確定
5. アクセス権・共有設定
5-1. ロールベースの権限
承認ステータスに応じて編集可能な人を切り替えるには、ロール&プロファイル機能で細かく権限を設定するのがポイントです。
- 下書き(Draft):作成者(申請者)のみ編集可能。承認者は閲覧のみ。
- 申請中(Pending):作成者は編集不可、承認者が編集可能。
- 承認済み(Approved):承認者以外は編集不可、閲覧のみ。
また、YetiForceCRMには“共有ルール”機能もあるため、特定ステータスのレコードは特定のチーム/ロールのみに公開する、といった柔軟な制御が可能です。
5-2. 監査ログ・変更履歴
YetiForceCRMの**Audit Trail(監査ログ)**を有効化すると、
- 誰がいつステータスを変更したか
- どのフィールドを編集したか
を自動的に記録します。万一の不正承認やトラブル時にログを確認し、原因究明しやすくなります。
6. PDF生成・ドキュメント管理との連携
契約書や見積書を承認後にPDF化して相手へ送付したり、最終的に社内保管する場合、次の方法を組み合わせると効率的です。
- PDFテンプレート機能
- 見積書や請求書をCRMデータから自動作成してPDF出力する。社内用・顧客用など複数パターンのテンプレを作成しておく。
- ワークフローによるPDF添付メール送信
- 承認ステータスに変更後、「PDFを自動生成→顧客へのメールに添付」というアクションを実行する。
- ドキュメントモジュールへの自動登録
- 生成したPDFをドキュメントモジュールに保存し、契約書や見積書として一元管理。必要な権限設定を行い、改ざん・削除を防ぐ。
7. 運用上のヒント
- 承認ボタンやステータス変更をわかりやすく
- ユーザインターフェース上で「承認」「却下」のボタンを追加する(必要に応じてカスタムボタンのスクリプトや拡張が必要)と、現場が操作しやすい。
- 承認依頼・結果通知メールのテンプレート
- ワークフローで自動送付するメール内容をテンプレート化しておき、常に同じ形式で通知できるようにしておく。
- 小さく始めて徐々に拡張
- まずは見積書だけ承認フローを作り、うまく回るようになったら請求書や契約書にも横展開する方法がスムーズ。
- 上限金額・条件分岐
- 一定金額を超えると承認者が変わる、といった条件分岐もワークフローで設定可能。承認フローを最適化し、無駄なやりとりを減らせる。
8. まとめ
YetiForceCRMで見積・請求・契約書などの承認システムを実装するには、下記ポイントを押さえてカスタマイズを行います。
- 対象モジュールに「承認ステータス」や「承認者」などのフィールドを追加
- ワークフローでステータス遷移時の通知・権限切り替え・PDF化・メール送付を自動化
- ロール&プロファイル、共有ルールで編集権限をコントロール
- 監査ログで変更履歴を追跡
- PDF生成やドキュメント管理機能と連携し、社内外への対応を効率化
YetiForceCRMはノーコードで承認フローを設計できるため、複雑なプログラミングなしに柔軟な承認システムを構築できます。運用初期はシンプルな1段階承認から始め、段階的に拡張していくとスムーズに定着し、会社全体のワークフローを効率化できるでしょう。