לקוח נכנס לאתר שלכם, קורא על השירות ומשאיר פרטים. מה קורה עכשיו?

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

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

זו השאלה שכדאי לשאול לפני פרויקט האתר הבא שלכם: עד איפה האתר אמור להשתתף בתהליך?

אתר תדמית יכול להספיק. תלוי מה מצפים ממנו

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

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

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

כל אחת מהאפשרויות האלה צריכה הצדקה. טופס ארוך מדי עלול להכביד על הפנייה. לכן צריך לבחור מה באמת נחוץ בשלב הראשון ומה נכון לברר בשיחה.

האפיון מתחיל בשאלה מה צריך לקרות אחרי השליחה

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

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

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

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

הלקוח והצוות צריכים להבין באיזה שלב נמצאים

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

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

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

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

לא כל לקוח צריך אזור אישי

קל להוסיף לרשימת הדרישות ״אזור אישי״, ״מעקב פניות״ ו״צ'אט AI״. כדאי לעצור ולשאול מי ישתמש בכל אחד מהם ובאיזו תדירות.

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

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

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

מה אפשר ללמוד מפנייה שממשיכה לתוך העסק

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

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

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

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

מי ינהל את האתר אחרי שהוא עולה

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

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

ב־Digital Pro Lab אנחנו מפתחים ומנהלים את המערכות האלה כחלק מהנכסים הדיגיטליים של העסק. האפיון כולל את הפעולה של הלקוח באתר ואת מה שהצוות צריך לעשות אחריה.

לפני שמחליטים לבנות אתר חדש

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

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