פתרונות מיקור חוץ למוקדי שירות: ארכיטקטורת טכנולוגיה שמונעת כשלי יישום בעלות של 180 אלף דולר

הספק שלכם מבטיח "אינטגרציית CRM חלקה" ו"יכולות רב-ערוציות". ארבעה שבועות לאחר ההשקה, הצגת נתוני הלקוח האוטומטית (screen-pop) ב-Salesforce אורכת 9 שניות, לתורי הצ'אט אין ניתוב לפי עדיפות, ותגובות המייל מגיעות בממוצע תוך 18 שעות — למרות התחייבות להסכם רמת שירות (SLA) של 4 שעות.

הכשל אינו נובע מהמיקום הגיאוגרפי או מאיכות הנציגים — אלא מארכיטקטורת הטכנולוגיה. פתרונות מיקור חוץ למוקדי שירות דורשים תשתית ספציפית: פלטפורמות מוקד שירות בענן (CCaaS) עם השהיית API מתחת ל-200 מילישניות, מנועי ניתוב רב-ערוציים, ניתוח שיחות (speech analytics) על 100% מהאינטראקציות, ותוכנת ניהול כוח אדם (WFM) עם חיזוי מבוסס בינה מלאכותית.

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

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

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

ליבת מוקד שירות בענן (CCaaS): פתרונות מודרניים משתמשים בפלטפורמות כמו Amazon Connect, Twilio Flex, Talkdesk או Five9, המחליפות מרכזיות PBX מדור קודם המותקנות מקומית. היתרונות כוללים:

• תמחור לפי דקה, שמבטל בזבוז על רישיונות עמדה בתקופות של נפח נמוך

• עיצוב מבוסס API המאפשר אינטגרציית CRM מתחת ל-250 מילישניות

• נקודות נוכחות גלובליות (PoPs) שמפחיתות השהיה (ל-Twilio יש מיקומי קצה בדרום אפריקה ובקניה)

• התאמת קיבולת אוטומטית שמתמודדת עם גאות של 400% ללא תכנון קיבולת מראש

עם זאת, ספקים מדור קודם עדיין משתמשים במערכות Avaya או Cisco מקומיות הדורשות מנהרות VPN. ה-VPN מוסיף השהיה של 200-350 מילישניות, מה שהופך פריסה בחו"ל לבלתי שמישה עבור תהליכי עבודה אינטראקטיביים. לכן, ארכיטקטורה מבוססת ענן היא חובה, לא אופציה.

שכבת תיווך (middleware) לאינטגרציית CRM: חיבורי API ישירים בין פלטפורמת ה-CCaaS למערכות ה-CRM יוצרים אינטגרציות שבירות, שנשברות בעדכוני גרסה. פתרונות ברמה ארגונית משתמשים בשכבת תיווך מסוג iPaaS כמו MuleSoft, Workato או Zapier Enterprise, היוצרת שכבות הפשטה.

דוגמה לזרימת נתונים: שיחת Twilio מתחברת ← Workato מפעיל טריגר ← מבצע שאילתה ל-Salesforce ← מעשיר בנתוני הזמנה מ-Shopify ← מציג רשומה מאוחדת לנציג תוך 280 מילישניות. אינטגרציה ישירה הייתה דורשת 3 קריאות API עוקבות (820 מילישניות בסך הכול).

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

מנוע ניתוב רב-ערוצי (omnichannel): מערכות קוליות בלבד משתמשות בניתוב שיחות (ACD). ניתוב רב-ערוצי דורש ניתוב מאוחד בין קול, צ'אט, מייל, SMS ומדיה חברתית. פלטפורמות כמו Genesys Cloud או NICE CXone מאחדות את התורים.

יכולת קריטית: שקלול עדיפות בין ערוצים. לקוח שהתקשר, ואז פתח צ'אט, ואז שלח מייל — אמור להיות מנותב לאותו נציג עם היסטוריית האינטראקציה המלאה. מערכות מבודדות מתייחסות לכל פנייה כנפרדת, מה שמאלץ לקוחות לחזור על מידע. תופעה זו גורמת ל-64% מהלקוחות הרב-ערוציים להחליף מותג, על פי מחקר Salesforce State of the Connected Customer.

