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

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

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

הגדרות המשפיעות על הזיהוי וההחלטה כיצד לפעול:

• מנע שיוך ליישויות על פי סוגי סטטוסים (הגדרות CRM => תקשורת נכנסת - שיוך התיעוד ליישות)
  • הגדרה זו קובעת לאיזה יישויות לא לשייך תקשורת נכנסת. בדרך כלל תרצו שיהיו שם סוגי סטטוס כמו: נסגר, נסגר בהצלחה, נסגר ללא הצלחה, לא רלוונטי, משוכפל
  • ואז במידה ויש יישות שהסוג של הסטטוס בו היא נמצאת, לא קיים ברשימה המוגדרת, התקשורת הנכנסת תשתייך ליישות הקיימת ולא תיצור פניה חדשה.
   
• מספר ימים מקסימלי מהתקשרות האחרונה עם היישות (הגדרות CRM => תקשורת נכנסת - שיוך התיעוד ליישות)
  • הגדרה זו קובעת את טווח מספר הימים בהם הייתם רוצים שתקשורת נכנסת ליישות שלא נמצאת בסטטוס ברשימה, תכנס כתקשורת ביישות שנמצאה. במידה ומספר הימים שעברו מהתקשורת האחרונה גדול יותר מהמספר המוגדר, תיווצר פניה חדשה עם הפרטים של התקשורת הנכנסת במקום תיעוד תקשורת בכרטיס הקיים.​
   
• משימות הנוצרות מתקשורת נכנסת - הגדר אחראי לטיפול לפי התקשורת היוצאת האחרונה (היסטוריית פעילות ותקשורת / משימות למשתמשים)
  • תופס לשיחות נכנסות, אימיילים נכנסים והודעות טקסט נכנסות. במידה והגדרה זו דלוקה, האחראי על המשימה או הפנייה שתיווצר בעקבות התקשורת הנכנסת, יהיה המשתמש אשר ביצע את התקשורת היוצאת האחרונה לאותו פונה. הכוונה לשיחת טלפון יוצאת שהסתיימה (לא במידה והיא לא נענתה) או הודעת טקסט יוצאת (סמס או וואטסאפ). אנחנו ממליצים שהגדרה זו תהיה דלוקה, כי בדרך כלל האחרון שפנה ללקוח הוא זה שצריך להמשיך את התקשורת איתו. זה פחות מתאים לעסקים נדירים בהם יש מישהו שמבצע את התקשורת היוצאת ואחרים מטפלים בתקשורת הנכנסת.
   
• שיחות נכנסות - צור תמיד פניה חדשה (שיחות טלפון)
  • על כל שיחה לייצר פניה חדשה. בדרך כלל הגדרה זו כבוייה אך לעיתים ישנם עסקים שרוצים לנטר את כמות השיחות מכל מקור ולכן רוצים שעל כל שיחה תיווצר פניה נפרדת. מתאים בדרך כלל לעסקים שמעוניינים למדוד את כמות השיחות שנכנסות למספרים וירטואלים שונים, ממקורות שונים.
   
• שיחת נכנסת לא נענתה - צור תמיד פניה חדשה (שיחות טלפון) / צור משימה עבור שיחה שלא נענתה (שיחות טלפון)
  • האם כאשר שיחה לא נענית, תיווצר משימה? האחראי על המשימה ייקבע לפי השלוחה אליה בוצעה השיחה שלא נענתה. (הנתון הזה תלוי בערכים שמתקבלים מהטלפוניה. בטלפוניות מסויימות הפנייה של שיחה למוקד שיחות חיצוני מדווח לקאלה בתור שיחה שלא נענתה ולכן במצב כזה אם ההגדרה דלוקה, תיווצר משימה של שיחה שלא נענתה, למרות שהיא עברה למוקד חיצוני. אם אותו מוקד מוגדר לייצר פניות בקאלה, תיווצר בנפרד פניה מהמוקד.)
   
• מנע יצירה של משימה עבור שיחה שלא נענתה במידה ולא נמצא אחראי (שיחות טלפון)
  • במידה ולא מעוניינים שתיווצר משימות של שיחות שלא נענו ללא אחראי, ניתן להדליק את ההגדרה הזו, אבל ביננו, זה קצת כמו לקבור את הראש בחול. עדיף להגדיר מישהו שאחראי לנתר משימות ללא אחראי ולשייך אותן לאחראי מסויים או לבצע אותן בעצמו. לכן המלצתנו החמה להשאיר את ההגדרה הזו כבוייה.
   
• הודעת טקסט נכנסת - צור תמיד פניה חדשה (הודעות טקסט)
  • במידה והגדרה זו דלוקה, על כל הודעת טקסט שנכנסת, תיווצר משימה 
   
• צור משימה עבור אימייל נכנס (אימיילים)
  • האם כאשר אימייל נכנס תיווצר משימה לאחראי על אותה יישות או לא.
   
• צור פניה חדשה כשהיישות המזוהה היא "חבר" (אימיילים) (הודעות טקסט)
  • במידה והיישות שזוהתה היא חבר / לקוח, אז במקום ליצור משימה או לתעד את ההתקשרות בכרטיס של החבר (תיק לקוח), תיווצר פניה חדשה. ההבדל המהותי הוא שלחברים אין סטטוסים אלא זו יישות שמחברת בין כל הפניות וההזמנות. לכן הגיוני בדרך כלל שבמקרה כזה תיווצר פניה חדשה וההיסטוריה שלה תנוהל בנפרד מהתיק לקוח.
   
• זיהוי אחראי לטיפול לפי החבר המשוייך או פניות דומות (ניהול פניות)
  • במידה ונוצרת פניה חדשה, האם לשייך לה אחראי בצורה אוטומטית לפי האחראי על החבר (הלקוח) ובמידה ואין יישות של לקוח דומה, אז לפי האחראי האחרון הפעיל מהפניות הדומות שלו.
  • מנע שיוך אחראי לטיפול לפי החבר (ניהול פניות)
    • להתעלם מהאחראי על החבר בעת הזיהוי. האחראי ייקבע לפי הפניות הדומות בלבד.
   
• זיהוי אחראי לטיפול לפי תקשורת אחרונה (ניהול פניות)
  • האם לקבוע אחראי על הפניה בצורה אוטומטית לפי המשתמש אשר ביצע את התקשורת היוצאת האחרונה לאותו פונה. הכוונה לשיחת טלפון יוצאת שהסתיימה (לא במידה והיא לא נענתה) או הודעת טקסט יוצאת (סמס או וואטסאפ). הגדרה זו בדרך כלל דלוקה אצל רוב העסקים.
  • זיהוי אחראי - בכמה ימים אחורה לחפש תקשורות (ניהול פניות)
    • ניתן לשלוט בכמות הימים אחורה בהן תבדק התקשורת שבוצעה. למשל אם מוגדר 7 יום, אז רק אם משתמש יצר איתו קשר בשבוע האחרון הוא יהיה אחראי על הפניה שתיווצר.