StackLab · AI, אוטומציה ופיתוח מערכות שמחברים את העסק
TRUST & RESPONSIBILITY

תנאי שימוש

כללים לשימוש באתר, בדמו, בכלים החינמיים ובשירותי StackLab.

תנאי שימוש

כללים לשימוש באתר, בדמו, בכלים החינמיים ובשירותי StackLab.

מה הפתרון יודע לבצע?

AIאוטומציהAPICRMבקרה
STACKLAB FIELD GUIDE

המדריך המעשי לבניית מערכת שעובדת בעסק

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

מטרת העמוד ומה חשוב להשלים

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

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

איזה מידע עשוי להיאסף באתר

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

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

איך משתמשים במידע

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

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

שיחות, הקלטות ו-Voice AI

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

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

אבטחה, הרשאות וספקים

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

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

זכויות, בקשות ויצירת קשר

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

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

כלים חיצוניים ואנליטיקס

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

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

עדכונים ושינויים

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

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

READY TO BUILD

רוצים לראות איך זה עובד אצלכם?

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

קבעו שיחת אפיון

אחריות משותפת בפרויקט

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

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

בדיקת מוכנות לפני פרסום

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

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

שמירת מידע ומחזור חיים

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

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

בדיקה מחודשת לאורך זמן

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

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

עבודה עם ספקי פיתוח ואינטגרציה

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

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

שאלות שכדאי לשאול לפני חיבור חדש

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

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

אישור לפני עלייה לאוויר

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

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

QUESTIONS & ANSWERS

שאלות נפוצות

האם זה נוסח משפטי סופי?

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

האם שיחת דמו יכולה לכלול הקלטה?

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

האם אתם שומרים את כל המידע?

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

למי פונים בבקשה לגבי מידע?

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

HEAR THE DIFFERENCE

שומעים את הקול. מבינים את הערך.

סוכן קולי הוא אחת מהיכולות של StackLab. בחרו תרחיש ושמעו איך שיחה יכולה להפוך לפעולה עסקית.

רוצים לקבל שיחה מהסוכן?

השאירו טלפון ונכניס אתכם לתור לדמו קולי קצר.

בואו נבין מה העסק צריך

השאירו פרטים. StackLab יחזור אליכם עם כיוון מעשי לסוכן, אוטומציה, API או מערכת שמתאימה לתהליך שלכם.

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

בואו נבנה את המערכת שלכם