
ほとんどのWordPressサイトでは、WhatsAppは単なるボタンとして扱われています。訪問者がそれをタップするとチャットウィンドウが開き、チームの誰かが起きてスマートフォンを確認していなければなりません。サイトが行うその他の機能はすべて、依然として受信トレイに届きます。.
代償とは、メッセージが届かないことではない。その空白である。見積もり依頼が9時間も未読のまま放置される。編集者は、投稿が金曜日に保留中レビュー送りにされていたことを月曜日に知る。バックアップ失敗のメールが、3月以来誰も開いていないフォルダに届く。.
WordPress向けのWhatsApp自動化は、サイト自体に送信を行わせることでそのギャップを埋めます。フォーム送信、ユーザー登録、投稿ステータスの変更、または外部の監視サービスからのアラートにより、必要な詳細があらかじめ入力された状態で、WhatsAppメッセージを自動的にプッシュ送信することができます。.
WordPress向けのWhatsApp自動化機能により、WordPressのイベント、プラグインの送信、または外部Webhookをトリガーとして、WhatsAppメッセージを自動的に送信することができます。. Bit Flows を使用すると、トリガーデータを取得し、ルールや AI を適用し、必要に応じて承認待ちで一時停止し、最終的なメッセージを WhatsApp Business Platform を通じて送信することができます。.
以下の7つの例は、Bit Flowsでカスタムコードを使用せずにこれらのワークフローを構築する方法を示しています。.
WordPressにおけるWhatsApp自動化とは、WordPress、連携されたプラグイン、または外部のイベントが、手動作業なしでWhatsAppビジネスプラットフォーム経由のWhatsAppメッセージをトリガーするすべての設定のことです。.
Bit Flows 単なる単一のルールではなくワークフローとして扱うため、1つのトリガーからメッセージが送信されるまでに、条件分岐、遅延、AIエージェント、または人間の承認を通過させることができます。.
| トリガー | 中央のロジック | WhatsAppに何が届くのか |
| フォーム送信成功 | 必須のリード項目を条件とする | 営業チームへの詳しいお問合せ |
| ビットアシストウォッチの提出 | チャットモデル、メモリ、およびツールを備えたAIエージェント | 機密サポートリクエスト |
| WordPressユーザー登録 | 遅延 | チームへの登録アラート |
| WordPressの投稿ステータス更新時 | 保留中のレビューの条件 | 編集者レビューの警告 |
| ワードプレスのコメント投稿 | モデレーション状態を条件とする | 承認待ちのコメント |
| WPForms フォーム送信 | 条件、AIエージェント、ヒューマン・イン・ザ・ループ、条件 | 承認または却下の決定 |
| 受信ウェブフック | 3つの別々の条件分岐 | アップタイム、バックアップ、またはセキュリティアラート |
以下のワークフローはすべてWhatsAppのアクションで終わるため、接続を一度設定すれば、残りのワークフローで再利用できます。準備するものは以下の4つです: Bit Flowsの設置, 、フローを起動するソース、WhatsApp Businessアプリ、および現実的なテスト送信。.
Bit Flows → Flows を開き、フローを作成または開いて、プラスアイコンをクリックし、「WhatsApp」を検索して、「メッセージを送信」を選択します。次に、WhatsApp Business アプリから、「ビジネスアカウント ID」、「電話番号 ID」、および「アクセストークン」の 3 つの値を取得します。.
よくある設定の失敗は、一時アクセストークンの有効期限が切れた後も使い続けることです。セットアップ時にMetaが提供するトークンは一時的なものです。有効期限は24時間で、その後連携が停止します。.
まず永続トークンを設定してください。作成する 事業ポートフォリオ, 、システムユーザーを管理者(Admin)ロールで追加し、そのユーザーにアプリを割り当ててから、「whatsapp_business_messaging」と「whatsapp_business_management」にチェックを入れてトークンを生成します。その WhatsApp アクションガイド Metaが何かを移動させた場合でも、現在の画面があります。.
顧客、見込み客、応募者に自動メッセージを送信する前に、必要なWhatsAppのオプトイン(受信許可)または連絡の許可を取得していることを確認してください。24時間のカスタマーサービスウィンドウと承認済みテンプレートのルールが引き続き適用され、電話番号を収集しただけでは、すべての発信メッセージが自動的に許可されるわけではありません。.
もう1つ:メールチャネルを使用する場合は、信頼性の高いWordPressメール配信を設定してください。 SMTP. Gmailを使用している場合は、ヒューマン・イン・the・ループ(Human in the Loop)のステップで求められるGmailアカウントを接続し、承認してください。.

