Notionで承認・レビュー待ちを自動リマインドする方法
要点（TL;DR）
- 承認・レビューが止まる主因は「承認者がNotionを開かない／アカウントを持たない」「ステータスが変わっても誰にも通知が飛ばない」「承認が後回しにされ、催促のきっかけがない」の3つです。
- 最初にすべきは、「承認待ち」を独立したステータスとして定義し、滞留日数が見えるビュー／フィルタを作ることです。土台がなければどの通知手段も安定しません。
- 社内の承認者にはNotion標準通知・Slack連携・Zapier/Make/GASなど、社外の承認者（クライアント）にはメールと、相手に応じて手段を使い分けるのが実務的です。
- 事故防止の観点では「承認済み・完了には催促を送らない」条件をステータスで担保できるかが要になります。
Notionで案件を管理していると、作業そのものより「承認待ち」「レビュー待ち」で止まっている時間のほうが長い、という状況は珍しくありません。この記事は、承認・レビューで止まった案件を、承認者（社内の上長・社外のクライアント）へ期日リマインドして動かすための手順を、第三者視点で整理したものです。まず原因を切り分け、次にステータス設計から通知の自動化、催促文面の作り方までを、Notion標準機能・チャット連携・DIY自動化・専用ツールを横並びで扱いながら解説します。
なお、担当者への一般的なリマインドの作り方はNotionで担当者にタスクを自動リマインドする方法、Notionを使わない社外の承認者への具体的な送り方はNotionを使わない取引先・クライアントにリマインドを送る方法で扱っています。本記事は「承認・レビューで止まる案件を動かす」ことに焦点を絞ります。
Notionで「承認待ち」が止まる本当の理由
承認・レビュー待ちが滞留するのは、担当者の怠慢ではなく、通知の構造とワークフローの設計に原因があることがほとんどです。原因を3つに切り分けると、どの対策から着手すべきかが見えてきます。
| 滞留の原因 | 何が起きているか | 対策の方向 |
|---|---|---|
| 承認者がNotionを開かない／持たない | 通知の宛先になれない | 社外はメール等Notionの外へ届ける |
| ステータス変更で通知が飛ばない | 依頼したこと自体が伝わらない | 更新をトリガーに自動通知する |
| 承認が後回しにされる | 期日と督促のきっかけがない | 期日設計＋自動リマインド |
承認者・クライアントがNotionを開かない／アカウントを持たない
承認を止める最大の要因は、承認者が普段Notionを開かない、あるいはそもそもアカウントを持っていないことです。社外のクライアントや取引先の承認者は、多くの場合Notionを日常的に使っていません。Notionの通知はアカウント保持者向けの仕組みのため、Notion圏の外にいる承認者は通知の宛先になれず、依頼が届いていることに気づけません。
ステータスが変わっても誰にも通知が飛ばない
Notionでステータスを「承認待ち」に変更しても、その変更自体は自動では誰にも通知されません。依頼した側は「ステータスを変えた＝相手に伝わった」と考えがちですが、承認者側から見ると、能動的にページを見に行かない限り依頼が発生したことすら分かりません。この認識のずれが、両者の「待ち」を生みます。
承認が後回しにされ、催促のきっかけがない
承認は、承認者本人の主業務ではない「割り込みタスク」であることが多く、優先度が下がって後回しにされやすい性質があります。加えて、依頼側にとって催促は心理的なハードルが高く、期日の再提示や督促のきっかけが仕組み化されていないと、どちらも動かないまま時間だけが過ぎます。属人的な「気づいたら催促する」運用では、案件数が増えるほど抜け漏れが発生します。
💡 ポイント：滞留は「相手に届いていない」「気づかせる仕組みがない」という構造の問題です。文面を丁寧にする前に、まず届く経路と自動で気づかせる仕組みを整えるのが順序です。
準備 — 「承認待ち」を独立したステータスとして設計する
自動リマインドを組む前に、どのタスクが承認で止まっているのかをNotion上で機械的に判別できる状態を作ります。これがすべての通知手段の土台になります。
ステップ1：ステータスに「承認待ち」を独立して定義する
「進行中」や「レビュー中」にまとめず、「承認待ち（確認待ち）」を独立したステータス値として定義します。承認の局面を独立させることで、「誰の承認で止まっているか」を後から条件抽出できるようになります。
- 対象データベースのステータス（またはセレクト）プロパティを開く。
- 「承認待ち」「差し戻し」「承認済み」など、承認フローの状態を独立した値として追加する。
- 「承認待ちになった日付」を記録する日付プロパティ（例：
承認依頼日）を用意する。滞留日数の計算に使う。 - 承認者を指定する担当者（Person）プロパティ、または社外向けにメールアドレスを入れるテキスト／メールプロパティを用意する。
💡 ポイント：
承認依頼日を手動またはオートメーションで自動入力しておくと、後述の「滞留日数に応じたエスカレーション」でdateBetweenなどの計算がそのまま使えます。ステータス変更時に日付を自動セットするNotionのデータベースオートメーションを併用すると、入力漏れを防げます。
ステップ2：滞留を可視化するビュー／フィルタを作る
承認待ちだけを抜き出したビューを作り、滞留がひと目で分かる状態にします。関係者はこのビューを見るだけで、止まっている案件を把握できます。
- データベースに新しいビュー（テーブルまたはボード）を追加する。
- フィルタで「ステータス＝承認待ち」を指定する。
承認依頼日の昇順でソートし、古い（＝長く止まっている）ものが上に来るようにする。- 承認者ごとに把握したい場合は、担当者プロパティでサブグループ化（またはボードのグループ）する。
このビューは、後述の定期便や送信対象の絞り込みの「元データ」としても機能します。承認で止まっている案件が構造化されていれば、どの通知手段を選んでも運用が安定します。
ステップ3：レビュー依頼を標準化する（依頼フォームで抜け漏れを防ぐ）
承認・レビューが往復する一因は、依頼の時点で必要な情報が揃っていないことです。「何を・いつまでに・どの観点で見てほしいのか」が曖昧だと、承認者は判断できず、確認の往復が増えます。依頼をフォーム化・テンプレ化して標準化すると、この曖昧さを抑えられます。
- 依頼テンプレートを用意する：データベースのテンプレート機能で「レビュー依頼」用のページテンプレートを作り、
確認してほしい点期日承認者参照リンクなどの項目をあらかじめ配置する。 - フォームで受け付ける：Notionのフォーム（フォームビュー）を使うと、依頼者が必須項目を埋めた状態でしかレコードを作れないため、情報の抜け漏れが構造的に防げる。
- 判断基準を明記する：「OK／要修正のどちらか」「◯日までに」など、承認者が即断できる形に整える。
⚠️ 注意：依頼の標準化は自動リマインドの「前提」です。文面を自動で送っても、依頼内容が曖昧なままでは「何を承認すればいいか分からない」という別の停滞を招きます。
社内の承認者に自動でリマインドを届ける方法
まずはNotion内で完結する社内向けの手段です。承認者が同じワークスペースのメンバーであれば、標準機能とその周辺で一定の自動化ができます。
Notion標準の@リマインド／通知の限界
Notionには @remind や日付プロパティのリマインダー、@メンション があり、承認者へ通知を送れます。承認待ちページのコメントで「@承認者名 ご確認をお願いします」とメンションすれば、その相手のNotion受信トレイに通知が届きます。
ただし、この通知が実際に見られるかは相手がNotionを開いているか、メール通知をONにしているかに依存します。承認者が普段Notionを開かず、メール通知も設定していない場合、通知は届いていても埋もれがちです。管理者側から相手の通知設定を強制することはできないため、「送ったつもりが見られていない」が起こり得ます。標準通知が届かない原因の切り分けはNotionの通知が届かないときの原因と対処で詳しく整理しています。
⚠️ 注意：Notionのメール通知は「しばらくNotionを開いていないときにまとめて届く」挙動になりがちで、期日に合わせた確実な督促を前提にした仕組みではありません。承認のように「期日までに必ず動いてほしい」用途では、到達の確実性を別途担保する必要があります。
担当者・ステータス条件を絞って自動で送る
「承認待ちかつ期日が近い（または過ぎた）案件の承認者にだけ送る」といった条件による絞り込み送信は、標準のリマインダー（日付ごとに一件ずつ手動設定）では設計上難しい部分です。ここを自動化するには、次のいずれかの方法があります。
| 手段 | 向いている相手 | 必要スキル | 双方向（書き戻し） |
|---|---|---|---|
| Notionオートメーション＋Slack | 社内メンバー | 低〜中 | ない（Notion手動更新） |
| Zapier / Make / n8n | 社内・社外メール | 中 | 自作が必要 |
| GAS＋Notion API | 社内・社外メール | 高 | 自作が必要 |
| 通知専用ツール | 社内・社外メール | 低 | 対応するものがある |
どの手段でも共通して必要なのは、「承認待ち」ステータスと期日を条件に、承認者を宛先として自動抽出するという考え方です。期日を条件にした通知の基礎ロジックはNotionの期日を自動でメール通知する方法でも扱っています。
チャット連携・DIY自動化で承認フローを組む（Slack／GAS）
承認者が社内にいてSlackなどを日常的に使う場合、チャットツールへの通知や、Notion APIを使った自作フローが選択肢になります。ここでは代表的な2つを公平に整理します。
SlackにNotionのレビュー依頼・更新を通知する
チームがSlackで動いているなら、Notionの更新やレビュー依頼をSlackに流すと、承認者が普段見ている場所に依頼が届きます。実現方法は主に次の3通りです。
- Notionのデータベースオートメーション：ステータスが「承認待ち」に変わったことをトリガーに、指定のSlackチャンネルへ通知を送る（Notion側でSlack連携を設定）。
- Zapier / Make / n8n：Notionのページ更新をトリガーに、条件で絞り込み、Slackへメッセージを投稿する。文面や宛先チャンネルを柔軟に分岐できる。
- Slackのワークフローとの組み合わせで、承認依頼を定型メッセージ化する。
Slack通知は「社内の承認者に、依頼が発生したことを能動的に気づかせる」用途に有効です。一方で、Slack側で承認しても、その結果は自動ではNotionに戻りません。承認者がSlackで「OK」と返しても、Notionのステータスは誰かが手動で更新する必要があります。また、Slackを使わない社外の承認者には届きません。
GAS・Notion APIで承認フローを自作する（申請登録→通知の一方向フロー）
コードを書ける場合、Google Apps Script（GAS）でNotion APIを叩き、承認フローを自作できます。よくある構成は、Slackなどからの申請をNotionに登録し、関係者へ通知する一方向フローです。
- 申請の受付：Slackのフォームやスプレッドシートで申請を受け、GASでNotion APIを呼び、承認待ちレコードを作成する。
- 定時トリガー：GASのトリガーで毎日決まった時刻に実行し、「承認待ち」かつ期日が近い（過ぎた）レコードを抽出する。
- 通知送信：
GmailApp.sendEmail()などで承認者へメールを送る、またはSlackへ投稿する。 - フラグ書き込み：送信後にNotion側へ「通知済み」フラグを書き込み、重複送信を防ぐ。
| 観点 | GAS＋Notion API 自作 |
|---|---|
| コスト | Google／Notionの無料枠で運用しやすい |
| 自由度 | 条件・文面・宛先を自由に設計できる |
| 必要スキル | JavaScript・Notion APIの知識が必要 |
| 保守 | API仕様変更・エラー・送信上限への対応は自己責任 |
| 双方向 | 承認結果をNotionに戻す仕組みは別途自作が必要 |
GASは無料で柔軟ですが、「申請登録→通知」の一方向で完結しがちで、承認者の判断をワンクリックでNotionに書き戻す双方向の仕組みまで作り込むには相応の工数がかかります。エラー時に誰にも気づかれない、Gmailの送信上限に当たる、といった運用リスクも自分で管理する前提です。
💡 ポイント：Slack連携もGAS自作も「気づかせる（通知する）」には有効です。ただし多くの構成は通知したら終わりの一方向で、承認結果のNotionへの反映は手動になりがちです。この点が、後述の双方向対応との分かれ目になります。
Notionを持たない社外のクライアント・取引先に承認を催促する方法
承認・レビューの相手が社外のクライアントや取引先の場合、ここまでの社内向け手段（Notion標準通知・Slack）はそのままでは使えません。相手はNotionアカウントもSlackも持たないことが多く、通知の宛先になれないためです。社外の承認者に届ける現実的な経路は、多くの人が日常的に見るメールです。
相手はログイン不要でメールから直接内容を確認できる
社外の承認者に届けるうえで重要なのは、相手に新しいツールの登録やログインを求めないことです。メールで承認依頼と確認リンクを送れば、承認者はNotionアカウントなしで、普段のメールから内容を確認できます。相手側のハードルが下がるほど、承認は早く返ってきます。社外の承認者への送り方の詳細はNotionを使わない取引先・クライアントにリマインドを送る方法にまとめています。
受信者のワンクリックでNotionのステータスに書き戻る（双方向）
社外への承認催促でとくに手間になるのが、相手の返信を見て、Notionのステータスを手動で更新する作業です。「承認します」というメールが来ても、Notion側の台帳を最新にするのはこちら側の手作業になります。
この往復を減らす考え方が、受信者のワンクリックでNotion側のステータスに書き戻る双方向の仕組みです。承認依頼メールに確認用のボタンを置き、承認者がクリックした結果がそのままNotionのステータスに反映されれば、依頼側はNotionを見るだけで最新状態を把握できます。DIY自動化や一般的な通知手段は「メールが届いたら終わり」の一方向が多く、この双方向更新の有無が運用負荷を大きく左右します。
Kapselとは、Notionの期日・担当・ステータスを監視し、承認者やクライアントにメールで自動リマインドを送り、受信者のワンクリックでNotionのステータスに書き戻すツールです。社外のNotionを使わない相手にも届き、承認済み・完了には送りません。
社外の承認者への双方向リマインドは、こうした専用ツールを使うか、前述のZapier/Make/GASで書き戻し部分まで自作するかの選択になります。
「承認待ちのまま放置」を防ぐ期限超過の自動督促とエスカレーション
一度の依頼で承認が返るとは限りません。放置されたときに段階的に督促を強める（エスカレーションする）仕組みがあると、案件が止まり続けるのを防げます。
滞留日数に応じてエスカレーションする
エスカレーションは、承認依頼日 からの経過日数（滞留日数）を基準に段階を設計します。ノーコードでも、条件（フィルタ）と自動送信を組み合わせれば実現できます。
| 段階 | タイミング（目安） | アクション |
|---|---|---|
| 一次リマインド | 期日の2〜3営業日前 | 期日を添えて確認を依頼 |
| 二次リマインド | 期日前日／当日 | 期日の再提示 |
| 督促 | 承認待ちが2営業日続いたら | 再度の依頼＋別チャネル併用 |
| アラート | 放置期間を過ぎたら | 依頼側の管理者へアラートメールを送る |
実装のポイントは、滞留日数を条件にビューやフィルタで対象を切り出し、その対象にだけ自動送信することです。GASなら承認依頼日からの経過日数を計算するコードで段階を分岐でき、通知専用ツールなら「期日超過」「◯日以上滞留」といった条件で対象を絞れます。非エンジニアがノーコードで始める場合は、まず「承認待ちビュー」を条件で複数用意し、それぞれに定期送信を割り当てる形が現実的です。
承認済み・完了には送らない（事故防止）
エスカレーションを自動化するとき、最も避けたいのは「すでに承認・完了した案件に催促が飛ぶ」事故です。承認済みの相手に督促メールが届くと、信頼を損ないます。日付だけを条件にした自動化はこの事故を起こしやすいため、ステータスを必ず条件に含めることが不可欠です。
- フィルタや条件に「ステータス＝承認待ち」を必ず入れ、「承認済み」「完了」を除外する。
- ステータスの変化を監視し、承認者が承認に更新した時点で以降の送信を止める。
- 送信前に「本当に未承認か」をステータスで再確認する設計にする。
この「片付いたものには送らない」という事故防止は、入金済みには督促を送らない実装と考え方が共通しています。同種の設計例はフリーランスの入金管理・報酬未払い対策でも扱っています。
⚠️ 注意：完了・承認済みへの誤送信は、社外の承認者相手ではとくに致命的です。「送らない」条件をステータスで担保できるかどうかが、自動督促を安心して運用できるかの分岐点になります。
催促メールの言葉遣いとタイミング（文例つき）
自動化しても、文面が事務的すぎたり急かしすぎたりすると逆効果です。承認催促では、期限の再提示・丁寧な表現・行き違いへの配慮の3点を押さえます。
- 期限を明確に再提示する：「◯月◯日（◯）までに」と具体的な日付で示す。
- 相手が即断できる形にする：「承認／差し戻しのどちらか」を一言で返せるようにする。
- 行き違いに配慮する：すでに対応済みの可能性に触れ、「対応済みでしたらご容赦ください」を添える。
- タイミングを分ける：期日前は「お願い」のトーン、超過後は「再度のご連絡」と段階を変える。
社外のクライアント向けの承認催促の文例です。
件名：【ご確認のお願い】〇〇の承認について（〇月〇日まで）
〇〇株式会社
〇〇 様
お世話になっております。〇〇です。
先日お送りした「〇〇」につきまして、〇月〇日（〇）までに
ご確認・ご承認をいただけますと幸いです。
▼ご確認・ご承認はこちら
（リンク）
すでにご対応済みの場合は、行き違いのご連絡となりますことをお詫び申し上げます。
ご不明な点やご懸念があれば、お気軽にお知らせください。
社内の承認者（上長）向けの、より簡潔な文例です。
件名：【承認依頼】〇〇のご確認をお願いします（期日：〇月〇日）
〇〇さん
お疲れさまです。
「〇〇」の承認をお願いできますでしょうか。期日は〇月〇日です。
▼対象
（リンク）
対応いただけそうな時期の目安だけでも教えていただけると助かります。
（すでにご確認済みでしたら本メールはご放念ください）
💡 ポイント：文例は「一件ずつ手で書く」前提だと運用が続きません。次に触れる差し込み変数で、宛名・案件名・期日を自動で差し替える形にすると、丁寧さを保ったまま数をさばけます。
差し込み変数で催促メールを一件ずつ手打ちしない
承認待ちが増えると、案件ごとに文面を手打ちするのは現実的ではありません。**差し込み変数（マージタグ）**を使えば、Notionのプロパティ値をメール本文に自動で挿入でき、一件ずつのパーソナライズを自動化できます。
- 宛名：承認者名・会社名を各レコードから差し込む。
- 案件名・対象：ページタイトルや対象プロパティを差し込む。
- 期日：期日プロパティを差し込み、「◯月◯日まで」を自動生成する。
- 確認リンク：該当ページや確認用リンクを差し込む。
差し込み変数を使うと、上記の文例の 〇〇 の部分がレコードごとに自動で埋まり、全員に同じ文面を一斉送信するのではなく、承認者ごとに宛名・案件・期日が異なる文面を送れます。Zapier/Make/GASでも各プロパティを本文にマッピングすれば同様のことができますが、マッピングの手作業と保守が発生します。通知専用ツールは、この差し込みをUIで設定できるものがあります。
定期便で「今、承認待ちの一覧」を関係者に配信する
個別の督促とは別に、**「現在承認待ちの案件一覧」を定期的にまとめて配信する（定期便）**運用を組むと、承認の滞留を定例で棚卸しできます。週次会議での目視確認に頼ると、会議のない期間は滞留が見えなくなりますが、定期配信なら関係者が常に最新の停滞状況を把握できます。
- 配信対象：ステータス＝承認待ちのレコード一覧（滞留日数つき）。
- 配信先：依頼側の管理者・プロジェクト責任者、または承認者本人。
- 頻度：週初など、決めたタイミングで自動送信。
定期便は「誰が何日止めているか」を関係者に共有する効果があり、個別の催促を出しにくい相手にも、一覧という形で自然に気づかせられます。
送信記録で「送った／送っていない」を可視化する
継続運用でつまずきやすいのが、「この承認者に催促を送ったか、まだか」が分からなくなることです。誰にいつ何回催促したかの記録がないと、二重送信や送り忘れが起きます。
- 送信履歴を残す：どの案件の承認者に、いつ、どの内容を送ったかを記録する。
- 回数を把握する：同じ相手への督促回数を可視化し、エスカレーションの段階判断に使う。
- 抜け漏れを防ぐ：「送ったつもり」を排し、未送信の案件を客観的に洗い出す。
DIY自動化（Zapier/Make/GAS）では、送信ログを自分でスプレッドシートやNotionプロパティに書き出して管理する設計が必要です。通知専用ツールには、送信記録を一覧で確認できるものがあり、運用の属人化を避けやすくなります。
NotionとKapselで承認リマインドを設定する流れ
社外の承認者への双方向リマインドや、完了・承認済みの除外、送信記録までを自作せずに使いたい場合の一例として、専用ツールを接続する流れを示します。ここではKapselを例にしますが、考え方は他の手段でも共通です。
- 無料登録する：getkapsel.com からFreeプラン（¥0）で登録する。
- Notionを接続する：承認待ちを管理しているデータベースを接続する。
- 監視条件を決める：「ステータス＝承認待ち」かつ「期日が近い／過ぎた」を送信条件にし、承認済み・完了を除外する。
- 宛先と文面を設定する：承認者（社内メンバー、または社外のメールアドレス）を宛先にし、差し込み変数で宛名・案件名・期日を組み込む。
- エスカレーションと定期便を設定する：期限超過の督促や、承認待ち一覧の定期配信を有効化する。
- 配信を有効化する：条件に合った承認者へ自動でリマインドが送られ、送信記録で到達を確認できる。社外の承認者はメール上のワンクリックでNotionのステータスに書き戻せる。
参考として、Kapselの料金は次のとおりです（税込・執筆時点）。
| プラン | 月額（税込） | 主な内容 |
|---|---|---|
| Free | ¥0 | 0円のまま使い続けられる無料プラン |
| Standard | ¥1,980 | 自動リマインド・絞り込み・定期便・送信記録・差し込み変数など |
| Pro | ¥4,980 | Standardに加え、複数のNotionワークスペース／差出人ブランディング（会社名・署名・ロゴ） |
💡 ポイント：まずFreeで1つのデータベースを接続し、少数の承認待ち案件で「誰に・いつ・何が届くか」を確認してから対象を広げると、安全に立ち上げられます。専用ツールが唯一の正解ではなく、社内完結ならNotion標準＋Slack、柔軟な分岐が要るならZapier/Make/GAS、と用途で選ぶのが実務的です。
よくある質問（FAQ）
Notionで承認フローを自動化するにはどうすればいいですか？
まず「承認待ち」を独立したステータスとして定義し、承認依頼日と承認者を記録する土台を作ります。そのうえで、社内ならNotionオートメーションやSlack連携、社外を含むならZapier/Make/GAS、または通知専用ツールで「承認待ちの承認者へ自動通知」を組みます。承認済み・完了を条件から除外することが、事故を防ぐ前提になります。
承認待ちのタスクを自動でリマインドする方法は？
「ステータス＝承認待ち」かつ「期日が近い／過ぎた」レコードを条件で抽出し、その承認者へ自動でメールやチャット通知を送る仕組みを作ります。Notion標準の日付リマインダーは一件ずつの手動設定になるため、条件で絞った自動配信にはオートメーションや外部ツールを組み合わせます。担当者への一般的なリマインドの作り方はNotionで担当者にタスクを自動リマインドする方法を参照してください。
Notionのステータスが変わったら自動でメール通知できますか？
はい、可能です。Notionのデータベースオートメーション、Zapier/Make/n8n、GAS＋Notion API、または通知専用ツールを使うと、ステータスが「承認待ち」に変わったことをトリガーにメールを送れます。ただし標準機能のメール通知は宛先がNotionアカウント保持者に限られるため、社外へ確実に届けたい場合はメール送信を担う外部の仕組みが必要です。
承認者やレビュアーがNotionを使っていない場合はどう通知すればいい？
Notionを使わない承認者には、メールで届けるのが現実的です。相手にログインや登録を求めず、確認リンク付きのメールを送れば、Notionアカウントなしで内容を確認できます。さらに、受信者のワンクリックでNotionのステータスに書き戻る仕組みを使えば、承認結果を手動で転記する手間も省けます。詳しくはNotionを使わない取引先・クライアントにリマインドを送る方法をご覧ください。
承認依頼が放置されているときのエスカレーション方法は？
承認依頼日からの滞留日数を基準に、段階を設計します。たとえば「期日前に一次リマインド→承認待ちが2営業日続いたら再依頼→放置期間を過ぎたら依頼側の管理者へアラートメールを送る」という形です。滞留日数を条件にビューやフィルタで対象を切り出し、それぞれに自動送信を割り当てれば、ノーコードでも段階的な督促を組めます。
クライアントへの確認・承認の催促メールはどう書けばいい？（文例・タイミング）
期限の再提示・丁寧な表現・行き違いへの配慮の3点を押さえます。「◯月◯日までにご確認・ご承認をお願いします」と期日を明記し、「すでにご対応済みでしたらご容赦ください」と添えるのが基本です。タイミングは期日前は「お願い」、超過後は「再度のご連絡」とトーンを分けます。本文の文例セクションにコピペ用の例を掲載しています。
承認済み・完了した案件に誤って催促が届かないようにするには？
日付だけでなく、必ずステータスを条件に含めることです。「承認待ち」だけを対象にし、「承認済み」「完了」を除外すれば、片付いた案件への誤送信を防げます。ステータスの変化を監視して、承認された時点で以降の送信を止める設計にすると、より確実です。Kapselは承認済み・完了には送らない設計になっています。
補足・注記
- 公開日：2026-08-05。本記事の内容は公開時点の情報にもとづきます。
- Notionの機能について：ステータス／セレクトプロパティ、日付プロパティのリマインダー、
@remind・@メンション、データベースオートメーション、フォーム、テンプレートなどの記述は、Notion公式ヘルプセンターの記載および執筆時点の挙動を参照しています。Notionの仕様・UIは更新されることがあるため、最新の手順は公式ヘルプで確認してください。 - 外部ツールについて：Slack、Zapier／Make／n8n、Google Apps Script（GAS）およびNotion APIの機能・料金・対応範囲は各サービスの提供状況により変わります。導入前に各公式情報をご確認ください。
- Kapselの機能・料金について：本文中のKapselの機能・料金（Free ¥0／Standard ¥1,980／Pro ¥4,980、いずれも税込）は執筆時点のものです。最新の情報は getkapsel.com をご確認ください。
- 本記事は、承認・レビュー待ちの停滞を解消する手段を客観的に整理することを目的としています。