CRM ותיקון 13 לחוק הגנת הפרטיות: מה נדרש מכם?

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

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

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

מה תיקון 13 לחוק הגנת הפרטיות באמת משנה בשטח?

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

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

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

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

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

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

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

איך מיישמים את דרישות תיקון 13 בתוך מערכת ה-CRM?

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

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

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

יידוע והסכמה בתיקון 13: מה משתנה בטפסים ובערוצי הפנייה?

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

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

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

פרטיות ותיקון 13: מתי ארגון לא צריך פרויקט שלם?

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

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

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