【第4回】Salesforce と DocuSign を連携するには？

DocuSign は契約文書の準備から合意・契約・稟議などにおける一連のワークフローのデジタル化を実現する製品群「DocuSign Agreement Cloud」を提供している米国の企業です。180カ国以上、100万社以上の企業、政府機関や非営利団体が有償版を採用し、ビジネスや日々の生活の中で利用されており、2017年には日本語にも対応しました。DocuSign サービス単体でも契約書の電子署名は可能ですが、Salesforce と連携することでよりシームレスに契約処理を進めることができます。

2023年7月現在、DocuSignと Salesforce が連携できる主なサービスは以下【表1】になります。弊社では、①DocuSign eSignature for Salesforce、②DocuSign Gen for Salesforce を導入し、③DocuSign Negotiate for Salesforce、④DocuSign CLM for Salesforce で実現している内容については、Salesforce のフローとSlack連携で簡易対応しました。

※Salesforce × Slack 連携につきましては、第3回の記事をぜひご参照ください。

次に、Docusign を利用する上で必要な概念について3つ説明します。

1.Envelope（エンベロープ）
　宛名や宛先のEmailアドレスを記載した封筒のようなもの。
　送信都度「ID」が採番され、「完了証明書」もエンベロープ単位に発行される。
　3.GenTemplate を元に作成したファイルや、手元で作成したファイルをアップロードし、顧客に送信する。

2. Envelope Template（エンベロープテンプレート）
　エンベロープ情報をテンプレート化することで、都度の宛名情報の設定を不要にすることができる。

3. Gen Template（ジェンテンプレート）
　Salesforceのレコード値を差し込むことができる、契約書などの書類のテンプレートフォーマット。
　これを活用することで動的な契約書を実現することができる。
　Microsoft Word か DocuSign Agreement Cloud Editorで作成。

下記は、DocuSign の①・②のサービスを利用した、契約書を作成→署名依頼→電子署名のイメージ図です。
このケースでは顧客のみが署名するケースを記載していますが、2名以上の署名も可能です。

まず、【図1】Salesforce × DocuSign の電子署名フローを前提として標準機能を用いて実装した内容を、
【図2】業務フローで表現しましたのでご覧ください。

DocuSign eSignature for Salesforce には多様な機能が搭載されていますが、Salesforce上の操作が苦手な営業担当者や、契約書のテンプレートを管理する法務担当者が混乱しないよう、契約の都度 DocuSign 側で行う作業を極力減らす＝シンプルにすることを前提とし設計しました。（※1）

また、標準の契約オブジェクトを参考にしつつ、カスタムオブジェクトで実装しました。

Salesforceロゴ × DocuSignロゴで表している箱は、Salesforce からシームレスに DocuSign の機能を利用していることを示しています。

Salesforce上で管理している「契約フェーズ」とDocuSign 上の「Envelope Event」を【図3】のように連携しました。それにより、契約書を送付→電子署名完了 or 署名辞退のアクションを Salesforce のフェーズと自動で連携できるようになりました。

また、一定のフェーズのみ、契約書を作成/送信できるよう Lightning アプリケーションビルダーでアクションの表示制御や、作成した契約書の内容と同期が取れるよう入力項目の制御を行っています。

次に、DocuSign Apps Launcher 内での設定内容についてご説明します。

DocuSign 側で行う作業を極力減らすために、下記を選択・活用しました。（②～⑤の番号は【表2】と連動）

　②DocuSign で作成した契約書を自動添付
　③契約オブジェクトから情報を取得・自動設定することで、宛先や宛名、送信元情報を自動入力
　④ユーザによる DocuSign の「フィールドの配置」設定作業を省略
　⑤完了した文書を Salesforce の契約レコードに保存し、Google ドライブにも自動保存

詳細は【表2】エンベロープテンプレートの設定内容をご覧ください。

DocuSign Gen テンプレートでは下記を選択・活用しました。（④～⑦の番号は【表3】と連動）

　④-1.契約オブジェクトの項目を動的表示。項目値次第で指定したブロックの表示非表示を制御
　④-2.署名日の自動表示と署名者欄を設定し、ユーザによる DocuSign の「フィールドの配置」設定作業を省略
　⑤文書ルールを設定し、契約オブジェクトの項目値に応じて読み込む契約書のテンプレートを切り替え
　　＝1つの Gen テンプレートで複数のテンプレート（Wordファイル）を作成することで効率化
　⑦Gen テンプレートをエンベロープに紐づけることで、都度のエンベロープ設定を不要に

詳細は【表3】DocuSign Genテンプレートの設定内容をご覧ください。

弊社固有のカスタマイズとして6点あげられます。

　①契約サービスマスタを用意
　②契約サービス毎にフローで必須項目を制御
　③担当者から上長への契約書の承認依頼を Salesforce×Slack 通知で対応
　④商談オブジェクトに紐づけた販売チャンネル（Slack チャンネル）を契約オブジェクトにコピー
　⑤契約終了日の n 日前に、固定のSlackチャンネルに担当者とカスタマーサポート担当をメンション通知
　⑥契約更新時に内容変更があった場合は、親契約をコピーして子契約の作成が可能。（親子管理を実現）