פלטפורמת ניתוח שיחות (speech analytics): בקרת איכות ידנית בוחנת 2-10% מהשיחות. ניתוח מבוסס בינה מלאכותית מנקד 100% עבור:

• סנטימנט (תסכול לקוח מזוהה דרך הטון, לא רק המילים)

• עמידה בתסריט (האם הנציג הציע את מועדון הלקוחות?)

• ביטויים אסורים ("אני לא יודע" = פער בהכשרת הנציג)

• זיהוי שקט מת (מעל 8 שניות דממה = בעיית השהיה ב-CRM)

פלטפורמות כמו CallMiner או Observe.AI עולות 18 דולר לנציג בחודש, אך מזהות בעיות המשפיעות על 100% מהשיחות, לעומת מה שדגימה של 2% תופסת. לכן, ניתוח השיחות מחזיר את ההשקעה דרך שיפורי איכות תוך 60 יום.

תוכנת ניהול כוח אדם (WFM): תזמון מבוסס גיליון אלקטרוני קורס ב-40 נציגים ומעלה. פלטפורמות WFM כמו NICE IEX או Calabrio חוזות נפח שיחות תוך שימוש בדפוסים היסטוריים בתוספת נתונים חיצוניים (מזג אוויר, לוח מבצעים), ומשיגות דיוק של 95%.

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

מערכת ניהול ידע: נציגים זקוקים לגישה מיידית למפרטי מוצר, מדיניות ומדריכי פתרון תקלות. Confluence או Notion עם חיפוש Algolia מספקים אחזור מידע תוך פחות מ-2 שניות. תיקיות SharePoint מיושנות עם ספריות מקוננות מוסיפות 90 שניות לכל שיחה לזמן הטיפול הממוצע (AHT).

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

במה שונים פתרונות רב-ערוציים למיקור חוץ למוקדי שירות מפתרונות קוליים בלבד?

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

מורכבות הניתוב: מערכות קוליות בלבד משתמשות בניתוב מבוסס מיומנויות (דובר ספרדית, תמיכה טכנית ברמה 2). ניתוב רב-ערוצי דורש ניתוב משולב שבו נציגים מטפלים בכמה ערוצים בו-זמנית — שיחה קולית אחת, או שלושה צ'אטים במקביל, או חמישה מיילים.

עם זאת, תכנון הקיבולת הופך למעריכי. נציג המטפל בשיחות קוליות עם זמן טיפול ממוצע (AHT) של 6.5 דקות מעבד 55 שיחות ביום. אותו נציג המטפל בצ'אט בממוצע של 12 דקות (4 שיחות במקביל) מעבד 120 פניות ביום. ניתוב מעורב חייב להביא בחשבון את דפוסי ההגעה של כל ערוץ — צ'אט מתגבר בשעות העבודה, מייל בלילה.

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

מודל נתוני ה-CRM: מערכות קוליות בלבד מתעדות שיחות כפעילויות. ניתוב רב-ערוצי דורש ציר זמן מאוחד של הלקוח המציג: התקשר ביום שני בשעה 9:00 בנוגע להזמנה #4477 (6 דקות) ← שוחח בצ'אט ביום שני בשעה 14:00 בבקשה למעקב (4 דקות) ← שלח מייל ביום שלישי בשעה 8:00 בבקשת החזר (טופל).

הדבר דורש התאמה אישית של ה-CRM. תצוגת "Case Feed" של Salesforce Service Cloud מאחדת זאת; מערכות CRM בסיסיות חסרות שרשור רב-ערוצי. לכן, בחירת הטכנולוגיה חייבת להקדים את היישום — הצמדת יכולת רב-ערוצית על מערכות CRM לא מתאימות נכשלת.

הבדלים במיומנויות הנציגים: נציגים קוליים זקוקים לתקשורת מילולית ולבהירות מבטא. נציגי צ'אט זקוקים למהירות הקלדה (55+ מילים לדקה) ולשליטה בדקדוק. נציגי מייל זקוקים למיומנויות כתיבה פורמלית.

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

