אוטומציה ל-CRM: מה היא באמת כוללת, ואיך היא מתקלקלת בשקט

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

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

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

חמשת התחומים שאוטומציה ל-CRM אמורה לכסות

1. תיעוד שנוצר כתוצר לוואי של העבודה

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

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

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

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

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

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

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

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

3. מעברי שלבים שהולכים אחרי העובדות

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

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

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

4. זיהוי דעיכה, האוטומציה שאנשים מפספסים

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

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

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

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

5. דיווח שמרכיב את עצמו

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

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

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

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

איך אוטומציה ל-CRM מתקלקלת

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

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

כללים שאיש אינו בעליהם

הכשל הראשון הוא ארגוני והוא כמעט אוניברסלי.

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

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

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

כשלים שקטים

הכשל השני הוא טכני והוא זה שמרמה אנשים מנוסים.

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

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

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

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

אוטומציות שרצות על נתונים שגויים

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

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

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

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

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

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

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

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

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

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

איפה Zoye נכנסת

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

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

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

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

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

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

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

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

ממשל, או איך עדיין לסמוך על זה בעוד שנה

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

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

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

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

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

מה להפוך לאוטומטי ובאיזה סדר

אם אתם מתחילים מאפס, הסדר להלן מסודר לפי תלות ולא לפי אטרקטיביות.

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

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

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

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

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

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

הפכו את הרשומה לאוטומטית, לא את הקשר

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

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

נסו את Zoye ותארו את הכלל הראשון שלכם במשפט.

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