①～④につきまして、詳細をご説明します。

【図5】【表3】④の Word で作成した テンプレート例に記載しておりますが、契約オブジェクトだけでなく契約サービスマスタを用意したことが挙げられます。

それにより、契約作成時に契約サービス・プランに応じた、最新バージョンの契約内容を初期値として表示することができます。それをベースに契約内容に準じた修正も可能ですし、過去の契約に準じる場合は過去契約をコピーして旧バージョンで作成することも可能です。

また、多少契約サービスやプランの内容が変わっても、大元の契約サービスマスタを修正することでバージョン管理が可能で、Genテンプレートを更新する必要がありません。（【図5】赤枠）

そして、複数のサービスを同一のテンプレートで対応できるようにすることで、
サービスが増える都度、Genテンプレートを用意する手間を省き、工数を削減できるよう設計しました。

この仕組みを採用した背景としては、私自身が構築して感じたのですが、誰もがすぐにEnvelopeやGenテンプレートの仕組みを理解し、設定できるとは思えなかったためです。
そのため、法務担当者が容易に更新・管理ができるようこのような仕組みにしました。

フローを活用して、契約サービス毎に必須項目が入力されているかチェックできるようにし、
そのチェックが通り、かつ、フェーズが「下書き」でなければ、契約書を生成できないようにしました。
それにより項目の入力不足を事前に防いでいます
また、「下書き」以降のステータスでは、一部の項目を除いて、Salesforce 上の項目を変更できないよう制御を加え、締結後のファイルと Salesforce のデータベースの内容が一致するように配慮しています。

契約書を生成後、Salesforce の契約画面から指定したSlackのチャンネル もしくは DMで上長に、承認依頼を通知できるよう、画面フローを実装しました。
上長は契約ファイルURL のリンクをクリックし確認後、契約書のフェーズを「上長承認中」から「上長承認済」に変更する（内容によっては「下書き」に差し戻す）だけで、確認完了となります。
必ずこのフェーズを通さなければ、契約書を送付できないようにすることで、契約書の質を担保しています。

商談を起点とした契約の場合、契約作成のトリガーを商談作成後・販売チャンネル（Slack チャンネル）設定後とし、かつ、商談画面から契約を作成できるようにしました。
そのタイミングで、レコードトリガーフローを用いて、商談オブジェクトに紐づけた販売チャンネル（Slack チャンネル）を契約オブジェクトにコピーしています。

それにより、弊社で契約業務に携わるカスタマーサポート担当者がどのSlack のチャンネルで日常の会話がなされているのか、状況を把握できるようにしました。

では、次に、Salesforce上で実装したフローの一部を【図6】【図7】で紹介します。

次に、Salesforce の DocuSign Apps Launcher で、DocuSign ユーザの追加方法について【図8】で紹介します。
②と③の順序が重要です。逆に行なうと、DocuSign アプリケーションへのアクセス付与が行えませんのでご注意ください。その場合、一度作成した③のユーザを削除して、②のACTIVATE後に再度③のユーザ追加を行う必要があります。

複数の電子署名ツールの中から、サービス単体で利用する時の送信側・受信側のユーザ体験の差はほぼないと言って差し支えない中、下記に優位性を感じ、DocuSign を選定しました。
これから導入される方の参考までに記載します。

・契約者本人名義での電子署名が有効であり本人性の担保、文書の証拠力の観点から法的効力が強い
・日本の電子署名法だけでなくアメリカの電子署名法や統一電子取引法にも準拠している
・SaaSサービスとの連携（API連携）に優れており、クラウド上で契約書ファイルの一元管理が可能
・全て自社で設定・実装が完結するため、契約書のパターンが増える都度外部に開発・実装を依頼しないですみ追加コストが発生しない
・多言語対応しており、国外に強い
・セキュリティも国際規格 ISO 27001:2013等厳しい基準を満たしており、情報漏洩や不正アクセスの危険性も低い
・高可用性を実現。無停止でメンテナンスやアップグレードを行なっており、過去数年の実績稼働率は99.99%以上

eSignature については事前に無料トライアルで試行していたことや、マニュアルが充実しており、設定が比較的容易なため導入支援はつけないケースが多いと伺っていた為、「導入後コンサルとしてのサポートプラン」は契約せず、「カスタマーサポート（Premier Support）」のみ契約しました。

結果、厚みのあるマニュアルやヘルプサイトを元に、ユーザがシンプルに利用できる環境を、
Salesforce × eSignature/Gen サービスで実現するには、お作法的な設定が多々必要で、
更なるトライアルの時間とカスタマーサポートの支援が必要でした。
時間をかけて応対いただき、感謝しております。

DocuSign Gen for Salesforce のサポートの人数も現時点ではあまり多くないようですので、
自社の開発リソースに自信がない場合は、有償の「導入後コンサルサポート」を契約することをお勧めします。
その場合も、DocuSignで何がどこまでできるのか/自社は何を優先したいのかといった点を法務担当者や関係者と事前に擦り合わせることが重要です。

弊社では、第2フェーズとして商談商品明細レコードの内容を元に、Gen テンプレートに差し込めるようにする予定です。

本記事を通して、Salesforce × DocuSign サービス導入の足がかりとなりましたら幸いです。