まずはこれからはじめましょう。数分で終わりますし、リードを週末ずっと未読のまま放置することには、実際に金額換算できるコストが生じますから。.
トリガーとして「Bit Form」を設定し、「送信成功」を選択して、お問い合わせフォームまたは「任意のフォーム」を選び、実際の入力内容を送信して応答を取得します。この操作を最初に行う必要があります。なぜなら、取得されていないフィールドを、下流の処理でマッピングすることはできないからです。 Bit Form トリガーガイド セットアップをカバーしています。.
次にフィルターを追加します。電話番号とメールアドレスの両方が存在する場合にのみフローが継続するように、ANDルールを設定した条件(Conditional)ノードを使用します。そうしないと、途中で中断されたすべての送信データが、営業チームが信頼すべきチャネルに届いてしまいます。一致する分岐をWhatsAppに接続し、固定の営業用番号を指定して、フィールドをメッセージにマッピングします。.
電源を入れる前に、ライブフローを通じてもう1件のエントリを送信し、WhatsAppのメッセージとBit Formのエントリを並べて比較してください。この比較を行うことで、他の方法では見つからないマッピングの誤りを発見できます。.

サポートリクエストは整理されて届くわけではありません。決済システムがダウンしているというものもあれば、パスワードの変更方法を尋ねるものもあり、どちらも同じウィジェットに届きます。A 条件 予測可能なフィールドやルールによって緊急性がすでに示されている場合にうまくいきます。自由記述のメッセージの意味から緊急性を推測する必要がある場合には、AIエージェントの方が適しています。.
ザ AIエージェント メッセージを読み取り、残りのフローが処理できるものを返します。チャットモデル、オプションのメモリ、およびアタッチする任意のツールを備えたツールエージェントとして実行されます。このビルドは使用しています OpenAI, 、Simple Memory、およびNotionを「データベースの取得」に設定することで、エージェントがメッセージを単独で判断するのではなく、分類時に自分のレコードから引き出せるようにします。.
トリガーのセットアップは、以下を通じて実行されます Bit Assist ガイド.
プロンプトを具体的に絞り込んでください。そうしないと、エージェントはアドリブで処理してしまいます。閉じたリスト(選択肢が限定されたリスト)を提示することで、次のノードが照合できる基準を与えられます:
あなたはWordPressサイトから送信されたサポートリクエストを分類します。送信されたメッセージのみを使用してください。不足している詳細を発明しないでください。
URGENT、TECHNICAL、BILLING、GENERALのいずれか1つのカテゴリを正確に返してください。
ウェブサイトの停止、セキュリティ問題、アカウントのロックアウト、決済をブロックする問題、またはデータ損失の場合のみURGENTを使用してください。
カテゴリの後に、1文の要約を書いてください。.
その閉じたリストにより、次のステップの評価値を予測可能にすることができます。WhatsAppが緊急のリクエストのみを受信するようにしたい場合は、AIエージェントの後に条件(Condition)を追加し、「URGENT」に一致させ、そのブランチのみを接続します WhatsAppのアクション. 他のカテゴリーはそこで停止するか、別の処理にルーティングできます。.

3つのノードがあり、真ん中のノードがこれが機能する理由です。登録と同時に発火する登録アラートは、チームの作業中に届き、スワイプして消されてしまいます。各登録アラートを一定期間待ってから送信したい場合にのみ、「遅延(Delay)」を追加します。遅延はアラートを延期するものであり、複数の登録を1つのメッセージにまとめるわけではありません。.
設定 WordPressトリガー ユーザー登録イベントに移動し、テストユーザーを登録してレスポンスを取得します。.
落として 遅延 トリガーとアクションの間に「実行遅延時間(Execution Delay Time)」を設定し、「時間単位(Time Unit)」を「分(Minutes)」に設定します。時間、日、週、月も利用可能です。.
マッピングされたチーム番号ではなく、固定されたチーム番号に送信します。それが、このワークフローを簡単にリリースできる実用的な理由です。チームへのメッセージ送信には、すでに取得しているユーザー名とメールアドレス以外、キャプチャされたデータから必要なものはありません。.

