kintone業務設計研究所 > メールワイズとkintone連携の設計方法|顧客対応履歴を業務DBに残す

メールワイズとkintone連携の設計方法|顧客対応履歴を業務DBに残す

2026年6月12日

17分で読めます

メールワイズとkintoneを連携するときに、顧客管理アプリ、メールテンプレート、個別送信、一斉送信、メール履歴、担当者、対応ステータス、配信対象抽出、対応漏れ防止をどう設計するか整理します。

kintone
メールワイズ
メール対応
顧客管理
問い合わせ管理
業務設計
助手
助手

メールワイズとkintoneを連携すれば、顧客管理とメール対応はかなり楽になりますか。

博士
博士

連携は有効ですが、メールワイズを「メール対応の実行場所」、kintoneを「顧客・案件・対応履歴の業務DB」として分けないと、送信履歴は見えても業務判断に使えない状態になります。

メールワイズとkintoneを連携したい会社では、すでにメール対応に課題があることが多いです。

代表アドレスに問い合わせが届く。

複数人で返信する。

過去のやり取りを見ながら対応したい。

kintoneの顧客情報からメールを送りたい。

キャンペーンや更新案内を対象者にまとめて送りたい。

顧客詳細画面で、メールワイズの送受信履歴を見たい。

こうした要望は自然です。

ただし、連携プラグインを入れるだけでは、顧客対応の運用は整いません。

  • 顧客マスタのメールアドレスが古い
  • 同じ顧客が複数レコードに分かれている
  • 一斉配信の対象条件が担当者ごとに違う
  • メールテンプレートの版が管理されていない
  • 送信後にkintoneの問い合わせステータスが変わらない
  • メールワイズ側では対応済みだが、kintone側では未対応のまま残る
  • 担当者が変わっても、引き継ぎに必要な対応履歴が読めない
  • メール履歴は表示されるが、案件や問い合わせと結びついていない
  • 送ってはいけない顧客を配信対象に含めてしまう

メールワイズは、複数人でメールを処理する場所です。

kintoneは、顧客、案件、問い合わせ、契約、対応状態を管理する場所です。

連携で大事なのは、両方を混ぜることではありません。

メールワイズで行った送受信を、kintoneの顧客・案件・問い合わせの文脈で使えるようにすることです。

メールワイズとkintone連携で最初に決めるべきなのは、メールを送れるかではなく、メール対応の結果をどの顧客・案件・問い合わせに戻すかです。

この記事では、メールワイズとkintone連携を、設定手順ではなく、顧客対応を業務DBに残す設計として整理します。

kintone顧客管理の設計方法はこちら
kintone問い合わせ管理の設計方法はこちら
kintoneメール送信の設計方法はこちら
kintoneメール配信の設計方法はこちら

kintone顧客管理、メールテンプレート、メールワイズ、個別送信、一斉送信、メール履歴、担当者、対応ステータスの関係を示すメールワイズ kintone連携設計図

メール対応と顧客管理の役割を分ける

メールワイズとkintone連携では、まず役割を分けます。

領域 メールワイズの役割 kintoneの役割
受信メール 代表アドレスの受信、担当者、処理状況の管理 顧客、問い合わせ、案件との紐づけ
返信・個別送信 実際のメール作成、返信、送信 宛先、顧客属性、案件状態、送信根拠の管理
一斉配信 メール本文の作成、送信処理 対象者抽出、配信可否、配信後の状態管理
メール履歴 送受信したメールの蓄積 顧客詳細、案件詳細、問い合わせ判断への表示
テンプレート メール文面として利用 テンプレート種別、利用条件、承認状態の管理
対応管理 処理状況、担当者、コメント 顧客対応ステータス、次回対応、未対応一覧

メールワイズ公式サイトでは、複数人で共有メールを扱い、処理状況や担当者、コメントを使ってメール対応を管理できる機能が紹介されています。

