外部サービスのロゴを並べた連携紹介ページは、対応するサービスを探す入口になります。ただし、ロゴだけでは何ができるかまでは伝わりません。営業担当者が「請求サービスと連携できます」と案内しても、検討者は入金状態まで自動で戻ると受け取っているかもしれません。
SaaS・業務用クラウドサービスのWebサイトでは、連携先の名前に加えて、渡すデータ、進む方向、反映のタイミング、利用条件を一組で見せることが大切です。本稿では、製品担当者に確認した仕様を、検討者が読める紹介ページに整える方法を解説します。連携を実装する手順や、システムの選定を扱う記事ではありません。
ロゴの下に「何の手間を減らす連携か」を書く
連携一覧を見ている人は、サービス名だけを確認したいとは限りません。「案件情報を請求書に転記する手間を減らしたい」「申込みが入ったことを担当者に知らせたい」など、片づけたい作業を持っています。ロゴの下には、その連携で扱う作業を一文で添えましょう。
例えば「請求Bと連携」より、「案件管理Aで確定した請求用データを、請求Bへ送る」という説明の方が、何を渡す機能かを読み取れます。ここに「請求業務をすべて自動化」と足すと、請求書の確認や送付、入金の管理まで含む印象になります。紹介文の動詞は、確認できた機能の範囲に合わせます。
通知とデータの同期も分けて説明します。Slackの公式資料では、Incoming Webhooksを外部アプリからSlackへメッセージを送る仕組みとして説明しています。通知を受け取れることから、元のアプリの顧客情報を書き換えられるとは判断できません。掲載する機能が「知らせる」「新しい情報を作る」「既存の情報を更新する」のどれに当たるかを、まず製品担当者と確認します。Slack公式資料
一つの連携を四つの情報で説明する
連携の説明は、対応データ、方向、頻度、制約の四つに分けると整理しやすくなります。ただし、各情報を離れたページに置くと、検討者が都合のよい部分だけを組み合わせてしまいます。紹介ページでは、一つの連携の近くにまとめて掲載しましょう。
対応データは、名称だけでなく操作も確認する
「顧客データに対応」という表現では、会社名と担当者名だけなのか、過去の取引や添付資料も含むのかが分かりません。検討者が判断するために必要な単位まで対象を絞ります。すべての項目を紹介ページに並べる必要はありませんが、業務上の判断を変える対象外の情報は省かないようにします。
さらに、新規作成と更新、削除を区別します。一度送ったデータを修正したときに反映されるか、元のデータを消したら連携先も消えるかは、別の確認事項です。「データ連携」という見出しだけでこれらを一括りにせず、「新規作成のみ」「変更した金額も更新」など、確認済みの操作を添えます。実際の仕様を確認できていない場合は、文章の都合で埋めず、確認待ちとして制作資料に残します。
方向は、どちらからどちらへ渡すかを書く
二つのロゴを線で結ぶだけでは、送信元と受信先が分かりません。「案件管理A → 請求B」のように矢印を付け、その矢印のそばに渡す情報を書きます。見た目の対称性を理由に両矢印を使うと、逆方向にも同じ情報が流れると受け取られるおそれがあります。
双方向に対応する場合も、二本の矢印に分けて対象を書く方法があります。往路は顧客の連絡先、復路は処理状態という仕様なら、それぞれの矢印に別の説明が必要です。双方向という語は、全項目やすべての操作が双方で同じように扱えることまで意味しません。
HubSpotの公式資料でも、データ同期は一方向・双方向の設定に加え、対象のデータやフィールドの対応を扱っています。この例から自社製品の機能を推測するのではなく、「方向だけを示せば説明が終わるわけではない」という確認観点として使います。HubSpot公式資料
頻度は、反映を待つ場面が分かる言葉にする
「自動連携」は、必ずしも操作した直後の反映を意味しません。定時に処理するのか、利用者が送信操作をするのか、一定間隔で更新を確認するのかによって、検討者の運用の見通しが変わります。製品の仕様に合わせて「毎日決まった時刻に送信」「利用者が実行したときに送信」などと書き分けます。
初回に既存データを取り込む処理と、利用開始後に変更を反映する処理も区別します。HubSpotの資料は初回同期と継続的な更新を分けて説明しています。他社サービスで示されている所要時間を自社の目安には使わず、自社で確認できた条件を記載します。処理の開始時点しか確認できていなければ、完了時刻を約束する表現にはしません。
制約は、判断に影響するものを図の近くに置く
連携に必要な契約プランや権限、対象外のデータは、対応範囲を読む段階で分かる位置に置きます。詳細な注意事項へのリンクは残しつつ、利用できるかどうかを左右する条件までリンク先に隠さないようにします。
一方、長い技術資料をそのまま貼り付けると、概要を読み取れなくなります。紹介ページには「対象プラン」「必要な設定」「主な対象外」を短く示し、項目一覧や詳しい設定方法は該当する資料へつなぎます。条件がないように見せるために説明を短くするのではなく、判断に必要な条件を選んで残します。
架空の連携を表と図にするとどう見えるか
次は、案件管理Aから請求Bへ情報を渡す架空の掲載例です。実在する製品の機能や導入事例ではありません。製品仕様として、確定した案件から新しい請求用データを定時に送り、入金状態は戻さないと仮定します。
| 確認する点 | 紹介ページに載せる例 | 読み違いを防ぐ補足 |
|---|---|---|
| 対象データ | 確定した案件の宛名・請求金額 | 商談の履歴と添付資料は含めない |
| 操作 | 請求Bに新しいデータを作成 | 送信後の修正・削除は反映しない |
| 方向 | 案件管理Aから請求Bへ | 請求Bの入金状態は案件管理Aに戻らない |
| タイミング | 毎日決まった時刻に送信 | 確定直後に反映する機能ではない |
| 利用条件 | 対象プランの契約と管理者の接続設定が必要 | 実際のプラン名と設定資料を確認して掲載する |
架空の仕様を使った掲載例。実際の対応範囲は製品担当者への確認が必要です。
図では、中央の矢印に「確定した請求用データ」と記し、下段に「入金状態は戻さない」と置きます。「連携できる」という説明のすぐ近くに、検討者が期待しやすい逆方向の対象外を示すためです。本文でも同じ意味を説明し、図を拡大しなくても要点が伝わるようにします。
この例を自社のページに転用するときは、サービス名だけを差し替えないでください。更新や削除も反映する製品なら操作の説明を変え、手動実行なら定時送信の記述を変えます。表は仕様を決める雛形ではなく、確認した仕様に説明の抜けがないかを見るための枠です。
標準機能と個別の開発を同じ一覧で混ぜない
外部サービスとの接続には、製品に用意された標準の連携機能、ファイルを出し入れする方法、APIを使った個別の開発などがあります。紹介ページでまとめて「連携可能」とすると、契約後すぐ使える機能と、別途の検討や作業が必要なものの違いが見えません。
一覧では「標準連携」「ファイルで受け渡し」「個別確認が必要」など、自社の提供形態に合う区分を付けます。CSVファイルを読み込めるだけなら、自動で継続同期するような矢印や見出しは避けます。APIを公開している場合も、特定のサービスとの接続が完成していることとは区別して説明します。
提供中と予定の違いも、ロゴの横で分かるようにします。公開予定の連携を提供中と同じ見せ方にすると、導入時に使える機能だと受け取られます。予定を掲載するかは社内で判断し、掲載する場合は状態を明記します。公開日が確定していなければ、制作側が日付を補わないようにします。
製品担当者の確認を、ページの更新までつなげる
Web担当者が連携の紹介を直すときは、営業資料、ヘルプ、製品担当者の回答を突き合わせます。「資料では双方向、ヘルプでは一方向」と食い違う場合、読みやすい方の表現を選ぶのではなく、現在の提供条件を確認してから公開原稿に反映します。
確認用の資料には、連携先ごとに担当者、確認日、根拠となるヘルプの該当箇所を残します。ページ上にも必要に応じて対応条件の確認時点を添えますが、日付を入れただけで最新性が保たれるわけではありません。製品側で対象データやプランが変わったときに、Webの説明を見直す連絡先を決めておきます。
概要からのリンクも点検します。「詳しくはこちら」でヘルプの入口へ戻すより、「対応する項目」「接続に必要な権限」など、知りたい内容が分かるリンク名で該当資料へ案内する方が、確認を進めやすくなります。閲覧にログインが必要なら、そのことも分かるようにします。
連携の一覧と個別の紹介、ヘルプで同じ条件を何度も書く場合は、どの資料を基準に更新するかを決めます。概要だけ古いまま残ると、詳しい資料を読む前の判断がずれてしまいます。製品側の変更通知を受けたら、ロゴ一覧の短い説明、図の矢印、対象外の注意書きまで見直せるようにします。
対応表で判断できない条件を相談へつなげる
概要を読んでも、自社の使い方に当てはまるか決められない人はいます。例えば同じ請求サービスを使っていても、送りたい項目や実行する回数が標準の範囲と異なることがあります。ページの末尾には、個別確認が必要な場合の相談先と、確認に役立つ情報を短く添えます。
相談前に整理してもらうのは、利用中のサービス名、どちらからどちらへ情報を渡したいか、対象データ、期待するタイミングなどです。架空例であれば「請求Bの入金状態を案件管理Aへ戻したい」という希望が分かれば、掲載済みの標準連携とは異なる相談だと切り分けられます。「連携について」という大きな選択肢だけより、希望する受け渡しを記入できる説明が役立ちます。
ただし、相談を受け付けることと、希望どおりの対応を約束することは別です。個別開発や追加費用の要否が未確認なら、「実現方法と対応可否を確認する」など、実際の受付範囲に合わせた案内にします。制作側が「どんなサービスでも連携可能」と補わないようにします。
最初の問い合わせで接続用の秘密情報や実データの提出を求める必要もありません。まず希望する情報の種類を把握し、詳細資料が必要になった場合は、製品側で定めた窓口と手順へつなぐ構成にします。紹介ページの役割は、仕様の確認に進むための条件をそろえることです。
公開前に、読み手が答えを見つけられるか確かめる
文章の誤字だけでなく、検討者が持ちそうな質問でページを読み直します。先ほどの架空例なら、「請求Bに入金を登録したら案件管理Aにも反映されるか」「送信後の金額修正は反映されるか」「案件を確定するとすぐ請求Bに届くか」の三問です。これは確認手順の例であり、実際に利用者テストを行った結果ではありません。
製品に詳しくない社内の人に読んでもらえる場合は、回答だけでなく、どこを読んで判断したかも確かめます。逆方向の説明が見つからなければ図の近くへ移し、「自動」という語だけで即時と解釈されたらタイミングの説明を直します。読者の理解不足と片づけず、判断の根拠になる情報の置き方を見直します。
スマートフォンでは、図の文字と表の読み順も確認します。横に長い図で注意書きだけ小さくならないようにし、表が横に動く場合は列をたどれる表示にします。画像だけで対象外を説明せず、直前か直後の本文にも書いておくと、狭い画面でも対応範囲を確認できます。
SaaSの連携説明を、導入前に確認できるページへ
外部連携の紹介ページは、対応ロゴを増やすだけでなく、何がどちらへ、いつ、どの条件で渡るかを読める形に整えることが重要です。まず問い合わせで認識のずれが起きやすい連携を一つ選び、製品担当者と四つの情報を確認すると、改修の範囲を定めやすくなります。
みやあじよでは、SaaS・業務用クラウドサービスのWebサイトについて、連携ごとの説明や範囲図、導入前の確認項目を整理する制作をご案内しています。ロゴは並んでいても対応範囲が伝わらない場合は、SaaS・業務用クラウドサービス向けホームページ制作をご覧ください。現在の紹介ページと確認済みの仕様資料を基に、Webで説明する内容を整理できます。
