נקודות גישה ישירות (DAP)

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

יש כמה דרכים להגדיר פלטפורמות DAP, באמצעות API או מערכת CRM (או שניהם). בקטע הזה מפורטות אפשרויות ההגדרה של DAPs.

סוגי DAP

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

סוג DAP IVR נייד אינטרנט
DAP של פלח משתמשים: מתאים ומנתב משתמשי קצה לפי צמדי מפתח/ערך של נתוני חשבון של משתמשי קצה מתוך ה-CRM.
DAP כללי: נקודת גישה שהמפתחים שלכם מציבים בהגדרת האפליקציה או ה-SDK. כשמשתמש קצה מגיע לנקודת הגישה הזו, הוא מנותב לתור ספציפי.
Support Phone Number DAP: מנתב משתמשי קצה לתורים ספציפיים בהתאם למספר הטלפון של התמיכה שאליו הם מתקשרים כדי להגיע למוקד הטלפוני שלכם.
תגובת API ל-DAP: התאמה של משתמשי קצה לתורים ספציפיים והפניה שלהם אליהם בהתאם לזוגות של מפתח וערך של תגובת API.
DAP לאפליקציה לנייד: המערכת מנתבת משתמשי קצה לתורים ספציפיים בהתאם לאפליקציה לנייד. האפשרות הזו זמינה רק בסביבות שבהן מופעלת התכונה מספר אפליקציות לנייד.

סדר ההתאמה והאינטראקציות ב-DAP

כשמשתמשים בכמה סוגים של DAP, פלטפורמת Contact Center AI (פלטפורמת CCAI) מחפשת התאמות, קודם לפי סוג ה-DAP ואז לפי הסדר שבו נוצרו ה-DAP. סדר ה-DAP שונה אם משתמשים באפליקציה אחת או יותר לנייד בסביבה. אם שני קריטריונים של DAP מתקיימים בסוג מסוים של DAP, פלטפורמת CCAI מנתבת את השיחה על סמך הקריטריון הראשון שנוצר.

סוגים וסדר של DAP בערוץ IVR רגיל

  1. מעבר אוטומטי ל-PSTN בנייד (אם משתמשים ב-SDK לנייד)

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  2. מספר טלפון DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  3. כללי DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  4. API DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  5. User segment SAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: העברה לראש התור.

סדר חלופי של DAP ב-IVR

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

  1. כללי DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  2. API DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  3. מעבר אוטומטי ל-PSTN בנייד (אם משתמשים ב-SDK לנייד)

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  4. מספר טלפון DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  5. פלח משתמשים DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: העברה לראש התור.

סוגים וסדר של DAP בערוץ לנייד

  1. כללי DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  2. פלח משתמשים DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  3. Mobile App DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: העברה לראש התור.

הזמנה חלופית של DAP

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

  1. פלח משתמשים DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  2. כללי DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  3. Mobile App DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: העברה לראש התור.

סוגים וסדר של DAP בערוץ אינטרנט

  1. כללי DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  2. פלח משתמשים DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.

הזמנה חלופית של DAP

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

  1. פלח משתמשים DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.
  2. כללי DAP

    • התאמה: ניתוב לתור הזה.
    • אין התאמה: עוברים לשלב הבא.

הרשאות גישה ישירה לפלחי משתמשים

בכל תוכנות ה-CRM יש אובייקטים של אנשי קשר (שנקראים Contact,‏ People,‏ Customer או משהו דומה). פלטפורמת CCAI בודקת אוטומטית אובייקטים של אנשי קשר בכל פעם שמשתמש קצה פונה אליכם באמצעות IVR או SDK, ומשווה אותם לזוגות של מפתח וערך שבהם השתמשתם כדי להגדיר את ה-DAP.

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

דוגמה ל-DAP של פלח משתמשים

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

  1. במערכת לניהול קשרי לקוחות (CRM), יוצרים שדה מחושב שסופר את בקשות התמיכה הפתוחות.

  2. יוצרים DAP כדי לחפש ערך ספציפי בשדה המחושב הזה שמציין שיש כמה בקשות תמיכה פתוחות.

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

דוגמה לדרישות מוקדמות לשימוש ב-DAP בפלח משתמשים

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

  2. הפעלת גישה ל-CRM

    1. בפורטל של פלטפורמת CCAI, עוברים אל הגדרות > ניהול פעולות.

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

    3. לוחצים על שמירה של הגדרות כלליות כדי לשמור.

  3. בקטע יצירת DAP מוסבר איך מגדירים DAP של פלח משתמשים.

מספרי טלפון של תמיכה ב-DAP

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

דוגמאות של DAP למספרי טלפון של תמיכה

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

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

פורמטים נתמכים

  • מספרים בפורמט E164: ‏ +(country_code)(phone_number)
  • מספרי טלפון ב-SIP בפורמט של כתובת SIP נכנסת: sip:[number]@[domain]

