kintone業務設計研究所 > メールワイズとkintone連携の設計方法|顧客対応履歴を業務DBに残す
2026年6月12日
•約17分で読めます
メールワイズとkintoneを連携するときに、顧客管理アプリ、メールテンプレート、個別送信、一斉送信、メール履歴、担当者、対応ステータス、配信対象抽出、対応漏れ防止をどう設計するか整理します。
メールワイズとkintoneを連携すれば、顧客管理とメール対応はかなり楽になりますか。
連携は有効ですが、メールワイズを「メール対応の実行場所」、kintoneを「顧客・案件・対応履歴の業務DB」として分けないと、送信履歴は見えても業務判断に使えない状態になります。
メールワイズとkintoneを連携したい会社では、すでにメール対応に課題があることが多いです。
代表アドレスに問い合わせが届く。
複数人で返信する。
過去のやり取りを見ながら対応したい。
kintoneの顧客情報からメールを送りたい。
キャンペーンや更新案内を対象者にまとめて送りたい。
顧客詳細画面で、メールワイズの送受信履歴を見たい。
こうした要望は自然です。
ただし、連携プラグインを入れるだけでは、顧客対応の運用は整いません。
メールワイズは、複数人でメールを処理する場所です。
kintoneは、顧客、案件、問い合わせ、契約、対応状態を管理する場所です。
連携で大事なのは、両方を混ぜることではありません。
メールワイズで行った送受信を、kintoneの顧客・案件・問い合わせの文脈で使えるようにすることです。
メールワイズとkintone連携で最初に決めるべきなのは、メールを送れるかではなく、メール対応の結果をどの顧客・案件・問い合わせに戻すかです。
この記事では、メールワイズとkintone連携を、設定手順ではなく、顧客対応を業務DBに残す設計として整理します。
kintone顧客管理の設計方法はこちら
kintone問い合わせ管理の設計方法はこちら
kintoneメール送信の設計方法はこちら
kintoneメール配信の設計方法はこちら
メールワイズとkintone連携では、まず役割を分けます。
| 領域 | メールワイズの役割 | kintoneの役割 |
|---|---|---|
| 受信メール | 代表アドレスの受信、担当者、処理状況の管理 | 顧客、問い合わせ、案件との紐づけ |
| 返信・個別送信 | 実際のメール作成、返信、送信 | 宛先、顧客属性、案件状態、送信根拠の管理 |
| 一斉配信 | メール本文の作成、送信処理 | 対象者抽出、配信可否、配信後の状態管理 |
| メール履歴 | 送受信したメールの蓄積 | 顧客詳細、案件詳細、問い合わせ判断への表示 |
| テンプレート | メール文面として利用 | テンプレート種別、利用条件、承認状態の管理 |
| 対応管理 | 処理状況、担当者、コメント | 顧客対応ステータス、次回対応、未対応一覧 |
メールワイズ公式サイトでは、複数人で共有メールを扱い、処理状況や担当者、コメントを使ってメール対応を管理できる機能が紹介されています。
サイボウズのkintone連携ページでは、kintoneの顧客情報から個別送信、一斉送信、メール履歴表示、メールテンプレート管理ができることが整理されています。
この2つを合わせると、メールワイズは「メール対応の実行場所」として強く、kintoneは「顧客と業務状態の正本」として強いことが分かります。
たとえば、顧客からの問い合わせに返信する場合、メール本文を書くのはメールワイズでよいです。
しかし、その問い合わせがどの顧客の、どの契約の、どの案件に関するものかは、kintone側で管理したほうが扱いやすいです。
顧客対応を後から見る人は、メール単体ではなく、顧客・案件・問い合わせの文脈で見ます。
だから、メール履歴をただ表示するだけでは足りません。
顧客レコード、案件レコード、問い合わせレコードに、メール対応がどう影響したかを戻す必要があります。
メールワイズとkintone連携の土台は、顧客管理アプリです。
kintone公式ヘルプでは、メールワイズ連携プラグインを設定する前に、顧客情報を管理するアプリと、メールテンプレートを管理するアプリを用意する流れが説明されています。
顧客管理アプリには、少なくとも次の項目を持たせます。
| 項目 | 目的 |
|---|---|
| 顧客名 | 会社名、個人名、店舗名などの表示 |
| メールアドレス | 個別送信、一斉送信、履歴紐づけのキー |
| 担当者 | 社内担当、引き継ぎ先 |
| 顧客区分 | 既存、見込み、契約中、休眠など |
| 配信可否 | 一斉送信してよいか |
| 配信停止日 | 停止依頼や対象外の根拠 |
| 関連案件 | どの案件、契約、問い合わせと関係するか |
| 最終対応日 | 最後に対応した日 |
| 次回対応日 | 次に連絡すべき日 |
| 重要メモ | メール本文に直接出さない社内メモ |
メールアドレスだけを持つ顧客アプリでは、後から運用が詰まります。
一斉送信では、配信対象を抽出する条件が必要です。
個別送信では、送ってよい宛先か確認する条件が必要です。
メール履歴表示では、どの顧客に紐づく履歴なのかを判断するキーが必要です。
顧客管理アプリを作るときは、次の観点で重複を減らします。
メールワイズ連携は、顧客情報の品質に強く依存します。
宛先が間違っていれば、どれだけ連携が正しくても誤送信になります。
メールワイズ連携の品質は、メールワイズ側の機能よりも、kintone顧客管理アプリの宛先・配信可否・担当者・重複整理で決まります。
メールワイズ連携では、メールテンプレートアプリも重要です。
テンプレートを使えば、件名や本文を標準化できます。
しかし、テンプレートをただ増やすと、どれを使えばよいか分からなくなります。
メールテンプレートアプリには、次の項目を持たせます。
| 項目 | 目的 |
|---|---|
| テンプレート名 | 担当者が選ぶ名称 |
| 利用場面 | 初回返信、資料送付、見積提出、催促、完了連絡など |
| 件名 | メール件名 |
| 本文 | 本文の基本形 |
| 差し込み項目 | 顧客名、案件名、担当者名、期限など |
| 利用条件 | どの顧客区分、案件状態で使えるか |
| 承認状態 | 下書き、利用中、停止、廃止 |
| 更新日 | 文面の最終更新日 |
| 管理者 | 文面を管理する責任者 |
サイボウズの機能ページでは、メールテンプレートを利用してkintoneの顧客情報を差し込んだメールを作成できることが説明されています。
差し込みは便利ですが、危険でもあります。
顧客名、会社名、案件名、金額、期限の差し込みが間違うと、そのまま顧客へ送られます。
そのため、テンプレートには利用条件と承認状態を持たせます。
たとえば、見積提出テンプレートは「見積承認済み」の案件でだけ使う。
更新案内テンプレートは「配信可」の顧客だけに使う。
催促テンプレートは、支払期限や回答期限が設定されているレコードでだけ使う。
このように、テンプレートは文面ではなく、業務条件とセットで管理します。
メールワイズとkintone連携では、個別送信と一斉送信を分けます。
| 送信方法 | 向いている用途 | kintone側で決めること |
|---|---|---|
| 個別送信 | 顧客別の問い合わせ返信、資料送付、見積提出 | 顧客、案件、送信理由、テンプレート |
| 一斉送信 | お知らせ、更新案内、セミナー案内、休業連絡 | 対象条件、除外条件、配信可否、送信後状態 |
| 手動返信 | 受信メールへの返信、個別事情が強い対応 | 対応履歴、担当者、次回アクション |
| 定型返信 | よくある問い合わせ、受付完了、完了報告 | 利用条件、差し込み項目、確認者 |
メールワイズFAQでは、kintone連携で、kintone上の顧客に個別メールを送る、一斉配信する、顧客詳細画面で送受信履歴を表示する、といった連携内容が説明されています。
メールワイズFAQ:kintoneとメールワイズではどのような連携ができますか
また、同FAQでは、一斉配信について一度に配信できる件数が1,000件までと案内されています。
このような上限や利用条件は、送信設計に影響します。
たとえば、顧客数が多い場合は、対象を分割する必要があります。
配信対象をkintoneの一覧で抽出する場合は、一覧条件の名前、作成者、更新権限を管理します。
一斉送信では、次の項目を必ず設計します。
個別送信では、顧客の個別事情を見ながら送ります。
一斉送信では、条件に合う顧客へ同じ文面を送ります。
この違いを曖昧にすると、「個別に確認すべき内容を一斉送信してしまう」「一斉送信でよい案内を個人ごとに手作業する」というズレが出ます。
メールワイズとkintoneを連携する大きな目的のひとつは、顧客詳細画面でメール履歴を確認できることです。
ただし、履歴表示だけでは足りません。
メール履歴を、次の判断に使える形にします。
| 判断 | 見るべき情報 |
|---|---|
| 返信済みか | 最後に誰が、いつ、何を返信したか |
| 追加対応が必要か | 顧客からの未返信メール、期限、担当者 |
| 案件に関係するか | メール件名、本文、顧客、関連案件 |
| クレームか | キーワード、担当者メモ、対応ステータス |
| 引き継げるか | 過去の送受信、社内コメント、次回対応 |
| 配信後の反応か | 一斉送信後の返信、エラー、停止依頼 |
メール履歴を読めるだけでは、担当者依存が残ります。
kintone側に、対応ステータス、次回対応日、対応メモ、担当者、関連案件を持たせます。
メールワイズの履歴を見て判断し、その判断結果をkintoneに残す。
この往復が必要です。
たとえば、顧客から「前回の件で」と返信が来た場合、メールワイズのスレッドだけで対応するのではなく、kintoneの問い合わせレコードを更新します。
対応中、回答待ち、完了、再連絡予定などの状態に変えます。
次に誰が何をするかをkintoneに残します。
そうすれば、メールワイズを開かなくても、kintoneの一覧で未対応や期限超過を確認できます。
共有メール対応では、対応漏れと二重対応が起きます。
メールワイズ側には、処理状況、担当者、コメントでメール対応を管理する仕組みがあります。
一方で、kintone側には、顧客や案件単位のステータスがあります。
両方をどう対応させるかを決めます。
| 状況 | メールワイズ側 | kintone側 |
|---|---|---|
| 新規問い合わせ | 未処理、担当未設定 | 問い合わせレコード新規、未対応 |
| 担当者が決まった | 担当者設定 | 担当者、期限、対応中 |
| 顧客へ返信した | 返信済み、コメント | 最終返信日、回答済み |
| 顧客返信待ち | 処理状況を変更 | 顧客返信待ち、次回確認日 |
| 完了 | 完了扱い | 完了、完了日、完了理由 |
| 再対応 | 再オープン | 再対応、期限再設定 |
ここで注意すべきなのは、メールワイズの処理状況とkintoneのステータスは完全に同じではないことです。
メールワイズはメール単位の処理状況です。
kintoneは顧客、案件、問い合わせ単位の業務状態です。
ひとつの問い合わせに複数メールが関係する場合もあります。
ひとつの顧客に複数案件がある場合もあります。
そのため、メールワイズ側の状態をそのままkintoneへコピーするのではなく、業務単位に変換します。
メールワイズの処理状況はメール単位、kintoneのステータスは業務単位です。同じ言葉に見えても、更新する対象を分けます。
対応漏れを防ぐには、kintone側に未対応一覧を作ります。
メールワイズ側で処理した後、kintone側の一覧から消えることを確認します。
一覧に残るものは、対応が終わっていないものとして扱います。
一斉送信では、配信対象の抽出が重要です。
kintoneの一覧や絞り込み条件を使う場合、条件設計を担当者任せにしないほうがよいです。
| 条件 | 例 |
|---|---|
| 対象条件 | 顧客区分、契約中、地域、サービス利用中 |
| 除外条件 | 配信停止、連絡不可、退会、重複、クレーム対応中 |
| 確認条件 | メールアドレスあり、担当者あり、顧客名あり |
| 承認条件 | 配信前承認済み、テンプレート利用中 |
| 送信後条件 | 配信済み、エラー、停止依頼、返信あり |
kintone公式ヘルプでは、メールワイズ連携プラグインの利用条件として、kintoneとメールワイズの両方を利用できるユーザーであること、同じサブドメイン内のメールワイズを利用すること、ゲストユーザーは利用できないことなどが説明されています。
この条件は、権限設計にも関係します。
「kintoneの顧客一覧は見られるが、メールワイズでは送信できない」
「メールワイズでは送れるが、kintoneの対象条件を確認できない」
こうしたズレがあると、運用で止まります。
また、kintoneの権限で見えている顧客情報を、メールで外部へ送ってよいとは限りません。
顧客情報、契約情報、請求情報、社内メモは、メール本文に出す範囲を分けます。
一斉送信では、送信対象一覧を確認する人と、送信ボタンを押す人を分けてもよいです。
メールワイズとkintone連携では、次の失敗が起きやすいです。
メールアドレスだけの顧客管理では、配信可否や担当者、対応状態が分かりません。
メールを送るための台帳ではなく、顧客対応を判断するアプリとして作ります。
顧客詳細にメール履歴が表示されると便利です。
しかし、履歴を見て判断した結果がkintoneに戻らなければ、未対応一覧や次回対応には使えません。
対応ステータス、次回対応日、担当者を更新します。
担当者ごとに一覧条件を作ると、除外条件が漏れます。
配信停止、連絡不可、重複、顧客区分などは共通条件にします。
テンプレートは、文面だけではなく、利用条件、承認状態、更新日、管理者を持たせます。
古いテンプレートは停止し、使えるテンプレートだけを選ばせます。
メールワイズで担当者を変えても、kintoneの顧客担当や問い合わせ担当が変わらないと、引き継ぎに失敗します。
担当変更のルールを決めます。
kintoneには社内向けの重要メモが入ることがあります。
差し込み項目に使ってよい項目と、絶対に使わない項目を分けます。
顧客から停止依頼が来たのに、kintone側の配信可否が更新されないと、次回配信で事故になります。
停止依頼を受けたら、誰がどのアプリを更新するかを決めます。
メールワイズとkintone連携を始める前に、次の項目を確認します。
| 確認項目 | 判断すること |
|---|---|
| 顧客管理 | 顧客、担当者、メールアドレス、配信可否、重複を管理できるか |
| メールテンプレート | 件名、本文、差し込み、利用条件、承認状態を持てるか |
| 個別送信 | どのレコードから、どのテンプレートで送るか |
| 一斉送信 | 対象条件、除外条件、送信上限、分割送信をどう扱うか |
| メール履歴 | 顧客、案件、問い合わせのどこで履歴を見るか |
| 対応状態 | メールワイズの処理状況とkintoneステータスをどう対応させるか |
| 担当者 | メール担当、顧客担当、案件担当の違いをどう扱うか |
| 配信停止 | 停止依頼、連絡不可、退会をどこで管理するか |
| 権限 | kintoneとメールワイズの利用権限が合っているか |
| 監査 | 誰が、いつ、どの対象へ送ったか追えるか |
| 引き継ぎ | 担当変更時に履歴と次回対応を読めるか |
この表が埋まると、プラグイン設定の前に決めるべきことが見えます。
メールワイズ連携は、設定すれば便利になります。
ただし、顧客管理アプリ、テンプレートアプリ、配信対象条件、対応ステータスが曖昧なままでは、連携後に運用が散らかります。
Bitlightでは、メールワイズとkintone連携を、メール送信機能の導入ではなく、顧客対応履歴を業務DBに残す設計として整理します。
相談できる内容は次の通りです。
メールワイズとkintone連携は、メールを送れるようにするためだけのものではありません。
顧客対応を複数人で見えるようにし、送信後の判断をkintoneに戻すための仕組みです。
メールワイズとkintone連携は、メールの履歴を表示するだけでなく、顧客・案件・問い合わせの次の対応を決められる状態まで設計します。
メールワイズには、共有メール対応の実行を任せる。
kintoneには、顧客、案件、問い合わせ、対応状態、配信可否を残す。
この分担を先に決めれば、メール対応が増えても、担当者だけに履歴や判断が閉じにくくなります。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。