איך לתכנן הרשאות ב-CRM בלי לחסום עבודה ובלי לחשוף מידע מיותר

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

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

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

מתחילים מתפקידים, לא ממשתמשים

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

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

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

לא כל מידע הוא אותו מידע

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

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

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

הרשאת צפייה והרשאת עריכה הן לא אותו דבר

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

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

צריך בעלים להרשאות, לא רק מנהל מערכת

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

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

בודקים הרשאות לפי תרחישי עבודה

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

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

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