דוגמה לדרישות מוקדמות ל-DAP למספר טלפון לתמיכה

  1. מוודאים שמספר הטלפון שרוצים להשתמש בו הוקצה לסביבת CCAI Platform.

  2. בקטע יצירת DAP מוסבר איך להגדיר DAP למספר טלפון לתמיכה.

API DAPs

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

הבקשה מעובדת באמצעות JSON. יש תמיכה בשיטות הבקשה POST ו-GET של HTTP. בניגוד לאפשרויות אחרות של DAP, אפשר גם להשתמש בלוגיקה של AND עם כמה זוגות של מפתח וערך. כשמזוהה התאמה של צמד מפתח/ערך, פלטפורמת CCAI מנתבת את השיחה באופן מיידי בהתאם להגדרה שלכם.

דוגמה לשימוש ב-DAP API

יש לכם API עם נתונים שמראים שמשתמש הקצה הוא Super-user, סוג המוצר הוא International, והוא עומד בקריטריונים ספציפיים אחרים. פלטפורמת DAP שהוגדרה לזיהוי של צמדי מפתח/ערך ספציפיים מעבירה אותם לתור ספציפי.

דוגמה לדרישות מוקדמות ל-DAP API

הרכיבים הנדרשים:

  • כתובת URL של API: נקודת קצה של כתובת URL שיכולה לקבל בקשה למספר טלפון ולהחזיר תגובה בפורמט JSON.

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

  • פרטי כניסה ל-API: נדרש אימות בסיסי לנקודת קצה שאינה Salesforce.

    או

  • הגדרת Salesforce: הוראות להגדרה הראשונית ב-Salesforce מופיעות בתיעוד של Salesforce.

הגדרת DAP ל-API

כדי להגדיר DAP של API:

  1. לוחצים על תפריט ואז על הגדרות > הגדרות למפתחים.

  2. עוברים לחלונית API request direct access point (נקודת גישה ישירה לבקשת API).

  3. בשדה כתובת ה-URL של בקשת ה-POST, מזינים את נקודת הקצה של ה-API עבור ה-DAP. אפשר להשתמש רק בנקודת קצה אחת לכל סביבה.

  4. באזור שיטת אימות, בוחרים אחת משיטות האימות הבאות:

    • אימות בסיסי. אם בוחרים באפשרות הזו, מזינים את שם המשתמש והסיסמה.

    • OAuth. פרוטוקול OAuth זמין רק כשמשתמשים ב-Salesforce. מידע נוסף זמין במאמר נקודת גישה ישירה ל-API – Salesforce REST API.

    • כותרת בהתאמה אישית: משתמש בכותרות HTTP לאימות. אם בוחרים באפשרות הזו, צריך לבצע את הפעולות הבאות:

      1. לוחצים על הוספת שדה. מופיעה תיבת הדו-שיח הוספת שדה.

      2. בשדה Field key (מפתח שדה), מזינים את השם של כותרת האימות.

      3. בשדה ערך השדה, מזינים את הערך של כותרת האימות.

      4. אופציונלי: מוסיפים כותרות נוספות.

      5. לוחצים על Save.

  5. באזור API request timeout, לוחצים על Expand more כדי לבחור את ערך הזמן הקצוב לתפוגה של בקשת ה-API בשניות. כדי לקבוע את משך הזמן האופטימלי להמתנה, כדאי לשקול את הדברים הבאים:

    • זמן ההמתנה האופטימלי לתפוגת בקשת API תלוי בחלקו בזמן התגובה של השרת. כלי כמו Postman יכול לעזור לכם לקבוע את זמן התגובה של השרת.

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

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

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

  6. באזור API request method (שיטת בקשת API), בהתאם לסוג הבקשה ששולחים, בוחרים באפשרות Post (פרסום) או Get (קבלת נתונים).

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

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

    https://example.com/api_dap?PARAMETER_NAME=+18005550100
    

    מחליפים את PARAMETER_NAME בשם של פרמטר מספר הטלפון.

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

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

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

    3. באזור Data records, מסמנים את תיבת הסימון כדי לכלול פרמטרים של נתונים בקובצי מטא-נתונים, פרמטרים של נתונים ברשומות CRM או את שניהם.

  10. באזור Push API response data to CRM (העברת נתוני תגובת ה-API למערכת CRM), מסמנים את תיבת הסימון כדי לעצב את נתוני תגובת ה-API כזוג של מפתח וערך, להשאיר את תגובת ה-API בפורמט JSON המקורי שלה או גם וגם.

  11. לוחצים על Save.

בדיקת ההגדרה

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

  1. עוברים אל הגדרה > הגדרות למפתחים > נקודת גישה ישירה לבקשת API.

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

  3. צופים בתגובה בפורמט JSON מה-API.

  4. אם הערך הוא null או שלא מתקבלות תוצאות, בודקים את הדברים הבאים:

    • האם החיבור מצביע על מסד נתונים עם הנתונים הנכונים?

    • האם מספר הטלפון משויך לאיש קשר?

    • האם פורמט מספר הטלפון נכון?

    • האם כותרת התגובה זהה בדיוק?

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

פרטים על הלוגיקה של API DAP

