מדיניות פרטיות
מידע על איסוף, שימוש, שמירה ושליטה בפרטים שנשלחים ל-StackLab.
מידע על איסוף, שימוש, שמירה ושליטה בפרטים שנשלחים ל-StackLab.
מידע על איסוף, שימוש, שמירה ושליטה בפרטים שנשלחים ל-StackLab.
מדיניות פרטיות צריך לשקף את הדרך שבה האתר והשירותים פועלים בפועל. StackLab מציג את העקרונות, נקודות הבקרה והפרטים שצריך להשלים לפני פרסום סופי.
עמוד זה מסביר את העקרונות של מדיניות פרטיות באתר StackLab ובשירותים הקשורים אליו. הוא נועד להיות בסיס ברור למבקרים, אך לפני פרסום סופי יש להשלים את פרטי הישות המשפטית, כתובת הקשר, ספקי התשתית, תקופות השמירה והנוסח שאושר לעסק.
הטקסט צריך להתאים בפועל לאופן שבו האתר אוסף מידע, מפעיל טפסים, שולח בקשות דמו, משתמש בכלי אנליטיקס ומטפל בשיחות או הודעות. אין לפרסם הבטחה שאינה תואמת את המערכות הפעילות.
מבקר עשוי לשלוח שם, שם עסק, טלפון, אימייל, תחום פעילות, מספר שיחות, CRM נוכחי, זמן מועדף והודעה. בנוסף, מערכות טכניות עשויות לקבל כתובת IP, סוג דפדפן, מקור הגעה, עמוד מקור ונתוני שימוש בסיסיים, בהתאם לכלים שיופעלו בפועל.
טפסים של שיחת דמו או בקשת קשר צריכים להציג למבקר מה נדרש, למה המידע משמש, איך אפשר ליצור קשר ומה קורה לאחר השליחה. כדאי להפריד בין מידע שנדרש למענה לבין נתוני מדידה שאפשר לאסוף רק בהסכמה מתאימה.
המטרה יכולה להיות חזרה לפונה, תיאום דמו, התאמת תרחיש עסקי, טיפול בבקשה, מדידת מקור פנייה ושיפור חוויית האתר. אם המידע נשלח לספקים טכניים, צריך למפות מי הם, איזה מידע עובר אליהם ולצורך מה.
אין להשתמש במידע למטרה חדשה שאינה תואמת את הציפייה של המבקר בלי לבדוק את הנוסח, ההסכמה והדרישות הרלוונטיות. כאשר נדרש אדם לטיפול, יש להעביר רק את ההקשר הנחוץ ולשמור על הרשאות מתאימות.
כאשר תהליך כולל שיחת דמו, סוכן קולי, תמלול או סיכום, צריך לתאם ציפיות באופן ברור לפני איסוף המידע. יש להגדיר האם השיחה מוקלטת, האם נשמר תמלול, מי יכול לצפות בו, כמה זמן הוא נשמר ואיך אפשר לבקש בירור או מחיקה לפי התהליך שאושר.
סוכן קולי צריך לדעת גם מתי להעביר לאדם ולא למסור מידע רגיש או לא מאושר. הניסוח באתר ובשיחה צריך להיות עקבי, והצוות צריך לדעת איך לטפל בבקשה להסרה, שינוי או הפסקת קשר.
האתר והמערכות צריכים להשתמש בהרשאות לפי תפקיד, סודות שאינם חשופים בקוד, חיבורים מאובטחים, לוגים מבוקרים ותהליך לביטול גישה. בפרויקט אוטומציה מגדירים גם מי אחראי על כל חיבור ומה קורה כאשר עובד עוזב או כאשר מערכת חיצונית משתנה.
המידע בעמוד אינו צריך לטעון להסמכה, אירוח מקומי או תקן שלא נבדקו. במקום זאת, מציגים בצורה מדויקת אילו אמצעים קיימים ומה עדיין דורש בדיקה, תצורה או אישור בפרויקט הספציפי.
מבקר צריך לדעת לאיזה ערוץ לפנות אם הוא רוצה לעיין במידע, לתקן אותו, לבקש הסרה, להפסיק פנייה או לשאול כיצד נעשה שימוש בפרטים. צריך להגדיר מי מקבל את הבקשה, איך מאמתים את הפונה ומה זמן הטיפול הפנימי.
באתר יש להציג כתובת קשר פעילה ולא להשאיר פרטי placeholder. לאחר ההשקה כדאי לבדוק את הטפסים, הודעות האישור, הלוגים ותהליך הטיפול כדי לוודא שהמידע שמובטח בעמוד אכן ניתן לביצוע.
אם משתמשים ב-Google Analytics, Search Console, מערכת CRM, מערכת דיוור, WhatsApp, יומן, ספק טלפוניה או כלי ניטור, יש לתעד את השימוש הרלוונטי ולהחליט איזה מידע משותף. גם כלי חינמי יכול לשמור נתונים, ולכן צריך לבדוק את ההגדרות ולא להניח שהוא חסר סיכון.
מומלץ להפעיל אנליטיקס רק עם מזהה שהוגדר על ידי העסק, לא להכניס מפתחות סודיים לדפדפן, ולבדוק שהאירועים אינם מכילים מספרי טלפון, תוכן שיחה או מידע אישי מיותר.
העמוד צריך לכלול תאריך עדכון כאשר הנוסח מתחלף. שינוי בטופס, ספק, תהליך הקלטה, כלי אנליטיקס או אופן שמירת מידע עשוי לדרוש בדיקה מחודשת של העמוד ושל ההסכמות.
StackLab יכול לסמן בפרויקט אילו נקודות דורשות אישור עסקי או משפטי לפני עלייה לאוויר. כך האחריות אינה נשארת בתוך קוד או תסריט שאף אחד לא חוזר לבדוק.
עוצרים לרגע באמצע המדריך, בוחרים את התהליך החשוב ביותר לעסק וממשיכים משם לדמו קצר ומותאם.
בפרויקט פיתוח יש להפריד בין אחריות StackLab על התכנון והיישום לבין אחריות הלקוח על המידע, הרשאות, הסכמים, מדיניות העסק והאישור לשימוש בערוצים. נקודת ההתחלה היא מיפוי ברור ולא הנחה שכל מערכת מותרת לשימוש בכל דרך.
לפני השקה מגדירים מי מאשר תוכן, מי בודק הרשאות, מי מקבל התראות, מי מטפל בבקשות פונה ומי מאשר שינוי. תיעוד כזה הופך אמון מתוצאה של ניסוח יפה לתהליך שאפשר לבצע.
לפני שמעלים את העמוד לאוויר עוברים על שם העסק, כתובת הקשר, ספקים, טפסים, כלי אנליטיקס, הודעות הסכמה, תהליך מחיקה, הרשאות והדרך שבה מטפלים בשיחה. כל סעיף צריך להיות מחובר למערכת קיימת או לקבל בעלים שימלא אותו.
בדיקה כזו מונעת מצב שבו האתר מצהיר דבר אחד והטפסים או האוטומציות מבצעים דבר אחר. היא גם נותנת לצוות רשימת משימות ברורה לפני קמפיין או חיבור ספק חדש.
לכל סוג מידע כדאי להגדיר מקור, מטרת שימוש, תקופת שמירה, גישה ותנאי מחיקה. לידים, תמלולים, לוגים, אירועי אנליטיקס ומסמכים אינם בהכרח צריכים להישמר באותה צורה או באותו מקום.
בפרויקט אוטומציה מתעדים את מחזור החיים בתוך מפת התהליך. כאשר מידע עובר מ-WhatsApp ל-CRM, ל-Webhook או לדשבורד, יודעים איזה שלב יוצר אותו ואיזה שלב מסיים את הצורך בו.
מדיניות אינה מסמך שמפרסמים פעם אחת ושוכחים. שינוי בספק, טופס, מודל AI, מערכת CRM, שיטת הקלטה או ערוץ הודעות צריך להפעיל בדיקה מחודשת של ההרשאות, הנוסח והלוגים.
אפשר להוסיף תזכורת רבעונית לבדיקת פרטי הקשר, ספקים, הרשאות ואירועי אנליטיקס. תחזוקה כזו מחברת בין האתר לבין התפעול האמיתי של StackLab והעסק.
כאשר ספק חיצוני בונה אוטומציה, API או סוכן, צריך לתעד אילו חשבונות מחוברים, מי הבעלים שלהם, איזה מידע נגיש ומה קורה בסיום ההתקשרות. עדיף להשתמש בהרשאות מוגבלות, חשבונות עסקיים ומפתחות שניתן לבטל ולהחליף.
מסמך מסירה טוב כולל תרשים חיבורים, שדות, Webhooks, לוגים, תקלות ידועות, פרטי תחזוקה והנחיות לצוות. כך העסק אינו תלוי בזיכרון של אדם אחד ויכול להמשיך לנהל את המערכת.
לפני חיבור CRM, WhatsApp, API או כלי אנליטיקס שאלו איזה מידע עובר, מי רואה אותו, היכן נשמר, כמה זמן הוא נדרש ומה קורה אם המשתמש מבקש לעצור. שאלו גם האם החיבור מתועד ואיך בודקים את ההרשאות לאחר שינוי.
StackLab יכול להוסיף את השאלות האלה למסמך האפיון ולרשימת הבדיקה של הפרויקט. ההחלטות מתקבלות לפני ההשקה, ולא רק אחרי שהאוטומציה כבר מעבירה מידע בין מערכות.
לפני פרסום או חיבור חדש, בעל העסק צריך לעבור על הנוסח, הפרטים, ההרשאות והספקים. לאחר האישור מתעדים מי אישר ומתי, כדי שיהיה ברור מה הייתה נקודת ההחלטה.
אם הפעילות משתנה, חוזרים לעמוד, מעדכנים את המדיניות ומוודאים שהטפסים, השיחות והאוטומציות עדיין תואמים לה.
לא. יש להשלים את הפרטים העסקיים ולהעביר את הנוסח לבדיקה משפטית לפי הפעילות והמערכות בפועל.
זה תלוי בתצורה. יש להציג שקיפות והסכמה מתאימות ולהגדיר שמירה, גישה ומחיקה.
צריך להגדיר זאת לפי המערכות והפרויקט. אין להבטיח שמירה או מחיקה לפני שממפים את התהליך בפועל.
יש להציג בעמוד כתובת קשר פעילה ולקבוע תהליך פנימי לטיפול ובדיקת זהות.
סוכן קולי הוא אחת מהיכולות של StackLab. בחרו תרחיש ושמעו איך שיחה יכולה להפוך לפעולה עסקית.
השאירו טלפון ונכניס אתכם לתור לדמו קולי קצר.
השאירו פרטים. StackLab יחזור אליכם עם כיוון מעשי לסוכן, אוטומציה, API או מערכת שמתאימה לתהליך שלכם.