הודעות מוכנות בוואטסאפ: המדריך המלא דרך ה‑API

Picture of Mumble Team

Mumble Team

May 24, 2026 | Reading Time: 6 minutes

הודעות מוכנות בוואטסאפ דרך ה‑API: המדריך המלא

תקציר

הודעות מוכנות (Templates) הן הודעות שנוסחו מראש ואושרו על ידי Meta, וזו הדרך היחידה לפנות ללקוח מחוץ לחלון 24 השעות או בשליחה רחבה. המאמר הזה מסביר מתי צריך הודעה מוכנה, איך עובדות שלוש הקטגוריות (מרקטינג, יוטיליטי, אוטנטיקציה), אילו רכיבים הודעה מוכנה יכולה להכיל, ואיך לעבור אישור בפעם הראשונה. נקודה אחת קריטית: הודעה מוכנה לא ניתנת לעריכה אחרי שנוצרה — תיקון תמיד אומר מחיקה ויצירה מחדש.

למה הודעות מוכנות קיימות בכלל

פלטפורמת WhatsApp Business של Meta בנויה סביב חלון שיחה של 24 שעות: ברגע שלקוח שולח לעסק הודעה, נפתח חלון של 24 שעות שבו העסק יכול להשיב בכל הודעה — טקסט, מדיה, כפתורים, מה שצריך. ברגע שהחלון נסגר, או כשהעסק רוצה לפנות ראשון ללקוח שלא כתב, היחידי שמותר לשלוח הוא הודעה מוכנה שאושרה מראש על ידי Meta.

כל פנייה יזומה ב‑Mumble — קמפיין, תזכורת, OTP, התראת משלוח, הודעה אישית בצ’אט מחוץ לחלון — עוברת דרך הודעה מוכנה. לכן בנייה נכונה של מאגר הודעות מוכנות היא לא פעולה חד‑פעמית בהקמת החשבון אלא תשתית שמלווה את העסק לאורך כל השימוש ב‑Mumble.

שלוש הקטגוריות, ומה כל אחת מאפשרת

Meta מסווגת כל הודעה מוכנה לאחת משלוש קטגוריות. הקטגוריה משפיעה על שני דברים: על המחיר לשליחה, ועל מה שמותר לכלול בהודעה. בחירת קטגוריה שגויה היא הסיבה הנפוצה ביותר לדחייה ולחיוב גבוה מהצפוי.

שלוש קטגוריות ההודעות המוכנות ב‑WhatsApp Business API
קטגוריה מתי משתמשים עלות יחסית
אוטנטיקציה (Authentication) קודי OTP, אימות התחברות, איפוס סיסמה הנמוכה ביותר (בישראל לרוב חינמית או כמעט חינמית)
יוטיליטי (Utility) עדכוני הזמנה, מעקב משלוח, תזכורות תור, אישורי תשלום בינונית
מרקטינג (Marketing) מבצעים, השקות, נטישת עגלה, סקרים, רימרקטינג הגבוהה ביותר

אוטנטיקציה (Authentication) — מה מותר ומה לא

  • תוכן: קוד אימות בלבד, באורך של עד 15 תווים, בתוך משתנה ({{1}}).
  • אסור: לינקים, תמונות, אימוג’י, טקסט שיווקי, וגם לא ברכה ארוכה מסביב לקוד.
  • מותר: כפתור אחד להעתקת הקוד או למילוי אוטומטי באפליקציה.
  • סיכון לדחייה: נמוך, כל עוד ההודעה באמת רק מעבירה קוד ולא מנסה לקדם מוצר במקביל.

יוטיליטי (Utility) — מה מותר ומה לא

  • תוכן: עדכון על פעולה שהלקוח עצמו יזם — הזמנה, פגישה, תשלום, שינוי סטטוס.
  • אסור: כל מילה של פרומו. אפילו “ובהזדמנות, יש לנו 10% הנחה” יסווג מחדש את ההודעה כמרקטינג.
  • מדיה: תמונה, וידאו או מסמך מותרים, אבל רק כשהם משרתים את המטרה השירותית (רשימה משלוח כ‑PDF — בסדר; באנר שיווקי — לא).
  • סיכון לדחייה: בינוני. נופלים בעיקר כשמערבבים פנייה שיווקית עם עדכון שירותי.

