kintone×n8nのリマインド用ワークフローで、クレーム対応の抜け漏れを解消する方法を紹介！

プロセス管理と通知を入れれば、是正の抜け漏れは防げるはずだった

クレーム対応の是正フローをkintoneで回している現場では、受付から原因調査、是正、客先報告まで、対応の段階をプロセス管理のステータスで表し、次の担当へ引き継いでいるはずです。リマインダー通知も設定して、対応が遅れないように手を打った。これで止まった案件は拾えるはずでした。

ところが、実際には「調査中」のまま何週間も止まっている案件が、相変わらず出てきます。誰も気づかないうちに客先報告の期限が過ぎ、あとから対応に追われることになる。プロセス管理も通知も入れたのに、抜け漏れそのものは消えなかった、というわけです。

ここには、最初に抱きやすい思い込みがあります。「プロセス管理と通知さえ設定すれば、是正の抜け漏れは仕組みで防げる」という期待です。もちろん設定は間違っていません。ただ、その設定だけでは止まった案件を最後まで追いきれない部分が残ります。

本記事では、kintoneの標準機能でどこまでできて、どこからが足りないのかを切り分けましょう。そのうえで、足りない部分をkintone・n8n・生成AIでどう補うかを、自社の検証をもとに整理していきます。

足りなかったのは「止まった案件を段階的に追いきる役」で、それはn8nが担える

まず到達点をお見せします。期限を過ぎて止まった是正案件を、超過の度合いに応じて担当から上長へ段階的に催促し、客先報告書の下書きまで添えて手元に届ける。この状態を作れます。1日1回の照会で回せば、期限超過は遅くとも24時間以内に検知できます。

kintone標準のリマインダー通知でできる単純な催促と、n8nが補う3つの領域（滞留計測・段階的催促・報告書と集約）の役割分担図

担当者が一覧を見張って、止まった案件を記憶を頼りに拾う必要はありません。止まった案件のほうから、判断が必要な人に向かって上がってくるようになります。

大事なのは、kintoneの標準機能を否定しているわけではない、という点です。kintoneのリマインダー通知でも、単純な催促までは十分にできます。足りないのは、正確な滞留時間の計測・担当から上長への段階的な催促・客先報告書の下書きと外部への集約という一歩踏み込んだ部分です。

この足りない部分を埋める役として、n8nが向いています。n8nは、あるツールで起きた出来事をきっかけに別のツールを動かす連携を組めるワークフロー自動化ツールです。基礎から知りたい場合は、kintoneユーザーのための生成AI実践大全であわせて解説しています。

止まった案件を「追いきる」には、kintone標準の通知では届かない部分がある

なぜ、標準の通知だけでは止まった案件を追いきれないのでしょうか。理由は、通知の仕組みが「決めた条件で知らせる」ところまでは担うものの、「止まった案件を最後まで追いかけて片づける」ところまでは担わないからです。

具体的には、kintoneのリマインダー通知で「ステータスが調査中のレコードに、更新日時から数日後に知らせる」といった通知までは出せます。ここは標準機能でまかなえる範囲です。問題は、その通知を受け取ったあとに残る運用のほうにあり、何が足りないのかの中身は次の見出しで開示します。

これまで、止まった案件は担当者が拾うしかありませんでした。Excelの台帳を目視で見返したり、担当者の記憶と勘に頼って「あの案件、そういえば止まっていた」と思い出したりする。

件数が少ないうちは回りますが、クレーム対応が増えると、この目視と記憶が追いつかなくなります。止まった案件が一覧のなかに埋もれ、気づいたときには手遅れ、という状態です。

Excel任せの運用を仕組みへ移す発想は、kintoneを5年使い込んでいてもリスケ対応がExcel任せ？でも別のテーマとして扱っています。

見えにくくなるのは、現場の担当者だけではありません。本部や品質保証、DX推進の立場から見ても、全案件がいつからどのステータスで止まっているのかを一元的に把握できないのが実情です。現場がExcelと個人の記憶で回している限り、上の階層からは停滞の全体像が見えないままになります。

是正の抜け漏れを「担当者が覚えているかどうか」に委ねている状態から、「システムが停滞を検知して追いかける」状態へ移すことが、ここでの狙いです。

もう1点、誰がこれを組むのかにも触れておきましょう。kintoneのアプリ作成に加え、n8nで簡単な処理を組める品質管理や情報システムの担当者であれば、この連携は視野に入ります。SIerに大規模な開発を発注しなくても、社内の手が届く範囲にあるのです。

実際に社内の人がkintoneと外部システムをつないだ例は、販売管理システムとkintoneをn8nで連携してみた記事で紹介しています。ただし、社内で手を動かす時間を確保できるかどうかは、技術的に組めるかどうかとは別の問題です。この点は記事の最後であらためて触れます。

リマインダー通知を組んで初めて分かった、3つの「できないこと」