פלטפורמת CCAI משתמשת בלוגיקה של קבוצות כדי לנתב שיחות (ראו סדר ההתאמה והאינטראקציות של DAP). בנוסף, ממשקי API של DAPs יכולים לכלול מספר תנאים שמוערכים כדי לנתב שיחות. לכן, הסדר הספציפי שבו יוצרים הרשאות DAP ל-API הוא חשוב מאוד. אם יש לכם הרשאות גישה קיימות ל-API (DAP) ויש חפיפה ביניהן לבין הרשאות גישה חדשות ל-API שאתם יוצרים, יכול להיות שתצטרכו ליצור מחדש את הרשאות הגישה הקיימות ל-API בסדר חדש כדי להשיג את הניתוב הנדרש.

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

דוגמה נכונה: קודם תנאים מורכבים

פלטפורמת CCAI תתאים קודם את 1, אחר כך את 2 ואז את 3.

  1. ‫"brand = Generico" AND "Customer type = lead" AND "product = retail"

  2. ‫‎"brand = Generico" AND "Customer type = lead"‎

  3. ‪"brand = Generico"

דוגמה שגויה: קודם תנאים פשוטים

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

  1. ‪"brand = Generico"

  2. ‫‎"brand = Generico" AND "Customer type = lead"‎

  3. ‫"brand = Generico" AND "Customer type = lead" AND "product = retail"

דוגמה לפריסה של נקודת קצה ל-DAP API

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

מאגר GitHub נמצא כאן: https://github.com/GoogleCloudPlatform/ccaas-dap-api.

יצירת DAP

  1. חשוב לוודא שהשלמתם את כל התנאים המוקדמים הנדרשים לסוג ה-DAP שלכם. הוראות מפורטות זמינות בקטעים API DAP, support phone number DAP, או user segment DAP.

  2. עוברים אל הגדרות > תור.

  3. בוחרים את הערוץ (IVR, אינטרנט או נייד) ולוחצים על עריכה / הוספה.

  4. בוחרים את התור שאליו רוצים להוסיף את נקודת הגישה הישירה. בחלונית הגדרות, גוללים אל נקודת גישה ולוחצים על + יצירת נקודת גישה ישירה.

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

    1. מספר הטלפון של התמיכה

      • מספר טלפון לתמיכה: מזינים מספר טלפון שהוקצה לחשבון שלכם על ידי CCAI Platform, כולל קוד המדינה אם מדובר במספר בינלאומי. הפורמט הוא e164 ‏ (+[country_code][phone_number]) או SIP ‏ (sip:[number]@[domain]).
      • הודעת פתיחה: מזינים הודעה למשתמשי הקצה בשדה כדי שהיא תוקרא על ידי המרת טקסט לדיבור, או מעלים קובץ אודיו משלכם. כדי לדלג על הודעת הפתיחה, מזינים . בשדה או מעלים קובץ ריק.
    2. פלח משתמשים

      • שדה פלח משתמשים מותאם אישית ב-CRM: השם של שדה פלח המשתמשים במערכת ה-CRM. דוגמה: Tier
      • ערך מותאם אישית של פלח משתמשים ב-CRM: ערך של פלח משתמשים שיופנה לתור הזה. דוגמה. ‫"Gold Tier"
      • הודעת פתיחה: מזינים הודעה למשתמשי הקצה בשדה כדי שהיא תוקרא על ידי המרת טקסט לדיבור, או מעלים קובץ אודיו משלכם. כדי לדלג על הודעת הפתיחה, מזינים . בשדה או מעלים קובץ ריק.
    3. תשובת API

      • תגובת API: לוחצים על הוספת מפתח וערך. מזינים את זוגות המפתח והערך כפי שהוגדרו ב-API. חוזרים על הפעולה לכל קבוצה של צמדי מפתח וערך שנדרשים ל-DAP.
      • (אופציונלי) מספר טלפון לתמיכה: מספר טלפון שמוקצה על ידי CCAI Platform, שמשתמשי קצה יכולים להתקשר אליו כדי להגיע למוקד הטלפוני שלכם. המספר הזה נדרש להתאמה בנוסף לצמדי המפתח/ערך של תגובת ה-API.
      • הודעת פתיחה: מזינים הודעה למשתמשי הקצה בשדה כדי שהיא תוקרא על ידי המרת טקסט לדיבור, או מעלים קובץ אודיו משלכם. כדי לדלג על הודעת הפתיחה, מזינים . בשדה או מעלים קובץ ריק.
    4. כללי

      • תווית כללית של נקודת גישה: תווית שקל לזהות ומיועדת למפתחים לשימוש באפליקציה או ב-SDK.
    5. אפליקציה לנייד

      • אפליקציה לנייד: בוחרים את האפליקציה לנייד מהתפריט הנפתח.
  6. לוחצים על יצירה.

בדיקת ניתוב שיחות

  1. מתקשרים לערוץ באמצעות מספר טלפון או חשבון משתמש קצה עם פרמטרים שיודעים שאמורים להפעיל את ה-DAP.

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