מרקטינג (Marketing) — מה מותר ומה לא

  • תוכן: כמעט כל פנייה יזומה — מבצעים, השקות, רימרקטינג, סקרי שביעות רצון.
  • מותר: אימוג’י, לינקים, מדיה, מספר כפתורים, ניסוח חופשי.
  • חובה: הלקוח חייב להיות מנוי מאושר (אשר דיוור). שליחה לרשימה לא מסוננת היא דרך מהירה לפגוע בדירוג האיכות של המספר.
  • סיכון לדחייה: נמוך מבחינת תוכן, גבוה יותר מבחינת איכות — הודעות מרקטינג שמקבלות הרבה חסימות או דיווחי ספאם מורידות את האיכות של כל מספר השולח.

מלכודת הסיווג: אם הודעה מערבבת תוכן יוטיליטי עם משפט אחד שיווקי, Meta מסווגת אותה כמרקטינג — קטגוריית המחיר הגבוהה יותר. כשיש ספק, מפצלים לשתי הודעות מוכנות נפרדות.

רכיבים של הודעה מוכנה

כל הודעה מוכנה בנויה מעד ארבעה רכיבים, חלקם חובה וחלקם אופציונליים. ההיכרות עם הרכיבים והמגבלות שלהם חוסכת רוב סבבי הדחייה.

Header (כותרת) — אופציונלי

  • אחת מהאפשרויות: טקסט, תמונה (Image), וידאו (Video), מסמך (Document).
  • Header טקסטואלי לא יכול להכיל משתנים — זו מגבלה של Meta.
  • במרקטינג, Header עם תמונה מגדיל מאוד את שיעור הפתיחה. ביוטיליטי, מומלץ להישאר עם טקסט פשוט או בלי Header כלל.

Body (גוף ההודעה) — חובה

  • עד 1024 תווים. המונה מופיע בפינת השדה במסך יצירת ההודעה ב‑Mumble.
  • תומך במשתנים ממוקמים בפורמט {{1}}, {{2}}, {{3}} — ברצף, בלי דילוגים.
  • אסור להתחיל או לסיים את ה‑Body במשתנה.
  • אסור ששני משתנים יהיו צמודים, למשל {{1}}{{2}} — חובה טקסט קבוע ביניהם.
  • ערך שמוזרק למשתנה אסור שיכיל שורה חדשה, טאב, או יותר מ‑4 רווחים רצופים.

Footer — אופציונלי

  • טקסט פשוט בלבד, עד 60 תווים, ללא משתנים ובלי מדיה.
  • שימוש קלאסי: הוראת הסרה (“השיבו STOP להסרה”) בהודעות מרקטינג, או חתימה קצרה ביוטיליטי.

כפתורים — אופציונלי

עד 10 כפתורים סך הכול בהודעה אחת, בשילובים גמישים:

  • Quick Reply — כפתור שמחזיר טקסט קבוע לתוך המערכת. שימושי בעיקר בצ’אטבוט, כי הוא מאפשר להסתעף לפי הבחירה של הלקוח.
  • Call to Action — URL — פותח לינק לאתר. מותר עד אחד בהודעה.
  • Call to Action — Phone — מחייג למספר טלפון. מותר עד אחד בהודעה.

אפשר לשלב כפתורי Quick Reply רבים עם כפתור URL ו‑כפתור טלפון יחיד באותה הודעה, כל עוד הסך הכולל אינו עולה על 10.

כללי שם, שפה ומשתנים

שם ההודעה

  • עד 30 תווים, באנגלית בלבד.
  • בלי רווחים — משתמשים בקו תחתון (order_shipped_v2, otp_login_he).
  • אותיות קטנות, מספרים וקו תחתון בלבד. בעברית, באותיות גדולות, או עם תווים מיוחדים — נדחה אוטומטית.
  • השם חייב להיות ייחודי בתוך החשבון. ניסיון לשמור הודעה עם שם שכבר קיים יחזיר שגיאה.
  • הבדיקה הזו רצה לפני בדיקת התוכן של Meta, ולכן שגיאת שם נכשלת מיד.