אתגרי ניטור איכות: האזנה לשיחות קוליות אורכת 6.5 דקות לכל ביקורת. קריאת תמלילי צ'אט אורכת 2 דקות. הערכת איכות תגובת מייל דורשת 3 דקות.

עומס בקרת האיכות מתפוצץ בסביבה רב-ערוצית — אנליסט בקרת איכות הבוחן 10% מהאינטראקציות בשלושה ערוצים זקוק ל-2.2 שעות ביום לכל נציג, לעומת 0.65 שעות בערוץ קולי בלבד. הדבר דורש או פי 3 כוח אדם בבקרת איכות, או ביקורת בסיוע בינה מלאכותית המנקדת אינטראקציות שגרתיות באופן אוטומטי, ומסלימה לביקורת אנושית רק את החריגים.

מהם שלבי היישום של פתרונות מיקור חוץ למוקדי שירות?

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

שלב 1 - תיעוד דרישות (שבועות 1-2): מפו כל סוג של אינטראקציה עם לקוח:

• נכנס: סטטוס הזמנה, החזרים, תמיכה טכנית, בירורי חיוב

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

עבור כל סוג, תעדו:

• נתוני CRM נדרשים (היסטוריית הזמנות, סטטוס תשלום, כתובת משלוח)

• זמן טיפול ממוצע (AHT) צפוי (יעדים לביצועי הנציג)

• דרישות תסריט (גילויי ציות, הצעות מכירה נלווית)

• נתיבי הסלמה (מתי נציגים מעבירים למפקחים)

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

שלב 2 - בחירת מערך הטכנולוגיה (שבועות 3-4): העריכו פלטפורמות CCaaS על בסיס:

• השהיית API (מתחת ל-200 מילישניות ממתקן הספק ועד נקודת הנוכחות של הפלטפורמה)

