לקוח נכנס לאתר, מתעניין בשירות, ממלא פרטים ולוחץ על „שליחה”.
על המסך מופיעה הודעה: „הפנייה נשלחה בהצלחה”.
מבחינתו, עכשיו תורכם לחזור אליו.
אבל אצלכם אין מייל, אין התראה ואין לקוח חדש במערכת.
אובדן לידים באתר יכול להתרחש גם כשהטופס נראה תקין לחלוטין.
הבעיה מתגלה לפעמים רק כשלקוח מתקשר ושואל: „השארתי פרטים לפני יומיים, למה לא חזרתם אליי?”
בשלב הזה כדאי לבדוק מעבר לעיצוב הטופס ולכתובת המייל שמוגדרת בו.
צריך להבין לאן הפנייה הגיעה, באיזה שלב נעצרה ואיך מזהים את התקלה בפעם הבאה.
מה קורה לפנייה אחרי שלוחצים על „שליחה”?
פנייה מהאתר עוברת בין כמה רכיבים.
במערכת טיפוסית המסלול נראה כך:
מילוי ושליחה ← קליטה באתר ← שמירת הפנייה ← שליחת התראה או העברה ל-CRM ← טיפול בעסק.
בחלק מהאתרים שליחת המייל וההעברה למערכת ניהול הלקוחות מתבצעות במקביל.
כל אחד מהשלבים יכול להצליח או להיכשל בנפרד.
ייתכן שהפנייה נשמרה באתר, אבל המייל לא הגיע.
ייתכן שהמייל הגיע, אבל הרשומה לא נוצרה ב-CRM.
וייתכן שהכול עבד טכנית, אך הפנייה נשארה ללא אחראי.
גם בתיעוד הרשמי של WordPress מצוין שתשובת הצלחה מפונקציית שליחת המייל אינה מבטיחה שהנמען קיבל אותו בפועל.
לכן, הודעת הצלחה לגולש היא רק נקודת בדיקה אחת במסלול.
איך מזהים אובדן לידים באתר? מתחילים בשליחה אמיתית
בדיקת טופס מתחילה במקום שבו הלקוח נמצא: באתר הציבורי.
פתחו את העמוד בחלון גלישה פרטית, כשאינכם מחוברים לניהול האתר.
מלאו את הטופס בפרטי בדיקה מזוהים, למשל „בדיקת טופס – עמוד שירות – 14:30”.
כך תוכלו למצוא את אותה פנייה באתר, במייל ובמערכת ניהול הלקוחות.
בדקו:
- האם אפשר למלא את כל השדות ולשלוח?
- האם מתקבלת הודעת הצלחה ברורה?
- האם הפנייה נשמרת במערכת?
- האם המייל מגיע לכתובת הנכונה?
- האם הטלפון, כתובת המייל ותוכן ההודעה מופיעים בשלמותם?
- האם הפנייה מגיעה לאדם שאמור לטפל בה?
חזרו על הבדיקה גם מהטלפון.
אם יש טופס בעמוד יצירת קשר, טופס בפופאפ וטופס בדף נחיתה, בדקו כל אחד מהם.
טופס אחד שעובד אינו מעיד שכל הטפסים באתר מוגדרים נכון.
גם מייל בדיקה מתוסף דיוור אינו מחליף שליחת טופס אמיתי.
הוא בודק חלק ממנגנון המייל, אך אינו בודק את הגדרות הטופס ואת הפעולות שמתבצעות אחריו.
שמירת פניות באתר: רשת ביטחון כשההתראה נכשלת
כאשר העותק היחיד של הפנייה נשלח במייל, תקלה במסירה עלולה להשאיר את העסק בלי דרך פשוטה לשחזר את פרטי הלקוח.
לכן כדאי לוודא שהפניות נשמרות גם במערכת מוגדרת.
באתרים המשתמשים בטופסי Elementor Pro, למשל, אפשר להגדיר את הפעולה Collect Submissions ולצפות בפניות מתוך ניהול WordPress.
יש לבדוק שהפעולה מוגדרת בטופס ושפניית הבדיקה אכן מופיעה ברשימה.
שמירה באתר ושליחת מייל הן שתי פעולות שצריך לאמת בנפרד.
כדאי לשמור לצד הפנייה גם את מועד השליחה ואת העמוד שממנו נשלחה.
המידע הזה עוזר לזהות אם הבעיה קשורה לטופס מסוים או התחילה לאחר שינוי באתר.
עם זאת, שמירה מקומית אינה תחליף לגיבוי.
יש להגדיר הרשאות גישה ומשך שמירה שמתאימים לצורכי העסק, ולהימנע משמירת מידע שאינו נחוץ.
הטופס נשמר, אבל המייל לא הגיע: מה בודקים?
אם הפנייה מופיעה באתר אך אינה נמצאת בתיבה, אפשר להתמקד במסלול המייל.
תחילה בדקו את הדברים הפשוטים:
- כתובת הנמען שמוגדרת בטופס.
- תיקיות ספאם, אשפה והסגר ארגוני.
- כללי סינון או העברה אוטומטית.
- תיבה מלאה או כתובת ישנה של עובד.
- כתובת השולח שמוגדרת בהודעה.
לאחר מכן בודקים את שירות השליחה ואת יומני הפעילות שלו.
חיבור מאומת באמצעות SMTP או API של ספק מייל מאפשר לשלוח דרך שירות מוגדר ולבדוק את התהליך בצורה מסודרת יותר.
אבל עצם התקנת תוסף SMTP אינה הוכחה שהבעיה נפתרה.
צריך לוודא שהחיבור פעיל, שהאימות תקין ושהשליחה מהטופס עצמו מצליחה.
בבדיקה מקצועית בוחנים גם את אימות הדומיין באמצעות SPF ו-DKIM, ואת התאמת הגדרות DMARC לשירות ששולח את ההודעות.
כתובת הלקוח יכולה לשמש ככתובת למענה, Reply-To.
כתובת השולח צריכה להתאים לשירות ולדומיין שמורשים לשלוח.
חשוב גם להבין מה אומר כל סטטוס ביומן.
„התקבל לשליחה” אינו בהכרח „נמסר לשרת הנמען”, וגם אישור מסירה אינו הוכחה שההודעה הופיעה בתיבת הדואר הנכנס או נקראה.
אחד הפתרונות המעשיים: הגדרת שליחת מיילים עם WP Mail SMTP
אחד הפתרונות לבעיות בשליחת מיילים מוורדפרס הוא התוסף WP Mail SMTP.
התוסף מחבר את האתר לשירות מייל מוגדר באמצעות SMTP או חיבור ייעודי לספק, בהתאם לאפשרות שבוחרים.
כך אפשר לשלוח את ההתראות מהטפסים דרך חשבון מאומת ולבדוק את תקינות השליחה.
איך מגדירים אותו?
- בלוח הבקרה של וורדפרס נכנסים אל תוספים ← תוסף חדש, מחפשים WP Mail SMTP, מתקינים ומפעילים.
- פותחים את אשף ההגדרה ובוחרים את שירות המייל שדרכו האתר ישלח הודעות.
- מגדירים כתובת שולח השייכת לדומיין העסק, למשל
[email protected], ואת שם העסק. - משלימים את החיבור לפי הוראות הספק. בחיבור SMTP נדרשים בדרך כלל כתובת שרת, פורט, סוג הצפנה ופרטי אימות. את הנתונים מקבלים מספק המייל.
- משלימים את אימות הדומיין, אם נדרש, ושולחים מייל בדיקה מתוך התוסף.
- לבסוף שולחים פנייה אמיתית מכל טופס באתר, ומוודאים שהיא נשמרת ומגיעה לכתובת הנכונה.
אם בוחרים לכפות את כתובת השולח דרך התוסף, יש לוודא שההגדרה מתאימה גם לשאר המיילים שהאתר שולח.
את כתובת הלקוח שממלא את הטופס מגדירים בשדה Reply-To, כדי שתוכלו להשיב אליו ישירות.
חשוב: WP Mail SMTP מטפל בשלב שליחת המייל.
הוא אינו מחליף שמירת פניות באתר, אינו מתקן חיבור כושל ל-CRM ואינו מבטיח שכל הודעה תגיע לתיבת הדואר
חיבור ל-CRM: האם נוצרה פנייה שאפשר לטפל בה?
מערכת CRM מרכזת את פרטי הלקוחות ואת תהליך הטיפול בהם.
אלא שחיבור הטופס למערכת מוסיף עוד שלב שצריך לבדוק.
תקלות אפשריות כוללות הרשאת חיבור שפגה, שדה חובה שלא הועבר, שינוי במבנה הנתונים או אוטומציה שנעצרה.
לכן, אחרי שליחת הבדיקה, היכנסו למערכת ובדקו את הרשומה עצמה.
האם מספר הטלפון מופיע בשדה הנכון?
האם תוכן ההודעה נשמר?
האם מקור הפנייה ברור?
והאם הוגדר אחראי לטיפול?
גם תשובה טכנית חיובית מהחיבור אינה תמיד מספיקה.
לפעמים היא מעידה רק שהבקשה התקבלה לעיבוד.
דוגמה נוספת היא לקוח שכבר קיים במערכת.
ייתכן שהטופס מעדכן את איש הקשר הקיים במקום ליצור רשומה חדשה.
אם אין תיעוד לפנייה החדשה או התראה לצוות, קל לפספס אותה.
הבדיקה מסתיימת כשאפשר למצוא את הפנייה ולהבין מי מטפל בה.
טבלת אבחון: באיזה שלב הפנייה נעלמה?
| מה רואים? | מה כדאי לבדוק? |
|---|---|
| הטופס לא מסיים שליחה | שדות חובה, שגיאות בדפדפן, מנגנוני אבטחה ותגובת השרת |
| מופיעה הצלחה, אך אין פנייה שמורה | הגדרת השמירה, יומני הטופס ושגיאות בעיבוד |
| הפנייה נשמרת, אך אין מייל | הגדרות ההתראה, שירות השליחה, סינון ודחיית הודעות |
| המייל מגיע, אך אין פנייה ב-CRM | הרשאות החיבור, מיפוי שדות ויומני האוטומציה |
| הפנייה קיימת ב-CRM, אך אינה מטופלת | שיוך לאחראי, התראות ונהלי מעקב |
הטבלה מציעה כיוון לבדיקה. כדי לקבוע מה השתבש, צריך להשוות את אותה פניית בדיקה לאורך המסלול.
התראה על כשל: לגלות את התקלה לפני הלקוח
בדיקה ידנית חשובה, אך אינה מספיקה כשלעצמה לאורך זמן.
בהתאם למערכות באתר, אפשר להגדיר התראות על כשל בשליחת מייל, אוטומציה שנעצרה או העברה ל-CRM שנכשלה.
רצוי שהתראה על תקלה במייל תישלח גם בערוץ נוסף, כדי שלא תהיה תלויה באותו מנגנון שנכשל.
בחיבורים מתאימים אפשר להוסיף ניסיונות העברה חוזרים.
צריך לתכנן אותם כך שלא ייצרו פניות כפולות, למשל באמצעות מזהה ייחודי לכל פנייה.
אפשר גם לבצע בדיקת טופס אוטומטית תקופתית, תוך סימון ברור של פניות הבדיקה והחרגתן מדוחות המכירות.
לצד ההתראות, כדאי להשוות בין מספר הפניות שנשמרו באתר למספר הפניות שנקלטו במערכת.
פער אינו מוכיח מיד תקלה, אך הוא מצביע על משהו שכדאי לברר.
גם דוח המרות עלול ליצור תמונה מטעה
אירוע המרה במערכת מדידה יכול להיספר בלחיצה על הכפתור, בהצגת הודעת הצלחה או במעבר לעמוד תודה.
המשמעות תלויה בהגדרה שבוצעה באתר.
לכן, עשר המרות בדוח הפרסום אינן בהכרח עשר פניות שהגיעו לעסק.
כדאי להתאים את המדידה לשלב שאפשר לאמת, ולהשוות אותה לנתוני הטפסים וה-CRM.
יש להביא בחשבון גם פניות בדיקה, ספאם וכפילויות.
להפוך את בדיקת הפניות לחלק מתחזוקת האתר
לאחר החלפת אחסון, שינוי בשירות המייל, עדכון משמעותי או עריכת טופס, כדאי לבצע שוב שליחה מקצה לקצה.
בשגרה, קבעו תדירות בדיקה בהתאם להיקף הפניות ולחשיבות שלהן לעסק.
הגדירו גם מי מקבל התראות ומי אחראי לטפל בתקלה.
אם הטופס מציג הצלחה אבל הפניות אינן מגיעות, כדאי להתחיל בבדיקה מסודרת של המסלול כולו.
אובדן לידים באתר מצמצמים כשמוודאים שכל פנייה נקלטת, נשמרת ומגיעה לאדם שיכול לחזור ללקוח.
בדיקת טפסים וקבלת פניות היא חלק חשוב משירות תחזוקת אתר וורדפרס.
לא מספיק לוודא שהאתר עולה ושהתוספים מעודכנים – צריך לבדוק שגם הפניות נשמרות ומגיעות ליעדן.
כאשר מתגלה תקלה, תיקון אתר וורדפרס צריך לכלול איתור של נקודת הכשל ובדיקה חוזרת של כל מסלול הפנייה, משליחת הטופס ועד לקבלתה בעסק.
מומחה בניית אתרים וורדפרס עם ניסיון ומוניטין של מעל 20 שנה בעולם הדיגיטל.
אני בונה ומעצב אתרים וחנויות בוורדפרס, מתמחה באחסון ותחזוקה, ומלווה עסקים משלב האפיון ועד קידום במנועי חיפוש.
המאמרים שאני כותב מבוססים על ניסיון אמיתי בעבודה עם מאות אתרים ולקוחות, כדי לתת לך ידע שימושי וטיפים פרקטיים לעסק שלך.
השארת תגובה