שפה

  • שפה אחת לכל הודעה. אסור לערבב עברית ואנגלית באותו Body.
  • אם צריך לתקשר עם לקוחות בשפות שונות, יוצרים הודעה נפרדת לכל שפה (לרוב עם שם דומה וסיומת: welcome_he, welcome_en).

משתנים

  • פורמט: {{1}}, {{2}}, {{3}} — ממוקמים, לא בעלי שם.
  • סינטקס כמו {name} או {{first_name}} לא נתמך בהודעות מוכנות. (הסינטקס הזה שייך לקנבס הצ’אטבוט, וזו תפיסה אחרת.)
  • בעת השליחה — דרך קמפיין, צ’אט, או API — ממלאים את הערכים לפי הסדר.

תהליך האישור

  1. שומרים את ההודעה ב‑Mumble. במסך “הודעות מוכנות”, סטטוס “ממתין לאישור” מופיע.
  2. Mumble מעבירה את הבקשה ל‑Meta אוטומטית.
  3. Meta מאשרת או דוחה. בפועל, האישור לוקח בין כמה דקות לכ‑24 שעות — תלוי בקטגוריה ובעומס הצד של Meta.
  4. הודעה מאושרת עוברת לסטטוס “מאושר” וזמינה לשליחה דרך קמפיין, צ’אט, או API.
  5. הודעה שנדחתה עוברת לסטטוס “נדחה” עם סיבת הדחייה.

תיקון הודעה שנדחתה: מחיקה ויצירה מחדש

זו הנקודה החשובה ביותר במאמר הזה, כי היא נוגדת את האינטואיציה: הודעה מוכנה לא ניתנת לעריכה אחרי שנוצרה. אחרי שמירת ההודעה ב‑Mumble — בין אם היא במצב “מאושר”, “ממתין לאישור”, או “נדחה” — היחידי שאפשר לעשות איתה הוא למחוק אותה וליצור חדשה.

לכן, ההתמודדות עם הודעה שנדחתה תמיד נראית כך:

  1. פותחים את ההודעה ב‑Mumble וקוראים את סיבת הדחייה.
  2. מוחקים את ההודעה.
  3. יוצרים הודעה חדשה עם שם חדש (כי שמות הם ייחודיים) ועם התיקון הרלוונטי.
  4. ממתינים שוב לאישור Meta.

המסקנה המעשית: התייחסו לכל הודעה כאל רשומה קבועה. בדקו את השם, הקטגוריה, ה‑Body והמשתנים פעמיים לפני השמירה. עדיף מאגר קטן של הודעות בדוקות מאשר עשרות וריאציות חצי‑עובדות.

דוגמאות

דוגמה ליוטיליטי — אישור משלוח

שם: order_shipped_he
קטגוריה: Utility
Body:

שלום {{1}},
ההזמנה שלך מספר {{2}} יצאה למשלוח ותגיע ב‑{{3}}.
ניתן לעקוב אחרי המשלוח בקישור בכפתור מטה.

Footer: “החנות שלנו, שירות לקוחות בימים א’–ה'”
כפתור: Call to Action — URL, “מעקב משלוח”, מפנה לדף המעקב.

הדוגמה הזו עוברת אישור כי היא מתייחסת לפעולה שהלקוח יזם (הזמנה), אין בה תוכן שיווקי, והמשתנים לא בתחילת המשפט או בסופו.

דוגמה למרקטינג — מבצע סוף עונה

שם: summer_sale_2026
קטגוריה: Marketing
Header: תמונה (Image) — באנר מבצע
Body:

היי {{1}}, סוף עונה אצלנו — הנחה של 30% על כל הקולקציה עד {{2}}.
שווה להציץ לפני שייגמרו המידות. הקופון שלך: {{3}} 🎉

Footer: “השיבו STOP להסרה”
כפתורים: Quick Reply “תראו לי” + Call to Action — URL “לחנות”.

הדוגמה הזו הולמת מרקטינג: יש הצעה ערכית ברורה, כפתור פעולה, תאריך תפוגה, ואופציה ברורה להסרה. האימוג’י מופיע בתוך התוכן עצמו — שם הוא מותר ואף מקובל.

