מערכת IVR מודולרית בפיתוח - מחפש פידבק טכני [באישור ההנהלה]

משרדי

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

nigun

@משרדי
אצלי נשאר מחובר
ולא בחרתי זכור אותי

telekesher

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

מטעמים

@telekesher כתב במערכת IVR מודולרית בפיתוח - מחפש פידבק טכני [באישור ההנהלה]:

נוחות השימוש בממשק

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

הערה קטנה:
ניסיתי לבצע שינוי בעץ, העברת שלוחה למיקום אחר, ולא הצלחתי לבטל (לא מצאתי כפתור "בטל" וגם לחיצה על ctrl+z לא הועילה). הייתי צריך לגזור שוב ולחפש את המקום ממנו גזרתי ולהדביק שם.

שאפו על האתר.

telekesher

@Shmuel754 כתב במערכת IVR מודולרית בפיתוח - מחפש פידבק טכני [באישור ההנהלה]:

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

זה מה שנדרש לפי וועדת הרבנים לענייני תקשורת

יגעתי ומצאתי

@telekesher
יפה מאוד!
אהבתי מאוד את הרעיון של העץ תיקיות (מה שהצעתי בעבר לימות...)
__
כמה הצעות לשיפור (אולי אוסיף עוד בהמשך):

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

עלה והצלח!

meir lamdan

@יגעתי-ומצאתי כתב במערכת IVR מודולרית בפיתוח - מחפש פידבק טכני [באישור ההנהלה]:

לעשות אפשרות ליצירת כמות שלוחות בבת אחת תחת שלוחה מסויימת.

קיים כבר כזה אפשרות

telekesher

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

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

הגדרה ראשונית: מערך פעולות בסיסי שמוגדר בשלוחה מראש באתר (בעיקרון עם json אבל אפשר גם עם UI יותר ידודתי)
הרחבה דינמית: השרת יכול להוסיף פעולות חדשות בזמן ריצה

בהגדרה הראשונית צריך להגדיר מה הפעולה הראשונה שיבצע (עדיף לכאורה מאשר שיבחר באופן אוטומטי את הפעולה הראשונה במערך)

היתרונות המשמעותיים:

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

סוגי פעולות בסיסיות

play_and_get_digits: השמעת הודעה וקבלת קלט
playback: השמעת הודעה
curl: שליחת בקשה ל-API
hangup: ניתוק השיחה

בהמשך כנראה נוסיף פעולות כמו הקלטה או העברה למודל API אחר וכדו'

מבנה הפעולות

כל פעולה במערך מוגדרת עם:

{
  "uuid": "שם_ייחודי",
  "type": "סוג_הפעולה",
  "next_action": "הפעולה_הבאה",
  // או
  "conditional_map": {
    "תנאי": "פעולה_הבאה"
  }
}

בפעולת curl יש מפתח מיוחד:

{
  "type": "curl",
  "curl_command": "...",
  "next_action_on_error": "הפעולה_במקרה_שגיאה"
}

משתנים דינמיים

שמירת משתנים: "save_variable": "שם_המשתנה"
שימוש במשתנים: {{שם_המשתנה}}
משתנה מובנה: {{user}} - מזהה שיחה ייחודי

דוגמה מלאה: אימות PIN

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

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

הנה ההגדרה הראשונית שתוגדר בממשק שמממש את התהליך הזה:

{
  "first_action": "get_pin",
  "actions": [
    {
      "uuid": "get_pin",
      "type": "play_and_get_digits",
      "audio_files": ["enter_pin.wav"],
      "min_digits": 3,
      "max_digits": 3,
      "tries": 3,
      "timeout": 5000,
      "terminator_key": "#",
      "regex_pattern": "\\d+",
      "save_variable": "pin",
      "conditional_map": {
        "no_input": "fail",
        "default": "verify_pin"
      }
    },
    {
      "uuid": "verify_pin",
      "type": "curl",
      "curl_command": "https://server1.dev/verify?pin={{pin}}",
      "next_action_on_error": "fail"
    }
  ]
}

דוגמאות לתשובות שרת

תשובה תקינה - הוספת פעולות חדשות:

{
  "next_action": "play_pin",
  "new_actions": [
    {
      "uuid": "play_pin",
      "type": "playback",
      "audio_files": [
        "you_entered.wav",
        "digits/1.wav",
        "digits/2.wav",
        "digits/3.wav"
      ],
      "next_action": "get_confirmation"
    },
    {
      "uuid": "get_confirmation",
      "type": "play_and_get_digits",
      "audio_files": ["confirm.wav"],
      "min_digits": 1,
      "max_digits": 1,
      "tries": 3,
      "timeout": 5000,
      "terminator_key": "#",
      "regex_pattern": "[12]",
      "conditional_map": {
        "1": "confirm_pin",
        "2": "get_pin",
        "no_input": "fail"
      }
    }
  ]
}

תשובת שגיאה - חזרה למצב קודם:

{
  "next_action": "invalid_pin",
  "new_actions": [
    {
      "uuid": "invalid_pin",
      "type": "playback",
      "audio_files": ["invalid_pin.wav"],
      "next_action": "get_pin"
    }
  ]
}

נשמח לשמוע מכם:

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

יאנג בוי

@telekesher
מבחינת פעולות, כל עוד אפשר לעשות את כל מה שאפשר במודול API של ימות, מבחינתי זה רק שדרוגים.
כן דבר שמאוד חשוב לי, הוא שליחת data של קובץ להשמעה חד פעמית.
שיהיה חלק מתשובת השרת, יושמע למאזין ולא ישמר במערכת.
משהו שקיים מאוד חלקי ולא מאובטח בימות המשיח (מאגר ציבורי שיש להעלות אליו קבצים מראש, ומי שרואה את הנתיב לקובץ בלוג של שלוחת הAPI במערכת שלו, יכול להשתמש בו)
תודה רבה!

עריכה:
אשמח ג"כ לדעת מה העלויות הצפויות (אם בכלל) אבל פחות בוער להרגע כמובן.

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

יאנג בוי

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

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

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

תודה ובהצלחה!

telekesher

@יאנג-בוי אתה יכול לשים איזה ערכים שאתה רוצה בבקשה לשרת

יאנג בוי