kintoneのリマインダー通知を実際に組んでみると、通知を出すだけでは片づかない場面に3か所で突き当たります。順番に並べているのは、これがそのまま作業の進む順序と重なるためです。kintone側の設定は、サイボウズのヘルプ（リマインダー通知）に沿って進められます。

kintoneのリマインダー通知で停滞を追いきれない3つの「できないこと」（滞留日数のリセット・段階的な通知先の切替不可・報告書と集約）を並べた図

基準日を「更新日時」にすると、別項目を触っただけで滞留日数がリセットされる

最初につまずくのは、滞留時間を正確に測れないことです。リマインダー通知は、基準日に「更新日時」を選び、そこから数日後に通知する設定ができます。一見、これで「調査中に入ってから何日たったか」を測れそうに見えます。

ところが、ここで選べる「更新日時」は、レコード全体の最終更新日時です。ステータスが「調査中」のままでも、担当者が関係のない項目を1つ直しただけで、更新日時が動いてしまいます。

その結果、実際には2週間止まっている案件でも、昨日どこかの項目を1つ更新していれば「昨日更新された案件」として扱われ、通知の基準がずれるのです。

しかも、基準日のプルダウンに並ぶのは「作成日時」や「更新日時」で、「ステータスが変わった日時」という選択肢そのものがありません。「調査中に入ってから、実際に何日放置されているか」を正しく測るには、ステータスが変わった日時を別に持っておく必要があります。

更新日時を基準にしている限り、この正確な滞留時間は取れません。

超過の度合いで、担当から上長へと通知先を切り替えられない

次につまずくのは、通知先の出し分けです。止まった案件をすべて同じ相手に、同じ内容で通知すると、本当に急ぐべき案件が日々の通知に埋もれます。理想は、超過が浅いうちは担当者へ軽く催促し、深くなったら上長へ引き上げる、という段階的な出し分けです。

しかし、リマインダー通知では宛先は指定できても、「超過が浅ければ担当、深ければ上長」という段階的な切り替えまでは組めません。結局、すべての通知が同じ相手に同じ重さで届き、重要な超過ほど埋もれるという、元の問題に逆戻りしてしまいます。

客先報告書の下書きや、Teamsへの集約までは手が回らない

3つ目は、通知を出した先の作業です。止まった案件に気づいても、そこから客先へ出す報告書を用意したり、判断が必要な案件だけを1か所にまとめて関係者へ知らせたりする作業は、通知機能の外にあります。

リマインダー通知は、あくまでkintoneのなかで「知らせる」ところまでを担う機能です。報告書の下書きを生成したり、Teamsのような普段見ている場所へ通知を集約したりする役目までは持っていません。ここを埋めないと、通知は来ても、そのあとの手作業は残ったままです。

なお、「通知が来ない」と感じる場合の多くは、この機能不足ではなく、条件や基準日の設定が想定と違っているケースだと補足しておきます。

ステータスの滞留を測り直し、n8nで段階的に追い、報告書まで用意する

3つの「できないこと」は、いずれも「どこに何をやらせるか」を整理すれば埋められます。ここからは、止まった案件を検知してから関係者へ届けるまでを、実行する順に組み立てましょう。設計の軸は一つで、止まった案件を人の記憶に頼らず、システムの側から追いかけることです。

ステータス変更日時の記録とn8nスケジュール実行による滞留計測、段階的な通知先切替、生成AIによる報告書下書きとTeams集約までの処理フロー図

ここからは、実際に組んだ画面を添えながら進めます。まず、検証で組み上げたワークフロー全体がこちらです。

ステータスが変わった日時を記録し、n8nのスケジュール実行で滞留時間を測る

1つ目の限界、滞留時間を正確に測れない問題には、基準そのものを持ち直すことで応えます。ステータスが切り替わったタイミングで、その日時を専用のフィールドへ記録しておくのがポイントです。こうすれば、あとから別の項目を触っても、この「ステータスが変わった日時」は動きません。

実際に用意したクレーム是正アプリがこちらです。滞留を測る「ステータス変更日時」を持たせ、書き戻し先の「滞留営業日」「エスカレ先」「報告書下書き」はこの時点では空にしてあります。

そのうえで、n8nを1日1回など定期的に動かし、記録した日時と現在時刻を比べて滞留時間を計算します。処理が動き出すきっかけを「レコードが変化したとき」ではなく「決まった時刻がきたとき」に置くのが勘所です。

止まって動かない、つまり何も変化していない案件こそ拾いたいので、変化を待つのではなく、時間のほうから全件を見に行く形にします。

この「ステータス変更日時」を基準に、n8nのスケジュール実行で滞留営業日を測ります。基準が更新日時ではないことが、下の計算ノードで確認できます。

滞留の段階に応じて、n8nで通知先を担当から上長へ切り替える