טיפול בבעיות נפוצות

ההודעה נדחתה — “Wrong category”

סימפטום: הודעה שנוסחה כעדכון שירותי הוגשה כ‑Utility ונדחתה, או להפך — הודעה שיווקית הוגשה כיוטיליטי.
סיבה: Meta סורקת את התוכן ומשווה לקטגוריה שבחרתם. אפילו משפט אחד שיווקי בתוך הודעת שירות יסווג את כל ההודעה כמרקטינג.
פתרון: מוחקים, יוצרים מחדש עם הקטגוריה הנכונה, או מפצלים לשתי הודעות נפרדות אם התוכן באמת מעורבב.

ההודעה נדחתה — משתנה בתחילת ה‑Body או בסופו

סימפטום: דחייה מיידית, סיבה כללית של “פורמט תוכן”.
סיבה: כלל של Meta — אסור להתחיל או לסיים את ה‑Body במשתנה. {{1}}, ההזמנה שלך יצאה ייכשל.
פתרון: מוסיפים טקסט קבוע סביב המשתנים. שלום {{1}}, ההזמנה שלך יצאה. יעבור.

ההודעה נדחתה — שני משתנים צמודים

סימפטום: דחייה על {{1}}{{2}} ברצף.
סיבה: Meta דורשת טקסט קבוע בין כל שני משתנים, כדי שערך המשתנה לא ידלוף לתוך השני.
פתרון: מפרידים במילה, פסיק, או רווח — לדוגמה {{1}} ({{2}}).

שם ההודעה לא מתקבל

סימפטום: השמירה ב‑Mumble נכשלת לפני שהבקשה בכלל מגיעה ל‑Meta.
סיבה: השם כולל עברית, רווחים, אותיות גדולות, או שתווי קצה אחרים. בנוסף, השם כבר תפוס בחשבון.
פתרון: שם באנגלית בלבד, אותיות קטנות, מספרים, וקו תחתון. אם השם תפוס, מוסיפים סיומת גרסה (_v2, _he).

שליחת ההודעה דרך ה‑API מחזירה שגיאה אף שהיא מאושרת

סימפטום: ההודעה מופיעה כ”מאושר” אבל קריאת ה‑API מחזירה שגיאה.
סיבה: לרוב, פורמט מספר טלפון לא תקין, חוסר התאמה בין מספר המשתנים שנשלחו בקריאה לבין מספר המשתנים שמוגדרים ב‑Body, או ניסיון לשלוח לקוח שלא אישר דיוור עבור הודעות מרקטינג.
פתרון: מספר בפורמט בינלאומי בלי + ובלי 0 מוביל (972501234567); אותו מספר משתנים בקריאה כמו ב‑Body; ולקוח עם אשר דיוור תקף עבור Marketing.

ההודעה אושרה פעם, ועכשיו נכנסה למצב “מושהה”

סימפטום: הודעה שעבדה זמן רב עברה למצב Paused על ידי Meta.
סיבה: ירידה באיכות — חסימות, דיווחי ספאם, שיעור קריאה נמוך מהממוצע.
פתרון: מצמצמים את התפוצה, מוודאים שכל הנמענים אישרו דיוור, בודקים את הניסוח. אחרי תקופה של איכות יציבה, Meta תחזיר את ההודעה למצב מאושר.

קישורים קשורים

שורה תחתונה

הודעה מוכנה היא רשומה קבועה: שם, קטגוריה ותוכן נכונים מהפעם הראשונה חוסכים סבבי דחייה, כי תיקון תמיד אומר מחיקה ויצירה מחדש — לא עריכה.

Picture of מאמבל

מאמבל

מאמבל מתמחה בשדרוג תקשורת עסקית באמצעות פתרונות WhatsApp חדשניים. אנחנו מתמקדים בשיפור תהליכי מכירה, ניהול לידים ואוטומציה של מעורבות לקוחות, מה שמאפשר לעסקים לצמוח בצורה חכמה ומהירה יותר. מתוך תשוקה ליעילות ולחדשנות, צוות Mumble ממשיך להגדיר מחדש את הדרך שבה חברות מתחברות ללקוחות שלהן.