設定 WordPressトリガー On Post Status Update イベントに移動し、テスト投稿を「下書き」から「レビュー待ち」に変更して、何が返されるかを確認します。.
ザ 条件/フィルター nodeがここにふさわしいのは、「On Post Status Update」がステータスの変更ごとに実行されるからです。公開、予約投稿、ゴミ箱行き、そのすべてです。フィルターがなければ、エディターもそのすべてを受け取ることになります。.
1つのブランチを追加し、「Pending Review」という名前を付けます。キャプチャしたレスポンスから投稿ステータスをマッピングし、演算子を「Equal to」に設定します。チュートリアルからのフィールドパスではなく、テストが返した正確な値を使用してください。推測されたパスは何もエラーを出さずに失敗するためです。そのブランチのみがWhatsAppに接続されます。他のすべては「No Condition Matched」に着地し、そこで停止します。.
不規則にコメントが寄せられるサイトでは、コメントのモデレーションは見落としがちです。キューを3回確認して何も見つからないかと思えば、実際に対処が必要だった1件を見逃してしまうのです。.

設定 WordPressトリガー コメント投稿(Comment Post)に移動し、WordPressが即座に公開せず保留にするテスト用コメントを送信して、キャプチャされたデータを確認します。.
追加 条件 承認フィールドでは、テストが返した正確な保留中の値を使用してください。ペイロードから信頼できるモデレーション状態が得られない場合は、これを有効にする前に、別のネイティブコメントイベントで得られるかどうかを確認してください。承認は引き続きWordPressで行われます。WhatsAppは何か待ち状態であると通知するだけです。.

これは盗む価値のあるパターンであり、クリックパスよりもその理由付けが重要である。AIはアプリケーションを読み込み、整理することに長けている。誰かを承認するべきなのはAIではない。エージェントが準備し、人間が決定し、WhatsAppが結果を報告する。.
会員登録、パートナー申請、ベンダーのオンボーディング、アクセスリクエストに適合します。.
フォームから始めましょう。こちらがそれです。 WPForms トリガー フォームの送信(サポートされているどのビルダーでも動作は同様です)。完全なテストアプリケーションをキャプチャし、使用予定のすべてのフィールドが正しく送信されたことを確認します。.
それから 条件/フィルター eligibility checkという名前のブランチを作成し、ウェブサイトが存在し、WhatsApp番号が存在し、メールアドレスが存在し、理由が存在するというANDロジックを使用して、不完全なデータが人間の担当者に一切届かないようにします。.
ザ AIエージェント ツールエージェントとして実行される ディープシーク シンプルメモリと2つのツール(データベースを取得するように設定されたNotionと、テーブル(すべて)を取得するように設定されたwpDataTables)を備えたチャットモデル。要約のみを行うように制限する:
応募者、企業、応募種類、関連経験、懸念事項、不足情報、レビュアーのまとめ.
承認を完了する。追加する 人間参加型, 、チャネルとしてGmailを選択し、「メールの送信と応答の待機」を選びます。最後の部分がポイントで、メールを送信してそのまま処理を進めるのではなく、フローが一時停止します。.
Map the applicant details and the AI summary into the message body. HTML is supported, which matters when someone is reading a structured summary on a phone. Set Approval Options to Approve and Disapprove. For this workflow, set the rejection behavior to Continue the Flow so the next Condition can read the returned status and send the rejected WhatsApp message. Set the deadline behavior separately based on what you want to happen when nobody responds.
A final Conditions/Filters node reads the returned status and splits: Approved Condition to one WhatsApp message, Disapproved Condition to another. Use the exact strings your own test returned.
Approved:
Hi {name}, your application has been approved. Continue here: {onboarding_url}
Rejected:
Hi {name}, thank you for applying. We reviewed your application
and cannot approve it at this time.

