פורטל לקוחות: מה הלקוח שלכם רואה, ומי מחליט מה מותר לו
במאמר הזה
בעסק שלכם יש כנראה קבוצת וואטסאפ אחת לפחות שרוב מה שעובר בה זו אותה שאלה, שוב ושוב: "איפה זה עומד?" מישהו בצוות עונה, מעתיק את התשובה למייל או ליומן, ולפעמים שוכח לעדכן את מי ששאל בדיוק את אותו הדבר אתמול.
התשובה שהוא נותן נכונה. הדרך שהוא עבר כדי להגיע אליה היא זמן שאף אחד בעסק לא תכנן להקדיש לזה.
זו הנקודה שבה עסקים מתחילים לחשוב על פורטל לקוחות. וזו גם הנקודה שבה רובם מתחילים מהשאלה הלא נכונה.
מה זה פורטל לקוחות, ומה הוא לא
ההגדרה המקובלת פשוטה. פורטל לקוחות הוא נקודת כניסה מאובטחת שדרכה לקוח של הארגון נכנס לאזור אישי ורואה מידע שנוגע אליו בלבד. לפעמים גם מוריד מסמכים, ולפעמים גם מעלה.
המונח קיים כבר שנים, והוא מוכר בעיקר מעולמות שבהם חילופי מידע רגיש חייבים לעבור בערוץ מאובטח ולא במייל. בעשור האחרון הוא ירד לעסקים קטנים ובינוניים, ושם הוא פגש מציאות שונה לגמרי: ארגון בלי מחלקת IT, עם מידע שמפוזר בין כלים, שרוצה בכל זאת לתת ללקוח חלון פנימה.
עד כאן כולם מסכימים.
אנחנו מוסיפים להגדרה הזו תנאי אחד: הפורטל חייב לשקף את המערכת שבה העסק באמת עובד, בלי התנאי הזה נשארים עם מסך יפה שמישהו צריך לעדכן באופן ידני.
הבעיה מתחילה בהגדרה שהשוק דוחף. רוב הספקים בישראל מגדירים פורטל לקוחות ככלי שירות עצמי, ומצרפים לתיאור רשימת פונקציות אחידה שנראית זהה אצל כולם.
הרשימה הזו מבלבלת יותר משהיא עוזרת, היא מתארת מה אפשר לשים בפורטל, ולא מה הפורטל אמור להיות.
זו לא ההגדרה שאנחנו עובדים לפיה, פורטל אמיתי אינו ערוץ תמיכה. הוא שיקוף של המערכת התפעולית של העסק, בגרסה שהלקוח רשאי לראות אותם נתונים, אותה אמת אחת, עם שכבת הרשאות מעליה.
ההבדל אינו סמנטי, הוא קובע מאיפה הפורטל שואב: כלי שירות עצמי שואב מבסיס נתונים משלו ומסתנכרן מדי פעם, שיקוף שואב מהמערכת עצמה, בזמן אמת, כי אין לו בסיס נתונים אחר.
וזו הנקודה שבה מתגלה מי יכול לבנות פורטל ומי לא. עסק שהמידע שלו מפוזר בעשרה כלים לא יכול לשקף אמת אחת, כי אין לו אחת הוא יכול רק להוסיף מסך שמושך ממקום אחד ומשאיר את התשעה האחרים מאחור.
יש עוד הבדל שנובע מכך, והוא נוגע לאמון. כשהפורטל שואב מהמערכת, מה שהלקוח רואה זהה למה שהצוות שלכם רואה. כשהוא שואב מעותק, נוצר פער, והפער הזה מתגלה תמיד ברגע הכי גרוע: לקוח מתקשר ואומר שבפורטל כתוב משהו אחר ממה שאמרתם לו.
אנחנו לא בונים פורטל כמוצר נפרד. הוא נגזרת של המערכת, ולכן אין בו מצב שבו שתי גרסאות של האמת חיות זו לצד זו.
מה הלקוח שלכם באמת רוצה לראות שם
בשיחות אפיון אנחנו שומעים בדרך כלל רשימת פיצ'רים, אפשר להתחיל אחרת, מהשאלה איזו שיחת טלפון אתם רוצים שלא תתרחש.
התשובות חוזרות על עצמן, והן קצרות:
- מתי התור, הפגישה, מועד האספקה, שלב בתהליך, הלקוח רוצה לדעת איפה הוא עומד על ציר הזמן ובדרך כלל זו השאלה שחוזרת הכי הרבה.
- מה יש ללקוח: מסמכים, סיכומים, אישורים, חוזים, דברים שקיבל או שאמור לקבל.
- תשלומים: מה שולם, מה נותר, מה צפוי, בלי להתקשר ובלי לחפש במייל.
- הצעד הבא: מה נדרש ממנו עכשיו ומה נדרש מכם, זו הקטגוריה שהכי מורידה שיחות, והכי פחות מיושמת.
שימו לב מה לא נמצא ברשימה. הלקוח לא מבקש דשבורד, הוא לא מבקש גרפים, הוא לא מבקש להתכתב.
הוא מבקש לדעת דבר אחד ולסגור את המסך.
זו נקודה שחשוב להפנים לפני האפיון, פורטל נמדד בכמה מהר הלקוח מקבל את התשובה שבשבילה נכנס ולא בכמה יכולות נדחסו לתוכו. מסך עמוס מייצר בדיוק את השיחה שרציתם למנוע של "לא מצאתי איפה".
זו הסיבה שאנחנו מתחילים בבניית פורטל לקוחות ממיפוי השיחות הנכנסות ולא ממיפוי הפיצ'רים.
השיחות מספרות לכם בדיוק מה חסר, בלי שתצטרכו לנחש.
ויש כאן גם מבחן פשוט, אם המידע שהלקוח מבקש לא קיים במערכת בצורה מסודרת, פורטל לא יפתור את זה. הוא רק יחשוף את הפער החוצה.
לדוגמה אם סטטוס ההזמנה נשמר היום בראש של מנהלת התפעול ומתעדכן בטלפון, אין מה להציג. הפורטל לא ימציא סטטוס. קודם צריך שהסטטוס יהיה שדה במערכת שמתעדכן מהתהליך, ורק אז אפשר לשקף אותו החוצה.
הסדר לבניית פורטול קודם התהליך, אחר כך השדה, ורק בסוף המסך.
שלושה ורטיקלים, שלושה פורטלים שונים לגמרי
הרשימה הקודמת נראית אוניברסלית, בפועל, אותן ארבע קטגוריות מקבלות משמעות אחרת בכל ענף.
אנחנו מפרטים כאן שלושה מבנים שונים של יחסי לקוח: אדם יחיד, לקוח בתיק, וצדדים מרובים בעסקה.
עסקים אחרים ימצאו את עצמם באחד מהשלושה.
קליניקה
הלקוח הוא מטופל, והמידע רגיש, מה שמופיע: תורים קרובים והיסטוריית ביקורים, טפסים למילוי מראש, מסמכי סיכום, ומצב תשלומים.
האתגר הוא מי בדיוק רשאי לראות, מטופל קטין, בן זוג שמתלווה, מטפל מחליף, כל אחד מהם דורש הכרעה נפרדת, ואי אפשר לדחות אותה לשלב העיצוב.
יש גם שאלה של עומק סיכום טיפול שנכתב עבור המטפל אינו בהכרח מסמך שנועד לעיני המטופל, וגם כשהוא כן, לא תמיד באותה גרסה. מערכת שלא מבחינה בין השניים תחשוף החוצה טקסט שנכתב פנימה.
מערכת מותאמת לקליניקות מתחילה מהמפה הזו ולא מהמסך.
ב-<a href="https://alcyone14.com">alcyone14</a> אנחנו רואים את התבנית הזו חוזרת: ככל שהמידע רגיש יותר, כך גדל הפער בין מה שקיים במערכת לבין מה שמותר להציג. זו לא בעיה טכנית אלא הכרעה עסקית שצריך לקבל שדה אחר שדה.
משרד עורכי דין
הלקוח רוצה לדעת מה קורה בתיק שלו, וזה בדיוק המידע שהכי קשה לחשוף.
מה שמופיע: שלב בתיק, מסמכים שהועברו, מועדים קרובים, וחשבוניות.
האתגר הוא: הגבול בין מה שמותר להראות לבין מה שחסוי או טרם גובש, טיוטה אינה מסמך, הערה פנימית אינה עדכון ללקוח. מערכת שמציגה כל קובץ שנשמר בתיק תחשוף חומר שלא נועד לצאת.
בנוסף, לקוח בתיק אחד לא אמור לראות דבר מתיק אחר, גם כשמדובר באותו לקוח ובאותו משרד.
מערכת מותאמת לעורכי דין מטפלת בהפרדה הזו ברמת הנתונים, לא בהסתרת מסך.
נדל"ן בוטיק
כאן הלקוח הוא רוכש או שוכר, והתהליך ארוך.
מה שמופיע: מסמכי עסקה, לוח זמנים, מצב תשלומים ואבני דרך.
האתגר הוא: בעסקה יש יותר מצד אחד, רוכש, מוכר, עורך דין, לעיתים גם בנק. פורטל שלא הכריע מראש מי רואה מה עלול לחשוף מידע מסחרי לצד הלא נכון.
ויש גם ממד הזמן עסקה נמשכת חודשים, ובמהלכם משתנים הצדדים, המסמכים והמועדים. פורטל שנבנה כתמונת מצב אחת מתיישן תוך שבועות. הוא צריך לשקף מצב שמשתנה, ולכן הוא חייב לשבת על המערכת שבה המצב הזה מנוהל.
שלושה ענפים, אותן ארבע קטגוריות, ושלושה מודלי הרשאות שאין ביניהם דבר משותף זו הסיבה שאין תבנית.
מי שקונה מודול מוכן מקבל את מודל ההרשאות שהמודול תומך בו, ומתאים אליו את העסק.
אצלנו הכיוון הפוך: מודל ההרשאות נגזר מהתהליך, והמסך נבנה אחריו.
הרשאות: השאלה שקובעת אם פורטל אפשרי בכלל
כל דוגמה בסקשן הקודם נעצרה באותה נקודה מי רשאי לראות מה, שאלה ארכיטקטונית, והיא מכריעה אם אפשר לבנות פורטל בכלל.
הרשאות לפי תפקיד הן המנגנון שעונה עליה. במערכת מותאמת, ההרשאה נבנית סביב תפקיד ולא סביב אדם, והיא נאכפת ברמת שאילתת הנתונים ולא בהסתרת רכיבים במסך.
ההבחנה הזו קריטית כפליים בפורטל, וזו הסיבה שאנחנו לא מתחילים לעצב מסכים לפני שמודל ההרשאות סגור.
בממשק פנימי, הסתרת כפתור מונעת טעות של עובד, בפורטל, הצד השני של המסך אינו עובד שלכם.
הוא לקוח, ולפעמים לקוח שמתעניין אכיפה ברמת הממשק אינה מספיקה כשהמשתמש אינו בשליטתכם.
יש כאן גם שאלה שרוב העסקים מגלים מאוחר: מתי המידע מפסיק להיות שלו.
מטופל שסיים טיפול. לקוח שהתיק שלו נסגר. רוכש שהעסקה הושלמה. הגישה שלהם לפורטל נשארת פתוחה לנצח, או שהיא נסגרת? ומה עם המסמכים שכבר הורידו?
אין תשובה נכונה אחת, יש תשובה שצריך להחליט עליה מראש, כי בדיעבד היא הופכת לפרויקט.
שאלה נוספת מאותה משפחה: מי בכלל פותח ללקוח גישה, ואיך. אם פתיחת גישה היא פעולה ידנית שמישהו בצוות זוכר לעשות, חלק מהלקוחות לא יקבלו גישה לעולם, וחלק יקבלו גישה שהיו צריכים לאבד. גישה שנפתחת ונסגרת מתוך התהליך העסקי עצמה פותרת את שתי הבעיות.
אנחנו נקבע יחד עם מודל ההרשאות, כי זו אותה החלטה בשני כיוונים, כל ההכרעות האלה נלקחות בשלב האפיון, לפני שנכתבת שורת קוד ראשונה.
למה פורטל לקוחות אינו מוצר נפרד
השוק מוכר פורטל כמודול. מוסיפים אותו ל-CRM קיים, מגדירים, ומשלמים בנפרד.
זה עובד כשה-CRM הוא באמת המקום היחיד שבו המידע יושב. ברוב העסקים הוא לא, וזה הפער שאנחנו פוגשים כמעט בכל שלב מיפוי.
תחשבו מה קורה כשהתורים ביומן אחד, המסמכים בדרייב, התשלומים בתוכנת החשבונאות והתקשורת בוואטסאפ. פורטל שמתחבר ל-CRM בלבד יציג ללקוח רבע מהתמונה, ובדיוק הרבע הפחות מעניין.
הפתרון אינו לחבר את הפורטל לארבעה מקורות. כל חיבור כזה הוא נקודת כשל נוספת, ואי סנכרון בפורטל הוא לא באג פנימי הוא לקוח שרואה מידע שגוי.
ההבדל בין השניים גדול ממה שנדמה, באג פנימי מתגלה על ידי עובד שיודע לזהות שמשהו לא הגיוני. באג בפורטל מתגלה על ידי לקוח שמניח שמה שכתוב נכון, ופועל לפיו. תשלום שמוצג כלא שולם, מועד שהשתנה ולא התעדכן, מסמך שנעלם. כל אחד מהם מייצר שיחה גרועה יותר מהשיחה שהפורטל היה אמור למנוע.
מערכת CRM מותאמת אישית פותרת את זה מהכיוון ההפוך: כשהתורים, המסמכים והתשלומים יושבים באותה מערכת, הפורטל אינו אינטגרציה. הוא תצוגה.
זו גם הסיבה שבניית פורטל לקוחות אצלנו אינה שלב עצמאי בתמחור. היא נכנסת לריטיינר כמו כל שלב אחר, בלי הצעת מחיר נפרדת ובלי מו"מ מחדש.
אנחנו לוקחים מספר מוגבל של לקוחות במקביל, ולכן מהנדס אחד מכיר את המערכת ואת הפורטל שמעליה.
לא שני צוותים ולא שתי מערכות. וזו גם הסיבה שהפורטל לא נגמר ביום ההשקה: אותו מהנדס ממשיך לענות כשמשהו לא ברור, בלי שכבת תמיכה שצריך לחנך מחדש בכל פעם.
ההשלכה המעשית מורגשת בהמשך הדרך כשתרצו להוסיף שדה לפורטל, או להציג שלב חדש בתהליך, זה שינוי במערכת אחת ולא תיאום בין ספק הפורטל לספק ה-CRM, שינויים כאלה מתגלגלים לתוך הריטיינר כמו כל שלב אחר.
מה צריך לדעת לפני שבונים
לפני האפיון, שווה לענות על חמש שאלות כולן עסקיות, אף אחת אינה טכנית.
אילו שיחות אתם רוצים למנוע? לא "מה יהיה בפורטל", אלא איזו שאלה חוזרת אליכם שוב ושוב.
מי הלקוח מבחינת המערכת? אדם אחד, או משק בית, או חברה עם כמה אנשי קשר. התשובה משנה את כל מודל ההרשאות.
מה קורה בסוף? מתי הגישה נסגרת, ומה נשאר נגיש ללקוח אחרי שהקשר הסתיים.
איפה המידע יושב היום? אם התשובה כוללת יותר משתי מערכות, הפורטל אינו הפרויקט הראשון. איחוד המידע הוא זו לא דחייה של הפורטל אלא הקדמה של מה שיאפשר לו לעבוד.
מי מעדכן? אם מישהו צריך לזכור להעלות מסמך לפורטל, הפורטל ייכשל תוך חודשיים. מה שמופיע שם חייב להגיע מהתהליך עצמו.
השאלה החמישית היא זו שמפילה את רוב הפרויקטים. אנחנו בודקים אותה כבר בשלב שבו ממפים תהליכים ועושים אינוונטר לכלים הקיימים, ובחלק מהמקרים המסקנה היא שהפורטל אינו הצעד הבא אלא הצעד שאחריו.
שווה גם לעצור על נקודה שנשמעת שולית ואינה, פורטל משנה את אופן העבודה של הצוות, לא רק של הלקוח. ברגע שמידע מסוים גלוי החוצה, מי שמזין אותו יודע שהוא נקרא. זה משפר דיוק, וזה גם דורש הסבר פנימי לפני ההשקה.
שאלות נפוצות
מה ההבדל בין פורטל לקוחות לבין אזור אישי ללקוחות?
בפועל אלה שני שמות לאותו דבר. "אזור אישי" הוא לרוב התווית שהלקוח רואה במסך, ו"פורטל לקוחות" הוא המונח שבו משתמשים כשמדברים על המערכת. מה שמשנה אינו השם אלא מאיפה המידע מגיע ומי הכריע מה מוצג.
מי בעצם צריך פורטל לקוחות?
לא כל עסק, פורטל משתלם כשיש נפח שאלות חוזרות, כשהתהליך נמשך לאורך זמן, וכשללקוח יש עניין לעקוב אחריו. עסק שבו כל אינטראקציה מתחילה ונגמרת באותו יום כנראה לא ירוויח ממנו. עסק שבו הלקוח נמצא בתהליך שנמשך שבועות או חודשים כמעט תמיד כן.
כמה זמן לוקח לבנות פורטל לקוחות?
זה תלוי בעיקר בשאלה אחת: האם המידע כבר מרוכז במקום אחד. כשהוא מרוכז, הפורטל הוא שכבת תצוגה מעל מה שקיים. כשהוא מפוזר, השלב הראשון אינו הפורטל אלא איחוד המידע. ב-<a href="https://alcyone14.com">alcyone14</a> הסקופ מוגדר לכל שלב בנפרד, והשלבים מתגלגלים לתוך אותו ריטיינר.
אפשר לחבר פורטל למערכות שכבר יש לנו?
טכנית כן, השאלה היא כמה מהן. חיבור למערכת אחת סביר. חיבור לארבע יוצר ארבע נקודות כשל, וכל אחת מהן עלולה להציג ללקוח מידע לא מעודכן. זה הבדל מהותי מבאג פנימי, כי כאן הטעות נראית כלפי חוץ.
איך מוודאים שלקוח לא רואה מידע של לקוח אחר?
באמצעות אכיפה ברמת הנתונים ולא ברמת הממשק. כל שאילתה מסננת לפי זהות המבקש, כך שמידע שאינו שייך לו פשוט לא מוחזר. הסתרה במסך מספיקה מול עובד, לא מול משתמש חיצוני.
מה נדרש כדי שהפורטל יהיה מאובטח?
אותם עקרונות שחלים על המערכת כולה: הרשאות שנאכפות ברמת הנתונים, הצפנה של המידע בתעבורה ובאחסון, ותיעוד של מי ניגש למה. פורטל אינו שכבה נפרדת מבחינת אבטחה. הוא פשוט המקום שבו הגישה נפתחת גם למי שאינו עובד שלכם, ולכן ההחלטות שנלקחו בארכיטקטורה מתגלות שם במלוא עוצמתן.
מה עם מידע רגיש שאסור להציג?
זו הכרעה שנעשית באפיון, שדה אחר שדה. בקליניקה, במשרד עורכי דין ובעסקת נדל"ן יש תמיד מידע שקיים במערכת ולא אמור להופיע בפורטל. המערכת צריכה לדעת להבחין בין השניים מראש, ולא לסמוך על מי שמעלה את המסמך.
אפשר להתחיל בקטן ולהרחיב?
זו הדרך המומלצת. פורטל שמציג קטגוריה אחת ועושה אותה טוב עדיף על פורטל שמציג ארבע ואף אחת מהן אינה מדויקת. ב-<a href="https://alcyone14.com">alcyone14</a> הרחבה אינה דורשת הצעת מחיר חדשה, ולכן אין תמריץ לדחוס הכל לשלב הראשון.
הלקוחות שלנו לא טכנולוגיים. הם ישתמשו בזה?
זה תלוי פחות בהם ויותר במה שהפורטל מציג. מסך שעונה על שאלה אחת שהלקוח באמת שואל נכנס לשימוש. מסך עם שתים עשרה אפשרויות נוטה להישאר ריק. בבניית פורטל לקוחות אנחנו מתחילים מהמעט ומרחיבים לפי שימוש בפועל.
מה קורה כשלקוח מסיים את הקשר איתנו?
זו אחת השאלות שהכי כדאי להכריע מראש. אפשר לסגור גישה מיד, אפשר להשאיר חלון זמן, ואפשר להשאיר נגישות למסמכים בלבד. כל אפשרות לגיטימית. מה שלא לגיטימי הוא לא להחליט, ואז לגלות שהגישה נשארה פתוחה שנתיים.
מה קורה אם הלקוח רואה משהו שגוי בפורטל?
זה תלוי מאיפה הפורטל שואב. כשהוא מציג את המערכת עצמה, טעות בפורטל היא טעות בנתון, ומתקנים אותה במקום אחד. כשהוא מציג עותק מסונכרן, ייתכן שהנתון תקין והתצוגה מיושנת, וזה סוג תקלה שקשה להסביר ללקוח. זו אחת הסיבות ש-<a href="https://alcyone14.com">alcyone14</a> מעדיפה תצוגה על פני סנכרון.
אתם בונים גם אפליקציה, או רק מסך בדפדפן?
שניהם אפשריים כחלק מאותה מערכת מאוחדת, כולל אפליקציה ל-iOS ולאנדרואיד. ההחלטה נגזרת מהשימוש ולא מהאופנה. לקוח שנכנס פעם בחודש לא יוריד אפליקציה, ולקוח שנכנס פעמיים בשבוע כן.