メールワイズ:処理状況・担当者・コメント

サイボウズのkintone連携ページでは、kintoneの顧客情報から個別送信、一斉送信、メール履歴表示、メールテンプレート管理ができることが整理されています。

サイボウズ:メールワイズ連携

この2つを合わせると、メールワイズは「メール対応の実行場所」として強く、kintoneは「顧客と業務状態の正本」として強いことが分かります。

たとえば、顧客からの問い合わせに返信する場合、メール本文を書くのはメールワイズでよいです。

しかし、その問い合わせがどの顧客の、どの契約の、どの案件に関するものかは、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側の配信可否が更新されないと、次回配信で事故になります。

停止依頼を受けたら、誰がどのアプリを更新するかを決めます。

実装前チェックリスト

メールワイズとkintone連携を始める前に、次の項目を確認します。

確認項目 判断すること
顧客管理 顧客、担当者、メールアドレス、配信可否、重複を管理できるか
メールテンプレート 件名、本文、差し込み、利用条件、承認状態を持てるか
個別送信 どのレコードから、どのテンプレートで送るか
一斉送信 対象条件、除外条件、送信上限、分割送信をどう扱うか
メール履歴 顧客、案件、問い合わせのどこで履歴を見るか
対応状態 メールワイズの処理状況とkintoneステータスをどう対応させるか
担当者 メール担当、顧客担当、案件担当の違いをどう扱うか
配信停止 停止依頼、連絡不可、退会をどこで管理するか
権限 kintoneとメールワイズの利用権限が合っているか
監査 誰が、いつ、どの対象へ送ったか追えるか
引き継ぎ 担当変更時に履歴と次回対応を読めるか

この表が埋まると、プラグイン設定の前に決めるべきことが見えます。

メールワイズ連携は、設定すれば便利になります。

ただし、顧客管理アプリ、テンプレートアプリ、配信対象条件、対応ステータスが曖昧なままでは、連携後に運用が散らかります。

Bitlightに相談できること

Bitlightでは、メールワイズとkintone連携を、メール送信機能の導入ではなく、顧客対応履歴を業務DBに残す設計として整理します。

相談できる内容は次の通りです。

  • 顧客管理アプリの項目設計
  • メールテンプレートアプリの設計
  • 個別送信、一斉送信、配信停止の使い分け
  • メールワイズの処理状況とkintoneステータスの対応づけ
  • 顧客詳細画面でのメール履歴確認設計
  • 配信対象一覧、除外条件、承認フローの設計
  • 担当者変更、引き継ぎ、次回対応の運用設計
  • 権限、社内メモ、差し込み項目の事故防止

メールワイズとkintone連携は、メールを送れるようにするためだけのものではありません。

顧客対応を複数人で見えるようにし、送信後の判断をkintoneに戻すための仕組みです。

メールワイズとkintone連携は、メールの履歴を表示するだけでなく、顧客・案件・問い合わせの次の対応を決められる状態まで設計します。

メールワイズには、共有メール対応の実行を任せる。

kintoneには、顧客、案件、問い合わせ、対応状態、配信可否を残す。

この分担を先に決めれば、メール対応が増えても、担当者だけに履歴や判断が閉じにくくなります。

kintone業務アプリ設計支援

メールワイズとkintone連携を、顧客対応の業務DBとして設計します

メールの送受信だけで終わらせず、顧客・案件・問い合わせ・テンプレート・送信履歴・担当引き継ぎまで実務に合わせて設計します。

著者
守高 成悟
守高 成悟

代表取締役 CEO

千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。

運営会社
株式会社ビットライト
株式会社ビットライト

顧客が本当に必要だった価値を、実装する。

現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援しています。

コーポレートサイトを見る
kintone設計相談

アプリ構成・権限・連携範囲を相談できます

Excelからの移行、既存kintoneの見直し、外部サービス連携まで、業務に合わせた設計範囲を整理します。