2つ目の限界、段階的な出し分けには、判定と分岐をn8n側に持たせて応えます。ステータスごとに許容できる日数をあらかじめ決めておきましょう。たとえば原因調査は5営業日、是正は10営業日、といった具合です。この基準はkintoneのマスタに持たせておけば、現場で見直せます。

しきい値は、ステータスごとにkintoneのマスタで持たせます。実際のマスタがこちらです。

計算した滞留時間がこの基準を超えたら担当者へ、さらに大きく超えたら上長へ、とn8nで通知先を切り替えます。

超過の深さに応じて届く相手が変わるので、急ぐべき案件が埋もれません。担当や承認者がkintoneを見に行かなくても、判断が必要な案件だけが向こうから届く形です。

同じ「調査中」でも、滞留の深さで担当・上長・未超過に振り分けられます。

報告書の下書きとTeamsへの集約をn8nに任せ、事実は生成AIに作らせない

報告書と集約という3つ目の限界には、n8nから生成AIとTeamsをつないで応えます。滞留を検知した案件について、客先報告書の下書きをその場で用意し、Teamsへ通知を集約する流れです。

ここで一つ、外せない注意点があります。下書きの文面づくりに生成AIを使う場合、金額や日付、案件番号といった事実まで生成AIに作らせてはいけません。生成AIは文章を書くのは得意でも、数字の扱いは苦手です。

もっともらしい文面のなかに、桁のずれた数値や実在しない案件番号をしれっと混ぜてくることがあり、しかも文面が自然なため、読んだだけでは気づきにくいのです。そのまま客先に出せば、事故のもとになりかねません。

避け方は単純です。案件番号や経過日数、原因といった確定した値はkintoneから取り出してそのまま渡し、生成AIには読みやすい文面への整形だけを任せます。事実はkintoneが持ち、文章の体裁だけを生成AIが担う、という切り分けです。

こうして用意した下書きを添え、超過の深さに応じて担当と上長へ届き分けます。

生成AIと業務データの組み合わせ方は、製造業の原価計算を自動化。kintone×freee連携で労務費の集計から振替伝票登録まで実行できるワークフローでも、近いテーマで具体化しています。

「状態」を持つだけの運用から、「停滞を段階的に追いかける」運用へ

これまでkintoneのプロセス管理は、いまどのステータスにあるかという「状態」は持っていました。リマインダー通知を足せば、単純な催促もできます。それでも、止まった案件を最後まで追いきる役だけは、標準機能のなかにありませんでした。

その空白を担当者の記憶とExcelの目視で埋めていたために、是正の抜け漏れは後を絶たなかったのです。

n8nがその空白を埋めると、止まった案件が、人の記憶ではなくシステムのほうから段階的に上がってくるようになります。

是正の抜け漏れは、「担当者が覚えているかどうか」から「システムが停滞を検知して追いかける」状態へと変わるのです。

現場の担当者だけでなく、本部やDX推進の立場からも、どの案件がいつから止まっているかが一元的に見えるようになるのも、この仕組みの効きどころです。

そして、できないと分かった場所ははっきりしています。ステータスの滞留を正確に測ること、超過の度合いで通知先を切り替えること、報告書と集約を用意すること。この3か所さえ先に押さえておけば、SIerに大規模な開発を発注しなくても、停滞の自動追跡までを自社の手で組める範囲に収まります。

ただし、技術的に組めることと、社内でそれを回し続けられることは分けて考える必要があります。仕組みを作る時間や、運用にのせる体制を社内で確保できるかどうかは、会社ごとに事情が違うためです。

まとめ

kintoneのプロセス管理と通知を入れても是正の抜け漏れが消えないのには、理由があります。

リマインダー通知は単純な催促まではできても、正確な滞留時間の計測・担当から上長への段階的な催促・報告書の下書きと外部への集約という3か所は、標準機能では届かないからです。

この3か所をn8nに担わせ、ステータスの滞留はステータス変更日時とスケジュール実行で測り、通知先はn8nで段階的に切り替え、報告書の文面は生成AIに整形だけ任せる。

役割をこう組み替えれば、是正の抜け漏れを「担当が覚えているか」から「システムが段階的に追いかける」状態へ近づけられます。

最後に

クレーム是正の停滞をどこで検知し、どの段階で誰に催促するかは、ステータスの構成や運用の実情によって変わります。

どのフィールドに何を持たせ、どこからをn8nに任せるのが自社に合うか、費用や導入にかかる期間はどれくらいか。こうした点は、実際の環境を見てみないと判断がつきません。

自社の是正フローにこの仕組みを当てはめたい、あるいは社内で回せる体制も含めて相談したい、という場合は、ものづくりAI自動化ファクトリーの無料相談をご利用ください。現状の運用をうかがいながら、どこから自動化できそうか、どれくらいの規模になりそうかを一緒に整理します。

関連記事