• תמיכה בערוצים (קול, צ'אט, מייל, SMS כמינימום)

• מחברי CRM מובנים (Salesforce, HubSpot, Zendesk)

• הסמכות ציות (PCI-DSS אם מטפלים בתשלומים, HIPAA לתחום הבריאות)

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

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

שלב 3 - פיתוח אינטגרציה (שבועות 5-8): בנו מחברים בין פלטפורמת ה-CCaaS למערכות הלקוח:

• סנכרון דו-כיווני של Salesforce (שיחה יוצרת פנייה, עדכוני פנייה גלויים בשולחן העבודה של הנציג)

• חיפוש הזמנות ב-Shopify (מלאי בזמן אמת, סטטוס הזמנה)

• עיבוד תשלומים ב-Stripe (יזום החזרים מממשק הנציג)

בדקו בסביבת בדיקה (sandbox) — לעולם אל תפתחו ישירות בסביבת הייצור. כשלי אינטגרציה נפוצים:

• חריגה מהגבלת קצב הבקשות של ה-API (Shopify במסלול הסטנדרטי מאפשר 2 בקשות לשנייה, לא מספיק למוקד בן 40 נציגים)

• פקיעת אסימון האימות ששוברת חיבורים לאחר 30 יום

• כשלי webhook כאשר מערכת הלקוח מושבתת (נדרשת לוגיקת ניסיון חוזר עם השהיה מעריכית)

שלב 4 - בדיקת עומסים (שבוע 9): דמו נפח ייצור:

• הפיקו 400 שיחות מקבילות באמצעות כלים כמו Apache JMeter או LoadNinja

• מדדו את זמן התגובה של הפלטפורמה תחת עומס (סביר: מתחת ל-300 מילישניות באחוזון ה-95)

• זהו צווארי בקבוק (שאילתות מסד נתונים, קריאות API, תפוקת רשת)

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

יתרה מכך, בדקו תרחישי אסון:

• כשל במעגל האינטרנט הראשי (האם גיבוי ה-4G שומר על האיכות?)

• השבתה של פלטפורמת ה-CRM (האם הנציגים רואים הודעות שגיאה או נתונים שמורים?)

• הפסקת חשמל (האם האל-פסק (UPS) מספק 30 דקות פעולה כפי שהובטח?)

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

שלב 5 - הדרכה (שבועות 10-13): מינימום ארבעה שבועות:

• שבוע 1: ידע על המוצר, מדיניות החברה, ניווט ב-CRM

• שבוע 2: תרגול טיפול בשיחות עם תרחישי משחק תפקידים

• שבוע 3: ניטור שיחות חי (נציגים חדשים מאזינים לנציגים מנוסים)

• שבוע 4: קינון (נציגים חדשים מקבלים שיחות תחת ניטור מפקח, עם משוב מיידי)

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

יתרה מכך, ההדרכה חייבת לכסות מקרי קצה:

• לקוח כועס הדורש פתרון בלתי אפשרי (כיצד להרגיע מבלי להפר את המדיניות)

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

• ניסיון הזמנה הונאתי (דגלים אדומים לזיהוי, פרוטוקול הסלמה)

שלב 6 - הרצה מקבילה (שבועות 14-15): הפעילו את המוקד הישן והחדש בו-זמנית:

• נתבו 20% מהשיחות למוקד החדש בחו"ל

• נתבו 80% למוקד הקיים

• השוו מדדים: זמן טיפול ממוצע (AHT), פתרון בשיחה הראשונה (FCR), מדד שביעות רצון (CSAT), שיעור העברות

שלב זה מזהה פערי איכות לפני המעבר המלא. תגליות נפוצות:

• זמן הטיפול הממוצע בחו"ל ארוך ב-40% (נדרשת הכשרת CRM נוספת)

• שיעורי ההעברה גבוהים פי 3 (לנציגים חסרה עצמאות לפתור בעיות)

• ציוני שביעות הרצון נמוכים ב-12 נקודות (בעיות מבטא או בעיות תסריט?)

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

שלב 7 - עלייה לאוויר וניטור (שבוע 16 ואילך): העבירו את שאר הנפח באופן הדרגתי:

• שבוע 16: 50% בחו"ל

• שבוע 17: 80% בחו"ל

• שבוע 18: 100% בחו"ל (המוקד הישן בכוננות למשך 30 יום)

נטרו את הסכם רמת השירות (SLA) מדי יום:

• זמינות (uptime) (מעל 99.5%)

• שיעור מענה תוך 30 שניות (מעל 85%)

• זמן טיפול ממוצע (AHT) מול היעד

• ציוני שביעות רצון (CSAT) מול קו הבסיס

בנוסף, קיימו סקירות תפעוליות שבועיות עם הספק:

• בעיות מגמתיות (תלונות לקוחות נפוצות)

• ביצועי המערכת (השהיית CRM, זמינות הפלטפורמה)

• משוב נציגים (אילו פערי הדרכה נותרו?)

מה גורם למערכי הטכנולוגיה של חברות מיקור חוץ למוקדי שירות להיכשל?

שלושה אופני כשל מופיעים ב-79% מהפריסות הכושלות.

כשל מספר 1 - חוסר תאימות של CRM מדור קודם:

תרחיש: הלקוח משתמש ב-SAP C4C (מערכת CRM מקומית) הדורשת גישת VPN. למתקן הקנייני של הספק יש השהיית בסיס של 280 מילישניות למרכז הנתונים של הלקוח. ה-VPN מוסיף 180 מילישניות של תקורת הצפנה. סך הכול: 460 מילישניות.

השפעה: הצגת נתוני הלקוח אורכת 5+ שניות. הנציגים עונים לשיחות "בעיוורון", ומבקשים מידע שכבר קיים במערכת. הלקוחות זועמים, ומדד שביעות הרצון (CSAT) קורס ב-28 נקודות.

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

כשל מספר 2 - הקצאת רוחב פס לא מספקת:

תרחיש: הספק מתמחר 95 דולר לנציג עבור תשתית טלפוניה. הנחות היסוד:

• 1 מגה-ביט לשנייה העלאה לכל שיחה מקבילה

• 30% שימוש בו-זמני (30 מתוך 100 נציגים בשיחות)

• סך הכול: נדרש רוחב פס העלאה של 30 מגה-ביט לשנייה

בדיקת מציאות: למתקן יש 50 מגה-ביט לשנייה העלאה המשותפים ל-200 נציגים (4 לקוחות). מוקד ה-100 נציגים של הלקוח מקבל הקצאה של 25% = 12.5 מגה-ביט לשנייה, התומכים ב-12 שיחות מקבילות בלבד. בשעת השיא עם 60 שיחות מקבילות, איכות הקול מתדרדרת באופן קטסטרופלי.

מניעה: החוזה חייב לציין הקצאת רוחב פס ייעודית, לא מאגרים משותפים. דרשו מהספק להוכיח את קיבולת המעגל באמצעות בדיקות מהירות במהלך ביקורים במתקן. בנוסף, הסכם רמת השירות (SLA) חייב להבטיח השהיה מתחת ל-150 מילישניות וריצוד (jitter) מתחת ל-30 מילישניות אפילו בניצולת נציגים של 100%.

כשל מספר 3 - הגדרה שגויה של ניתוב רב-ערוצי:

תרחיש: הלקוח פורס קול + צ'אט + מייל. לוגיקת הניתוב מתייחסת לכל ערוץ באופן שווה. הסכם רמת השירות (SLA) למייל הוא 4 שעות, ולצ'אט 2 דקות.

בעיה: הנציגים מעדיפים מייל (ללא לחץ בזמן אמת). 70% מהנציגים מגדירים את הסטטוס שלהם למייל בלבד, ומשאירים 30% לטיפול בקול+צ'אט. תור הצ'אט מתפוצץ לזמני המתנה של 8 דקות, ומפר את הסכם רמת השירות.

תיקון: שילוב ערוצים כפוי — הנציגים חייבים לקבל את הערוץ הראשי (קול) עם הצטרפות מרצון לערוץ משני (צ'אט/מייל). תוכנת ה-WFM משבצת תמהיל ערוצים על בסיס מיומנויות ועומק התור בזמן אמת. אם תור הצ'אט חורג מ-2 דקות, המערכת משבצת אוטומטית נציגים מוסמכים לצ'אט ללא קשר להעדפה.

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

פתרונות מיקור חוץ למוקדי שירות מצליחים באמצעות פלטפורמות מוקד שירות בענן (CCaaS) עם השהיית API מתחת ל-200 מילישניות, מנועי ניתוב רב-ערוציים המונעים בידוד ערוצים, ניתוח שיחות (speech analytics) המנקד 100% מהאינטראקציות, ותוכנת ניהול כוח אדם (WFM) החוזה נפח בדיוק של עד 5%.

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

היישום דורש גישה מדורגת בת 16 שבועות: תיעוד דרישות, בחירת פלטפורמה עם הוכחת היתכנות, פיתוח אינטגרציה, בדיקת עומסים, הדרכת נציגים בת 4 שבועות, הרצה מקבילה להשוואת מדדים, ומעבר הדרגתי תוך ניטור יומי של הסכם רמת השירות (SLA). מעברים ישירים של 100% מסכנים בקריסת שירות כאשר צצות בעיות.

אופני כשל נפוצים כוללים חוסר תאימות של CRM מדור קודם המייצר השהיה של 460 מילישניות, הקצאת רוחב פס לא מספקת התומכת ב-12 שיחות מקבילות בלבד במקום 60, והגדרה שגויה של ניתוב רב-ערוצי הגורמת לתורי צ'אט של 8 דקות המפרים את התחייבויות הסכם רמת השירות.

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

מסגרת ההחלטה: העריכו פלטפורמות CCaaS לפי השהיית API והסמכות ציות, דרשו הוכחת היתכנות המדגימה הצגת נתוני לקוח מתחת ל-300 מילישניות, בצעו ביקורים במתקן תוך צפייה בקיבולת רוחב הפס באמצעות בדיקות מהירות, ודרשו הרצה מקבילה של 30 יום המשווה את מדדי החו"ל לקו הבסיס לפני המעבר המלא. פתרונות הבנויים על ספקי אינטרנט (ISP) ביתיים, מרכזיות PBX מדור קודם, או אינטגרציות CRM ישירות ללא הפשטת שכבת תיווך — נכשלים תוך 90 יום.