איך בונים טופס יצירת קשר חכם ב-Base44
בפורומים של בעלי עסקי שירות חוזרת אותה שאלה בניסוחים שונים: כמה זמן הולך רק על לקלוט לקוח חדש. התשובות כמעט תמיד מתארות את אותה עבודה. להעתיק פרטים ממייל לגיליון, לחפש למי כבר חזרו, ולהיזכר בפנייה שנקברה בין ההודעות.
התהליך הזה מתחיל בטופס יצירת קשר. ורוב הטפסים באתרים הם לא באמת טפסים: הם כפתור ששולח מייל. מהרגע שהפנייה קיימת רק כמייל, כל מה שקורה אחריה הוא ידני.
המדריך הזה עובר על בניית טופס ב-Base44 שהוא תחילת תהליך ולא סוף שלו. הדוגמאות מבוססות על הטופס שרץ באתר הזה.
למה טופס ששולח רק מייל עולה לכם בזמן
שלוש בעיות מגיעות יחד עם המייל. הראשונה היא שאין רשומה: הפנייה חיה בתיבת הדואר, ותיבת דואר לא יודעת להגיד מי כבר קיבל מענה. השנייה היא שאין סטטוס, ולכן "טיפלתי בזה" הוא זיכרון ולא נתון. השלישית היא שאין מדידה: אי אפשר לענות על שאלה כמו כמה פניות הגיעו החודש, או כמה זמן עובר בממוצע עד שחוזרים ללקוח.
יש גם תרחיש גרוע יותר. אם שירות המיילים נכשל לרגע, וההודעה לא נשלחה, הפנייה נעלמה בלי שאף אחד ידע שהיא הייתה קיימת.
מה בעצם הופך טופס לחכם
לא AI. שלושה דברים פשוטים: הפנייה נשמרת כרשומה, לרשומה יש סטטוס, וההתראה מגיעה במבנה שמאפשר לפעול מיד. כל השאר, כולל סיווג אוטומטי או מענה ראשוני, נבנה מעל השלד הזה. בלי השלד, כל שכבה חכמה שתוסיפו יושבת על אוויר.
איך מגדירים את הישות ששומרת את הפניות
בישות אחת, עם השדות שבאמת נחוצים. בטופס של האתר הזה הישות היא ContactMessage, והשדות הם שם, אימייל, טלפון, נושא, תוכן ההודעה, וסטטוס. הסטטוס הוא רשימה סגורה עם שלושה ערכים: חדש, נקרא, נענה, וברירת המחדל היא חדש.
שימו לב לחלק שקל לפספס: רק שני שדות מוגדרים כחובה ברמת הישות, שם והודעה. כל שדה חובה נוסף הוא עוד סיבה שמישהו יסגור את הדף באמצע. את הכללים העדינים יותר (למשל שצריך טלפון או אימייל, לפחות אחד מהם) עדיף לאכוף בשלב הבא, ולא בסכימה.
למה ההרשאות הן ההחלטה הראשונה ולא האחרונה
טופס יצירת קשר הוא מקרה נדיר שבו הכתיבה פתוחה לגמרי והקריאה סגורה לגמרי. כל אדם אנונימי שנכנס לאתר חייב להיות מסוגל ליצור רשומה, אחרת אין טופס. ואף אחד חוץ מכם לא אמור להיות מסוגל לקרוא אותן, אחרת רשימת הפניות שלכם היא דף ציבורי.
בישות של האתר הזה זה מוגדר בדיוק כך: יצירה פתוחה, וקריאה, עדכון ומחיקה מוגבלים למנהל בלבד. זו ההגדרה שכדאי לבדוק בעיניים לפני שמעלים טופס לאוויר, כי ברירות מחדל נדיבות מדי הן אחת התקלות היקרות שקל לפספס. הרחבתי על החלק הזה, ועל עוד כמה מקומות שדורשים בדיקה ידנית, בחסרונות של Base44 שכדאי להכיר מראש.
איך שולחים התראה בלי לאבד פנייה
הסדר הוא כל העניין: קודם שומרים את הרשומה, ורק אחר כך שולחים את ההתראה. אם שירות המיילים מחזיר שגיאה, הליד עדיין אצלכם. הסדר ההפוך, שבו שולחים מייל ומקווים לטוב, הוא בדיוק איך שפניות נעלמות.
שני פרטים קטנים שמשנים את חוויית המענה. הראשון: מגדירים את כתובת השולח ככתובת המענה בהתראה, כך שלחיצה על "השב" בתיבה שלכם פונה ללקוח ולא למערכת. השני: מנרמלים את מספר הטלפון לפני שבונים ממנו קישורים. בטופס של האתר הזה מספר שמתחיל באפס מומר לקידומת 972, וכך הקישור לחיוג והקישור לוואטסאפ בתוך ההתראה פשוט עובדים בלחיצה מהנייד.
מה צריך להופיע בהתראה עצמה
ההתראה היא לא הודעה על כך שהגיעה פנייה. היא הפנייה עצמה. אם צריך לפתוח את המערכת כדי להבין מה מישהו רצה, ההתראה לא עשתה את העבודה שלה, והיא בעצם רק הוסיפה שלב.
בהתראה של האתר הזה מופיע הכל: השם, הטלפון כקישור לחיוג ולוואטסאפ, האימייל כקישור מענה, הנושא, וגוף ההודעה במלואו. זה נשמע טריוויאלי, אבל זה ההבדל בין פנייה שאפשר לסגור מהנייד בשתי דקות לבין פנייה שנדחית לערב, ומשם למחר. רוב הפניות שהולכות לאיבוד לא נמחקות. הן פשוט נדחות מספיק פעמים.
למה ולידציה חייבת לרוץ גם בצד השרת
הבדיקה בדפדפן היא חוויית משתמש. הבדיקה בפונקציית הצד השרתי היא הכלל עצמו. אפשר לעקוף טופס בדפדפן, ולכן כל דבר שחשוב לכם באמת צריך להיבדק שוב במקום שאי אפשר לערוך.
בפונקציה של האתר הזה הכלל הוא שלושה תנאים: יש שם, יש הודעה, ויש לפחות אחד מבין טלפון ואימייל. אם משהו חסר, הפונקציה מחזירה שגיאה מובנית עם רשימת סיבות, כל אחת עם קוד ועם הסבר בעברית, כדי שהטופס יוכל להצביע על השדה הנכון במקום להציג "משהו השתבש". אם אתם עורכים קוד של פונקציות מתוך המחשב שלכם ולא רק בעורך של הפלטפורמה, כתבתי איך הסנכרון הזה עובד במדריך על Base44, GitHub וקלוד.
איך הופכים את הטופס לתחילת תהליך
שדה הסטטוס הוא ההבדל בין ארכיון לבין תור עבודה. מסך ניהול פשוט שמציג פניות חדשות למעלה, ומאפשר לסמן נקרא או נענה, כבר עונה על השאלה שגוזלת הכי הרבה זמן: למי עוד לא חזרנו.
משם ההרחבות הן החלטות עסקיות, לא טכניות. אישור אוטומטי ללקוח שהפנייה התקבלה. ניתוב לפי נושא כשיש יותר מאדם אחד שמטפל. חיבור ליומן כשהצעד הבא הוא תמיד פגישה. כל אחת מהן שווה את עצמה רק אם היא חוסכת שלב שאתם באמת עושים היום ידנית.
מה אפשר למדוד ברגע שיש רשומות
ברגע שכל פנייה היא רשומה עם תאריך יצירה ועם סטטוס, נפתחות שאלות שקודם פשוט לא הייתה עליהן תשובה. כמה פניות הגיעו החודש לעומת החודש שעבר. כמה מהן עדיין בסטטוס חדש ברגע זה. כמה זמן עובר בממוצע בין הפנייה למענה. ואם יש שדה נושא, אילו נושאים חוזרים על עצמם מספיק פעמים כדי להצדיק דף תשובה באתר.
אף אחת מהשאלות האלה לא דורשת דוח שנבנה מראש. הן פשוט קיימות כשהנתונים יושבים במקום אחד במקום להיות פזורים בתיבת דואר. השאלה השנייה, כמה פניות תקועות בסטטוס חדש עכשיו, היא בדרך כלל זו שהכי לא נוח לענות עליה. זו בדיוק הסיבה ששווה שתהיה עליה תשובה.
מה כדאי לא לעשות
לא להשאיר קריאה של הרשומות פתוחה לכולם. לא להסתמך על ולידציה בדפדפן בלבד. לא להוסיף שדות חובה "כי אולי נצטרך", כי כל אחד מהם מוריד את אחוז ההשלמה. ולא לשלוח את ההתראה לפני שהרשומה נשמרה.
מתי זה מספיק, ומתי כבר לא
לחלק גדול מהעסקים טופס עם ישות, הרשאות נכונות והתראה טובה מספיק לאורך זמן, וזו התשובה הכנה. הוא מפסיק להספיק כשקורה אחד משלושה דברים: הפנייה צריכה להזין תהליך המשך כמו הצעת מחיר או חיוב, יותר מאדם אחד חולק את אותו תור, או שיש כללים שונים לסוגי פניות שונים. בנקודה הזו כבר לא מדובר בטופס אלא במערכת קליטה, וההחלטה מה לבנות ומה לקנות נעשית רלוונטית. כתבתי על שני הצדדים במערכת בהתאמה אישית מול פתרון מדף, וגם על מתי כדאי לעבוד עם מומחה Base44 ומתי אפשר לבד.
הטופס עצמו הוא עבודה של שעה או שתיים. מה שמחזיר את הזמן הוא מה שקורה לפנייה בדקה שאחרי.
שאלות נפוצות
האם צריך לדעת לכתוב קוד כדי לבנות טופס יצירת קשר ב-Base44?
לא כדי לקבל טופס עובד: Base44 יודעת לייצר את המסך ואת הישות ששומרת את הפניות מתוך תיאור מילולי. שני חלקים כן שווים בדיקה ידנית לפני שהטופס עולה לאוויר, וזה נכון גם למי שלא כותב קוד: ההרשאות על הישות, והוולידציה שרצה בצד השרת ולא רק בדפדפן.
מי יכול לראות את הפניות שנשלחות דרך הטופס?
זה נקבע בהרשאות של הישות, ולא בטופס עצמו. ההגדרה הנכונה לטופס יצירת קשר היא יצירה פתוחה לכל מבקר באתר, וקריאה, עדכון ומחיקה מוגבלים למנהל בלבד. אם הקריאה נשארת פתוחה, כל מי שיודע לפנות לממשק הנתונים יכול למשוך את רשימת הפניות שלכם.
מה קורה לפנייה אם שירות המיילים נופל בדיוק באותו רגע?
אם שמרתם את הרשומה לפני ששלחתם את ההתראה, הפנייה נשארת במערכת גם כשהמייל נכשל, ותראו אותה במסך הניהול. זו הסיבה שהסדר חשוב: מייל הוא התראה על אירוע, לא המקום שבו האירוע נשמר.
כמה שדות כדאי לשים בטופס יצירת קשר?
כמה שפחות שדות חובה. בטופס של האתר הזה רק שם והודעה מוגדרים כחובה ברמת הישות, והכלל שדורש טלפון או אימייל (לפחות אחד מהם) נאכף בפונקציה בצד השרת. כל שדה חובה נוסף הוא עוד נקודה שבה מבקר יכול לנטוש את הטופס באמצע.
אפשר לחבר את הטופס לוואטסאפ?
ההתראה שמגיעה אליכם יכולה לכלול קישור חיוג וקישור וואטסאפ אל מי שפנה, וזה עובד אחרי נרמול המספר לפורמט בינלאומי (מספר שמתחיל באפס מומר לקידומת 972). זה שונה משליחה אוטומטית של הודעת וואטסאפ ללקוח, שדורשת חיבור לספק שירות מאושר ונחשבת שלב נפרד.