עיצוב תוכן ההודעה במרפאת שיניים: אילו שדות תזכורת באמת צריכה, למה משתני תבנית הם החלטת חשיפה, הסכמה לפי ערוץ ומטרה, ולינק תשלום בלי הקשר קליני.
עיקרי הדברים
- מידע על תורים וטיפולים הוא מידע אישי מסוג רגיש. איזה חלק ממנו מופיע בהודעה למכשיר הוא בחירה של מי שבנה את התבנית.
- תזכורת פועלת עם ארבעה שדות: שם פרטי, מועד, זיהוי המרפאה ומסלול אישור או שינוי. שם הטיפול אינו אחד מהם.
- משתנה בתבנית שמקבל טקסט חופשי ממערכת אחרת הוא הדרך הנפוצה ביותר שבה תיאור קליני נוחת בהודעה בלי שאיש התכוון.
- הסכמה נשמרת לפי ערוץ ולפי מטרה, עם זמן ומקור. סימון בוליאני אחד לכל מטופל אינו מספיק כדי לענות על השאלה "למה נשלחה ההודעה הזו".
תוכן ההתראה הוא החלטת תכנון, לא תוצר לוואי של השדות שקיימים במערכת. תזכורת יכולה לומר "התור שלך מחר ב-10:00" ולעשות את אותה עבודה בדיוק כמו תזכורת שמפרטת טיפול. הטקסט כאן הוא תיאור טכני של עיצוב הודעות ותהליכים, ואינו ייעוץ רפואי, משפטי או פיננסי.
ההודעה שיוצאת, והשדות שמאחוריה
תזכורת אמיתית לתור נראית כך: "שלום דנה, תזכורת לתור שלך במרפאה מחר, יום שלישי, בשעה 10:00. לאישור השיבי 1, לשינוי השיבי 2." זו הודעה שעושה את כל העבודה: מזהה את הנמענת, נותנת מועד, נותנת מסלול פעולה. למדריך מעשי ראו איך בונים בוט וואטסאפ.
מה שהיא לא עושה הוא לתאר למה התור נקבע. ההבדל בין שתי הגרסאות הוא שורה אחת בקוד שמרכיב את ההודעה:
| השדה | בהודעה למכשיר | ביומן הפנימי | בתיק המטופל |
|---|---|---|---|
| שם פרטי | כן | כן | כן |
| מועד ומשך | מועד בלבד | מועד ומשך | מועד ומשך |
| שם המטפל | לא נדרש | כן | כן |
| סוג הטיפול | לא | קוד פנימי בלבד | כן |
| הערות קליניות | לא | לא | כן |
| סכום לתשלום | בהודעת תשלום נפרדת | כן | כן |
| מסלול אישור או ביטול | כן | כן | לא רלוונטי |
עמודת "בהודעה למכשיר" היא הקצרה ביותר מכולן, וזו הנקודה. מסך נעול בטלפון מציג תצוגה מקדימה, מכשירים משותפים בבית קיימים, וצילום מסך של הודעה נודד. מנגנון התזכורות עצמו, כולל תזמון וטיפול באי-הגעה, מפורק בתזכורות אוטומטיות והפחתת אי-הגעה לתורים.
למה משתני התבנית הם החלטת החשיפה האמיתית?
כי תבנית ב-WhatsApp Cloud API אינה טקסט חופשי. היא מבנה עם משתנים ממוספרים, {{1}}, {{2}} וכן הלאה, ומה שנכנס לכל משתנה נקבע בקוד ששולח אותה. תבנית תזכורת סבירה נראית כך:
{{1}}- שם פרטי בלבד.{{2}}- מועד מלא בפורמט אחיד.{{3}}- שם המרפאה או מספר טלפון לחזרה.
הכשל הנפוץ אינו בתבנית אלא במיפוי: מישהו מחבר את {{2}} לשדה "כותרת התור" מהיומן, ובאותו שדה יש טקסט חופשי שהצוות הקליני כתב. מאותו רגע ההודעה מדווחת לנמען כל מה שהצוות רשם בכותרת. משתנה בתבנית צריך להיות מחובר לשדה מובנה, לעולם לא לשדה טקסט חופשי. לעלויות בנייה ותפעול ראו כמה עולה צ'אטבוט.
שתי מגבלות מתועדות שכדאי לתכנן סביבן:
- מחוץ לחלון של 24 שעות אפשר לפנות רק בתבנית מאושרת. כל הודעה נכנסת מהמטופל פותחת ומאפסת חלון שירות בן 24 שעות, ובתוכו אפשר להשיב בטקסט חופשי.
- תבנית נבדקת לפני שהיא מאושרת. תוכן ומבנה מוגשים ל-Meta מראש, וזו הזדמנות טובה לוודא שאין בתבנית מקום שאליו יכול לזלוג תיאור קליני. תהליך ההגשה עצמו מפורק באישור תבניות WhatsApp.
הסכמה כרשומה לפי ערוץ ומטרה
סימון אחד "מסכים לקבל הודעות" עונה על שאלה אחת ומשאיר פתוחות שלוש. הרשומה שעונה על כולן נושאת ארבעה שדות: נמען, ערוץ, מטרה וזמן:
| ערוץ | מטרה | דוגמה למה שנשלח |
|---|---|---|
| תזכורת תור | מועד ומסלול אישור | |
| SMS | תזכורת תור | אותו תוכן, ערוץ גיבוי |
| דוא"ל | מסמכים וחשבוניות | קבלה, אישור תשלום |
| פניות שיווקיות | מבצע, תזכורת ביקורת תקופתית |
הפרדת השורה הרביעית מהראשונה היא ההבדל בין מטופל שיכול להפסיק לקבל שיווק ולהמשיך לקבל תזכורות, לבין מטופל שנאלץ לבחור בין הכול לכלום. כל שורה נושאת גם source - איפה ההסכמה נרשמה, בטופס קליטה או בהודעה חוזרת - וזמן. השוואה מעשית בין הערוצים עצמם מופיעה ב-SMS מול WhatsApp מול דוא"ל לתזכורות.
מה לינק תשלום צריך לדעת על הטיפול?
כלום. עמוד תשלום עובד עם ארבעה נתונים: מזהה חיוב, סכום, מטבע ותוקף. שם הטיפול אינו נדרש כדי לגבות, והוא גם מה שהופך את הקישור למסמך שאסור לשלוח הלאה.
מבנה סביר לחיוב:
charge_id- מזהה אטום ולא ניחוש, ולא מספר רץ.patient_ref- הפניה פנימית, לא ת"ז ולא שם מלא בכתובת ה-URL.amountו-currency- הסכום כפי שנרשם בחשבונית, כולל מע"מ לפי ההגדרה במרפאה.expires_at- תוקף. קישור תשלום שלא פג הוא קישור שממשיך לעבוד שנה אחרי.invoice_id- הקישור לחשבונית, שהיא המסמך שנושא את הפירוט.
הפירוט חי בחשבונית, והחשבונית נשלחת לערוץ שהוגדר למסמכים. ההודעה הקצרה בטלפון מפנה אליה ואינה מכילה אותה.
מי רואה מה: תפקידים מעל שלושה מאגרים
הפרדה מעשית מתחילה בשלושה מאגרים נפרדים, ולא בשדה הרשאה אחד על טבלה אחת:
- יומן ותורים - מועדים, מטפל, סטטוס הגעה. פקידת קבלה צריכה גישה מלאה.
- תיק קליני - אבחנות, טיפולים, צילומים. גישה לצוות מטפל.
- חיובים ומסמכים - חשבוניות, קבלות, יתרות. גישה להנהלת חשבונות.
התפקיד שמייצר את רוב התקלות הוא ספק חיצוני: מי שמפעיל את המרכזייה, את מערכת התזכורות או את הצ'אט. לפעמים הוא צריך גישה ליומן, וכמעט לעולם לא לתיק הקליני. ההפרדה הזו נאכפת ברמת הנתונים ולא ברמת המסך, למשל בעזרת מדיניות שורה כמו זו שמתועדת ב-PostgreSQL Row Security Policies.
מה נשבר בפועל
- כותרת יומן חופשית שנשלחת כמשתנה. התיאור שהצוות כתב לעצמו הופך לתוכן ההודעה.
- תור שנדחה ותזכורת שיצאה בכל זאת. הביטול עודכן ביומן ולא בתור השליחה.
- קישור תשלום בלי תוקף. חודשיים אחר כך מישהו לוחץ עליו שוב ומשלם פעמיים.
- הסכמה שנרשמה פעם אחת בלי ערוץ. אי אפשר לענות למה נשלחה הודעה מסוימת בערוץ מסוים.
- תבנית אחת לשני שימושים. תזכורת שמשמשת גם למבצע מערבבת שתי מטרות שמטופל היה מפריד ביניהן.
- צילומים שנשלחים בצ'אט. קובץ שיצא לצ'אט אינו מנוהל על ידי מדיניות השמירה של התיק.
מקורות
שאלות נפוצות
האם מותר לכתוב את שם הרופא בתזכורת?
זו החלטה של המרפאה ולא כלל טכני. מבחינת תכנון, שם מטפל הוא שדה נוסף שמצטרף להודעה ואינו נדרש כדי לאשר או לשנות תור. אם מחליטים לכלול אותו, כדאי שיהיה שדה מובנה נפרד ולא חלק ממחרוזת חופשית שנשאבת מהיומן.
מה עדיף לתזכורות, WhatsApp או SMS?
WhatsApp מאפשר מסלול תשובה דו-כיווני שמאפשר אישור וביטול באותו שרשור, ולכן הוא מקצר את הטיפול. SMS אינו תלוי בחשבון וביישום ולכן הוא גיבוי טוב. מרפאות רבות מפעילות את שניהם עם אותו תוכן בדיוק ובחירה לפי הסכמה קיימת.
איך יודעים אם התזכורת בכלל הגיעה?
דרך עדכוני הסטטוס של ההודעה שמגיעים ב-webhook, ולא דרך העובדה שהקריאה ל-API הצליחה. שליחה מוצלחת אומרת שההודעה התקבלה לעיבוד. כדאי לשמור לכל תזכורת את מזהה ההודעה ואת הסטטוס האחרון, ולהתריע על תזכורות שנתקעו.
האם צריך תבנית נפרדת לעברית ולאנגלית?
כן. תבנית מוגשת לאישור עם שפה מוגדרת, ולכן שתי שפות הן שתי תבניות עם אותו שם ושפות שונות. שמירת מזהה שפה לכל מטופל מונעת את המצב שבו נמענת שקבעה עברית מקבלת תזכורת באנגלית משום שזו התבנית שאושרה ראשונה.
להמשך קריאה
שירות רלוונטי
WhatsApp Cloud API
תבניות, אינבוקס דו-כיווני ותזכורות על ה-API הרשמי של Meta.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.