The first six workflows start inside WordPress. This one starts outside it. An uptime monitor, a backup service, or a security scanner posts to a Bit Flows webhook, and the conditions decide which alert goes out.
セット Incoming Webhook trigger as the trigger with Incoming Webhook, add a webhook, and paste the generated URL into the monitoring service. Then fire a real test event from that service and capture the payload.
One endpoint works when every service sends a predictable identifying value:
{
"source": "uptime",
"status": "down",
"site": "Main Website",
"message": "The website did not respond"
}
Build three branches inside a single 条件/フィルター node. Uptime matches when source is uptime and status is down. Backup matches on failed. Security matches on critical severity. Each branch wires to its own WhatsApp action, so an SSL warning does not land worded like a total outage, and anything unrecognised stops at No Condition Matched.
If the payloads differ structurally, three small flows with three separate webhooks is the cleaner build. Each gets its own capture, mapping, and logs, and you stop writing conditions around fields that only exist in one payload.
Three things, and two of them come from Meta rather than Bit Flows.
The 24-hour window catches almost everyone. Under the WhatsApp Business Messaging Policy, free-form messages only send inside a 24-hour window that opens when the recipient messages your business number. Outside it, you need an approved template. That includes your own editors and sales team. If your editor has not messaged that number since yesterday, Send Message will not reach them and Send Template Message is the fix. This is the usual reason a workflow tests perfectly and fails in production.
Costs sit outside Bit Flows. No per-task charge here, but Meta bills template messages under its own pricing rules, and a DeepSeek or OpenAI agent bills per token. Check both before you go from ten messages a day to a thousand.
Mapping is only as good as your capture. A common cause of empty or incomplete messages is a response captured with dummy data, or captured before a field existed. Capture again, then reopen the action.
When something fails, open Logs and read each node’s input and output in order. The node that broke is usually one step earlier than the node that errored.
The appeal here is simple. Your site already produces the signals. They just end up somewhere nobody reads. Routing them to WhatsApp is mostly a matter of picking the trigger and letting the flow carry the details across.
Start with one. Send a real submission through, watch it arrive on your phone, and let it run for a week. That first message landing correctly tells you more than any amount of planning, and once one flow works, the rest are variations on the same build.
Three habits keep them healthy. Capture real data before you map it. Keep fixed rules in Conditions and save the AI Agent for what genuinely needs interpreting. Check the Logs before you switch anything on.
These workflows need no custom code and no separate automation platform, though the services you connect still bring their own accounts and pricing. The Bit Flows user guide has the node-level setup, and the WhatsApp action page covers the connection screens in full.
Yes, Bit Flows can trigger a WhatsApp action from form submissions, WordPress events, Bit Assist requests, incoming webhooks, and other supported triggers without any code.
Yes, the connection requires a WhatsApp Business Account ID, a Phone Number ID, and an access token generated through a WhatsApp Business app in Meta’s developer console.
Bit Flows documents eight events: Send Template Message, Send Message, Send Document, Send Image, Send Audio, Send Video, Send Sticker, and Send Location.
Meta issues a temporary token valid for 24 hours during setup, so you need to create a Business Portfolio and generate a permanent token before the integration runs reliably.
Yes, once a WhatsApp connection exists you can select it from the dropdown in any other flow instead of re-entering the Business ID, Phone Number ID, and token.
No, use Conditions for predictable field checks and reserve the AI Agent for workflows that need free-text content classified, summarised, or interpreted.
Yes, provided every service sends a reliable source or event-type field that your Conditions can evaluate, otherwise separate webhooks are the cleaner build.
Create separate webhooks when services send different payload structures, different authentication, or different fields that need independent testing and debugging.
Complete the connection and field mapping, click Test Run to check the output, then run the full workflow with Test Flow Once and confirm the result in Logs.
No, the Bit Flows documentation states that Test Run output appears above the button but is not recorded in workflow Logs, so run the full flow for a permanent record.
Check the 24-hour customer service window first, since free-form messages only reach recipients who messaged your business number recently, otherwise an approved template is required.
Yes, Human in the Loop pauses the workflow through Gmail or Mail until a reviewer approves or disapproves, then routes the result to different WhatsApp actions.
Yes, enable Notification of Failed Tasks in Bit Flows Settings, add a notification email address, and confirm SMTP is working so failure emails are delivered.
Capture a fresh trigger response using realistic data, then reopen the WhatsApp action so Bit Flows exposes the new field in the mapping panel.
