מה זה אפיון מערכת CRM, ומה מקבלים בסופו?
אפיון הוא תרגום של הדרך שבה העסק עובד להחלטות שאפשר לבנות עליהן מערכת. לא רשימת משאלות, ולא «נרצה שהמערכת תעשה הכול». השאלה בכל שלב היא אחת: מה קורה כאן בפועל, ומה צריך לקרות.
בסוף האפיון מקבלים מסמך אפיון והצעת מחיר. מסמך אפיון טוב עונה בכתב על השאלות האלה:
מקורות: מאיפה מגיעות פניות, ומה נשמר מכל מקור. שלבים: אילו שלבים עובר לקוח, ומה בדיוק מסמן מעבר משלב לשלב. אחריות: מי אחראי בכל שלב, ומה קורה כשהוא לא זמין. מידע: אילו שדות חובה בכל שלב, ואילו רק נחמד שיהיו. הרשאות: מי רואה ומי מעדכן כל סוג מידע. חיבורים: אילו ערוצים וכלים מתחברים, ומה עובר ביניהם. נתונים קיימים: מה עובר מהגיליון או מהמערכת הקודמת, ומה נשאר בארכיון. שלב ראשון: מה נבנה עכשיו, ומה מחכה.
אם אחת התשובות חסרה, היא לא נעלמת. היא פשוט תוכרע תוך כדי הבנייה, על ידי מי שבונה, ולא על ידי מי שעובד במערכת. זה הסיכון העיקרי בדילוג על אפיון: מערכת שבנויה טוב, על החלטות של מישהו אחר.
בעסק של 2 עד 10 אנשים לא צריך מסמך דרישות ארוך. צריך שכל החלטה תהיה כתובה פעם אחת, במקום שכולם יכולים לחזור אליו, לפני שמתחילים להקים.
מה ההבדל בין אפיון CRM, הקמה והטמעה?
שלושה שלבים, שלוש שאלות שונות. אפיון עונה על «מה בונים ולמה». הקמה עונה על «איך זה נראה במערכת»: לוחות, שדות, שלבים, הרשאות ואוטומציות. הטמעה עונה על «האם הצוות באמת עובד ככה ביום יום».
הבלבול נפוץ כי בפרויקט קטן אותו אדם עושה את שלושתם. אבל ההבחנה חשובה, כי כל שלב נשען על הקודם. אי אפשר להקים שלב «הצעה נשלחה» לפני שהוחלט מה חייב להיות ברשומה כדי להגיע אליו. ואי אפשר להדריך צוות על שלב שאף אחד לא מבין למה הוא שם. ובמקביל, הטמעה חושפת לפעמים החלטת אפיון שלא מחזיקה בשטח, ואז חוזרים אליה ומתקנים אותה, לא עוקפים אותה בהקמה.
סימן טוב לאפיון שהסתיים: אפשר להסביר כל שדה, כל שלב וכל הרשאה במשפט אחד, וכולם מסכימים עם המשפט. סימן לאפיון שלא הסתיים: בהקמה עולות שוב ושוב שאלות כמו «מי אמור למלא את זה?» או «מה עושים כשהלקוח לא עונה?».
המדריך הזה מתמקד באפיון עצמו: מה מחליטים ואיך. את התמונה המלאה של הפרויקט, מהאפיון דרך ההקמה ועד הדרכת הצוות, מתארים בעמוד הטמעת CRM.
מאיפה מתחילים לאפיין: מאיפה מגיעה פנייה ומי מטפל בה?
מהנקודה שבה לקוח פונה לראשונה. לא מהדוחות שרוצים לראות בסוף, ולא מרשימת השדות. אם הפנייה לא נכנסת למערכת, שום דוח לא יעזור.
בעסק קטן בישראל יש בדרך כלל כמה ערוצים במקביל: וואטסאפ למספר העסק, טופס באתר, שיחת טלפון, מודעה ברשתות, הפניה מלקוח קיים. לכל ערוץ שואלים את אותן שאלות. מה מגיע ממנו, שם וטלפון בלבד או גם נושא? איפה הפנייה נוחתת היום, ומי רואה אותה ראשון? מה צריך לקרות כדי שהיא תהפוך לרשומת לקוח ב־CRM? ומה קורה כשאותו אדם פונה פעמיים, מערוצים שונים?
השאלה האחרונה נשמעת טכנית, אבל היא החלטה עסקית. האם מזהים לקוח לפי מספר טלפון? מה עושים כשאדם שכבר סגר עסקה פונה שוב? מעדכנים את הרשומה הקיימת או פותחים חדשה? בלי כלל כתוב, כל ערוץ ייצור כפילויות אחרות.
מיד אחרי המקור באה האחריות. לכל פנייה חדשה צריך להיות אחראי ברגע שהיא נכנסת, לא כשמישהו נזכר. באפיון מחליטים לפי מה משייכים: לפי ערוץ, לפי סוג פנייה, לפי אזור, או תור משותף עם ברירת מחדל ברורה. ומחליטים מה הצעד הבא שנוצר אוטומטית: משימת חזרה, סימון «חדש», או תזכורת.
בדיקה פשוטה לסוף החלק הזה: קחו פנייה אמיתית שנכנסה לאחרונה ועקבו אחריה על הנייר. מאיפה הגיעה, מי ראה אותה, מי ענה, ואיפה המידע נמצא עכשיו. כל מקום שבו התשובה היא «תלוי» הוא החלטה שהאפיון צריך לסגור.
אילו החלטות רק בעל העסק יכול לקבל באפיון?
חלק גדול מהאפיון הוא שאלות שמי שבונה את המערכת לא יכול לענות עליהן, גם אם הוא מכיר את הכלי היטב. הוא יכול להציע, להראות מה המשמעות של כל אפשרות, ולהזהיר ממבנה שלא יחזיק. את ההכרעה נותן העסק.
אלה ההחלטות שחוזרות כמעט בכל אפיון: מה נכנס למערכת ומה נשאר בחוץ. מה מסמן מעבר בין שלבים. מי אחראי על כל שלב. איזה מידע חובה לפני שמתקדמים. מי רואה מה. אילו שאלות ניהול המערכת צריכה לענות עליהן. ומי בעסק אחראי על המערכת אחרי המסירה.
פירטנו את ההחלטות האלה בטבלה, עם השאלה שצריך לענות עליה, מי בעסק עונה בדרך כלל ומה קורה כשההחלטה נשארת פתוחה: ההחלטות שנשארות אצל העסק לפני ההקמה.
מה שכדאי להוסיף כאן הוא איך מקבלים אותן מהר. שתי טעויות חוזרות. הראשונה: לנסות להכריע הכול בבת אחת, כולל מקרים שקורים פעם בשנה. עדיף להכריע את המקרה הנפוץ, ולכתוב במפורש שהחריג מטופל ידנית. השנייה: להכריע בלי מי שעושה את העבודה. בעל העסק קובע את הכלל, אבל מי שעונה לפניות יודע איפה הכלל ייתקל במציאות.
טריק מעשי: לכל החלטה, נסחו משפט אחד שמתחיל ב«אצלנו». «אצלנו עסקה נפתחת רק אחרי שיחה ראשונה». «אצלנו מי שענה ראשון הוא האחראי, עד שמישהו מעביר». אם אי אפשר לנסח את המשפט, ההחלטה עוד לא התקבלה.
איך אפיון CRM הופך למבנה ב־monday?
ניוטון מערכות (New Tone) בונה מערכות CRM על monday, ולכן כדאי שהאפיון יסתיים כבר בשפה של המבנה שייבנה. זה לא אומר שמתחילים מהכלי. מתחילים מהתהליך, ורק אז שואלים איך הוא יושב על אבני הבניין של monday.
התרגום נשאר בשפה פשוטה. מה שמנוהל כיחידה, למשל פנייה, עסקה, פרויקט או לקוח, מקבל לוח משלו. השלבים שהוגדרו באפיון הופכים לשלבים בלוח, ותנאי המעבר ביניהם נכתבים כחוקים: מה חייב להיות מלא לפני שמתקדמים. לכל רשומה יש אחראי. הקשר בין לקוח לעסקאות שלו נשמר כקישור בין הלוחות. ההרשאות נקבעות לפי מי צריך לראות ולעדכן כל לוח. ומה שחוזר על עצמו בלי שיקול דעת הופך לאוטומציה.
ההחלטה החשובה ביותר בשלב הזה היא מה היחידה שזזה. בעסק אחד זו הפנייה, באחר העסקה, ובשלישי משהו שאף אחד לא חשב עליו. בדוגמה האנונימית של CRM ליועצי פנסיה, מה שזז הוא הקופה ולא הלקוח. המבנה הראשון שם את הקופות בתוך רשומת הלקוח, ובבדיקה לפני הבנייה עלו מגבלות של monday שהובילו ללוח קופות נפרד שמקושר ללקוח. החלטה כזו קל לשנות באפיון, וקשה לשנות אחרי שהצוות כבר עובד.
עוד שני דברים שכדאי לבדוק כבר באפיון ולא אחרי ההקמה. הראשון: חלק מאפשרויות ההרשאה ב־monday תלויות בתוכנית המנוי, ולכן מי רואה מה נבדק מול התוכנית בפועל. השני: לא כל דרישה צריכה לוח. לפעמים שדה אחד בלוח קיים פותר את מה שנראה כמו תהליך נפרד.
מה שיוצא מהשלב הזה הוא מפה: אילו לוחות יהיו, מה כל אחד מנהל, אילו שלבים יש בו ומי אחראי עליו. עם מפה כזו, ההקמה היא ביצוע ולא ניחוש.
איפה וואטסאפ, חוזים ואוטומציות נכנסים לאפיון?
בתוך התהליך, לא אחריו. הטעות הנפוצה היא לאפיין CRM «נקי» ואז לחפש איך לחבר אליו את וואטסאפ. אבל אם רוב הפניות מגיעות בוואטסאפ, הערוץ הזה הוא חלק מהשלב הראשון של התהליך, והאפיון צריך להתחיל ממנו.
לניוטון מערכות (New Tone) יש כלי וואטסאפ משלה, שנבנה לעבודה של עסקים וסוכני AI. הכלי לא מחליף את ההחלטות: הן נכתבות באפיון, לפני החיבור.
בוואטסאפ מחליטים: אילו שיחות הופכות לרשומה ואילו לא, למשל ספק או לקוח קיים ששואל שאלה. מה עובר מהשיחה לרשומה: טלפון, שם, נושא, תקציר. מי מקבל פנייה חדשה, ומה קורה כשאף אחד לא ענה. רשימת בדיקה מפורטת לשדות, לשיוך ולכפילויות נמצאת בצ׳קליסט לחיבור וואטסאפ ל־CRM.
בהצעות ובחוזים מחליטים: באיזה שלב יוצאת ללקוח הצעה או חוזה, מי אחראי עליהם, ומה משתנה ברשומה כשהלקוח מאשר. לרוב זה גם הרגע שבו העבודה עוברת לביצוע, ולכן כדאי להגדיר בדיוק מה עובר הלאה: פרטי השירות שסוכם, אחראי לביצוע ומשימה ראשונה.
באוטומציות מחליטים רק על פעולות עם כלל ברור. «כשפנייה עוברת לשלב X, פתח משימה ל־Y» הוא כלל. «כשהלקוח נשמע מעוניין, תעדכן» הוא לא כלל, ולא כדאי לבנות עליו אוטומציה. לכל אוטומציה כותבים מה מפעיל אותה, מה היא עושה, ומי יודע אם היא נכשלה.
כלל אצבע לחלק הזה: כל חיבור וכל אוטומציה צריכים לשרת החלטה שכבר כתובה בשלבים הקודמים. אם אוטומציה לא קשורה לשום שלב או אחראי, כנראה שהיא לא שייכת לשלב הראשון.
מה אפשר להשאיר מחוץ לשלב הראשון?
יותר ממה שנדמה. המטרה של השלב הראשון היא שהצוות יעבוד במערכת על התהליך המרכזי, לא שהמערכת תכסה כל מקרה. אפיון טוב אומר במפורש גם מה לא נבנה עכשיו, כדי שזה לא ייכנס בדלת האחורית.
דברים שבדרך כלל יכולים לחכות: דוחות ותצוגות מעבר לשאלות הניהול המרכזיות. כדאי לראות קודם איזה מידע באמת נאסף. אוטומציות למקרים נדירים, שמי שנתקל בהם יכול לטפל בהם ידנית. העברה של ארכיון ישן שאף אחד לא פותח, כשמספיק להעביר לקוחות ועסקאות פעילים. חיבורים לכלים שמשתמשים בהם מדי פעם. וסוכן AI, שמגיע אחרי שהתהליך הבסיסי עובד ויש לו על מה לעבוד.
מה לא כדאי לדחות: את מקורות הפניות המרכזיים, את השלבים ותנאי המעבר, את האחריות, את שדות החובה ואת ההרשאות. אם אחד מאלה נדחה, הצוות יתחיל לעבוד סביב המערכת, ויהיה קשה להחזיר אותו.
דרך פשוטה להחליט: לכל רעיון שעולה באפיון שואלים אם הצוות יכול להתחיל לעבוד בלעדיו. אם כן, הוא נכנס לרשימה של «אחר כך», עם משפט שמסביר למה. הרשימה הזו היא חלק מתוצר האפיון, לא פסולת שלו.
איך בודקים אחרי ההקמה שהאפיון עובד בשטח?
חוזרים להחלטות הכתובות ובודקים אותן מול מה שקורה במערכת. האפיון הוא לא רק תוכנית לבנייה. הוא גם רשימת הבדיקה של מה שאמור לקרות אחרי שהצוות מתחיל לעבוד.
הבדיקה עובדת הפוך מהאפיון: במקום לשאול מה צריך לקרות, שואלים מה קרה. בוחרים כמה רשומות אמיתיות מכל ערוץ ובודקים עליהן. הפנייה נכנסה מהמקור שהוגדר? היה לה אחראי מהרגע הראשון? היא עברה שלבים לפי תנאי המעבר, או שמישהו דילג? שדות החובה מלאים, או שמולאו במשהו כללי רק כדי לעבור הלאה?
כל פער כזה שייך לאחד משני סוגים. או שההחלטה באפיון לא הייתה נכונה, למשל שדה חובה שאף אחד לא יודע בשלב הזה, ואז משנים את ההחלטה. או שההחלטה נכונה והצוות לא עובד לפיה, ואז הפתרון הוא הדרכה או בירור אחריות, לא עוד שדה או עוד אוטומציה.
ומכאן הכלל החשוב בשלב הזה: כל שינוי שעולה מהבדיקה נכתב בחזרה לאפיון, כדי שהגרסה הכתובה תמיד תתאר את המערכת שבאמת עובדת. כשמצטרף עובד חדש, או כשרוצים להוסיף שלב או ערוץ, זה המסמך שממנו מתחילים, ולא הזיכרון של מי שהיה שם בהתחלה.