როგორ ავიცილოთ დუბლირებული ჯავშანი განმეორებითი AI ზარისას

მოკლე პასუხი: კალენდრის ჩანაწერს შეთანხმებული ვიზიტის სტაბილური გასაღები უნდა ჰქონდეს. გასაღების შექმნის შემდეგ შეამოწმეთ, ხომ არ არის იგივე ოპერაცია უკვე დაწყებული ან დასრულებული, და მხოლოდ ამის შემდეგ გაგზავნეთ შექმნის მოთხოვნა. თუ პასუხი დაიკარგა, სისტემა იმავე გასაღებით ამოწმებს არსებულ ჩანაწერს და აღმოჩენილ event ID-ს იყენებს.

როდის ჩნდება ერთი შეთანხმებიდან ორი კალენდრის ჩანაწერი?

ერთი შეთანხმებიდან ორი კალენდრის ჩანაწერი მაშინ ჩნდება, როცა პირველი მოთხოვნა კალენდარში სრულდება, მაგრამ ინტეგრაცია პასუხს ვერ იღებს და შექმნის მოთხოვნას იმეორებს. მომხმარებელმა ვიზიტი ერთხელ დაადასტურა, თუმცა ინტეგრაცია მეორე, გარეგნულად იდენტურ მოვლენას ქმნის. მომხმარებელს ორი შეხსენება მისდის, თანამშრომელმა კი უნდა დაადგინოს, რომელი ჩანაწერი დატოვოს.

ქვემოთ აღწერილი სასწავლო ცენტრი „მეორე საათი“, მისი თანამშრომლები, ზარები, ჯავშნები და ტექნიკური ჩანაწერები გამოგონილი სასწავლო მაგალითია. ცენტრი aiCALL-ის კლიენტი არ არის. სტატია არ აღწერს რეალურ ინტეგრაციას, დუბლირებული ჯავშნების გაზომილ შემცირებას ან დასრულებულ დანერგვას.

გამეორებისას მთავარი რისკი ოპერაციის იდენტობის დაკარგვაა. სატელეფონო პროვაიდერი ყოველ ცდას ზარის ცალკე ჩანაწერს ანიჭებს. განმეორებული ტექნიკური მოთხოვნის იმავე ბიზნესშეთანხმებასთან დასაკავშირებლად გუნდი სტაბილურ გასაღებს ადგენს და ინტეგრაციას ამ გასაღების შედარების წესს უმატებს.

aiCALL-ის ზარიდან კალენდრამდე პროცესის განხილვის მოთხოვნას დაურთეთ ჯავშნის ველები, კალენდრის სისტემა, ხელახალი ცდის წესები და რეალური ოპერატორის მიერ გამოყენებული დადასტურების ფრაზა.

რა არის ერთი შეთანხმებული ვიზიტის სტაბილური გასაღები?

გასაღებისთვის სატელეფონო ნომერს მომსახურება, სრული დრო და მდებარეობა დაამატეთ. ერთ ადამიანს სხვადასხვა დღეს რამდენიმე ვიზიტი შეიძლება ჰქონდეს, ხოლო ერთი და იგივე დრო სხვადასხვა მომსახურებისთვის ან ფილიალში შეიძლება იყოს ხელმისაწვდომი. ამ სტატიის სამუშაო ბარათში 4 ველია.

ველი	რატომ არის საჭირო	როდის არ უნდა შევიდეს გასაღებში
დადასტურებული საკონტაქტო ჩანაწერი	შეთანხმებას კონკრეტულ მოთხოვნასთან აკავშირებს	თუ ნომერი ან სხვა მონაცემი ჯერ არ არის გადამოწმებული
მომსახურების კოდი	ერთ დროს სხვადასხვა მომსახურებას განასხვავებს	თუ მომხმარებელმა მომსახურება ჯერ არ აირჩია
დაწყების სრული დრო	თარიღსა და დროს ერთ მნიშვნელობად ინახავს	თუ დრო ბუნდოვანია ან დროის სარტყელი უცნობია
მდებარეობის კოდი	ფილიალს ან ონლაინ არხს განსაზღვრავს	თუ ორგანიზაციას მხოლოდ ერთი უცვლელი ადგილი აქვს

გასაღები მხოლოდ დადასტურებული მნიშვნელობებიდან უნდა შეიქმნას. თუ მომხმარებელი არსებულ ვიზიტს გადაანიშნავს, ძველი მოვლენა დადასტურებული წესით განაახლეთ ან გააუქმეთ და ჟურნალში ძველ და ახალ ჩანაწერებს შორის კავშირი შეინახეთ. თუ მომხმარებელი დამატებით ვიზიტს მკაფიოდ ითხოვს, ცალკე ახალი მოვლენა შექმენით. დროის ან ფილიალის ცვლილებისას ჯერ სწორედ ეს განზრახვა დააზუსტეთ.

რატომ არ კმარა მხოლოდ CallSid-ის იდენტიფიკატორი?

CallSid-ის იდენტიფიკატორი მხოლოდ ზარის ცალკე მცდელობას განსაზღვრავს, ამიტომ განმეორებით ზარებში შეთანხმებული ერთი ბიზნესოპერაციის დასაკავშირებლად სხვა სტაბილური გასაღებია საჭირო. Twilio-ს ოფიციალური Call resource-ის დოკუმენტაცია თითოეულ ზარს უნიკალურ CallSid-ს ანიჭებს. ამ იდენტიფიკატორით გუნდი კონკრეტული ზარის მცდელობას აკვირდება. ხელახალი ზარი ახალ იდენტიფიკატორს მიიღებს, ამიტომ გუნდი მხოლოდ CallSid-ით ვერ ადგენს, რომ ორ ზარში ერთი და იგივე ვიზიტი შეთანხმდა.

პრაქტიკული გასაღები ბიზნესშეთანხმების სტაბილური ველებიდან უნდა წარმოიქმნას. მის გვერდით შეინახეთ პირველი ზარისთვის მინიჭებული CallSid-ი, შემდგომი მცდელობების იდენტიფიკატორები და კალენდრის მოვლენის იდენტიფიკატორი. ასე ჩანს როგორც ბიზნესოპერაცია, ისე მისი ტექნიკური ისტორია.

Google Calendar-ის ოფიციალური მოვლენის შექმნის სახელმძღვანელო განმარტავს, რომ კლიენტს საკუთარი event ID-ის მითითება შეუძლია. დოკუმენტაციის მიხედვით, ასეთი იდენტიფიკატორი ადგილობრივ მონაცემსა და კალენდრის მოვლენას სინქრონულად აკავშირებს და ხელს უშლის დუბლირებული მოვლენის შექმნას, თუ სერვერზე წარმატებული ოპერაციის შემდეგ პასუხი დაიკარგა. მოვლენის ეს იდენტიფიკატორი შექმნის დროს უნდა მიეთითოს; მოგვიანებით მისი შეცვლა ვერ ხერხდება.

Google-ის მიერ აღწერილ შემთხვევაში კლიენტის event ID-ის მითითებით დუბლირებული მოვლენის თავიდან აცილებაა შესაძლებელი. aiCALL-ში მისი ავტომატური დანერგვა ამ წყაროთი დაუდასტურებელია. გასაღების ფორმატი, კალენდრის უფლებები, შეცდომების დამუშავება და არსებული ჩანაწერის ძიება თითოეულ ინტეგრაციაში ცალკე უნდა შემოწმდეს.

რა განსხვავებაა განმეორებულ გასაღებსა და დაკავებულ დროს შორის?

განმეორებული გასაღები ერთი შეთანხმების შესაძლო განმეორებას მიუთითებს, ხოლო დაკავებული დრო სხვა მომხმარებლის ნამდვილ ჯავშანსაც შეიძლება ეკუთვნოდეს. გუნდმა ეს ორი სიგნალი ცალ-ცალკე უნდა შეამოწმოს.

1. თუ იგივე გასაღები უკვე წარმატებულ მოვლენას უკავშირდება, დააბრუნეთ არსებული ჩანაწერი და ახალი მოვლენის შექმნა გამოტოვეთ.
2. თუ იგივე გასაღების ოპერაცია ჯერ მიმდინარეობს, სისტემამ განმეორებითი მოთხოვნა უნდა შეაჩეროს და მიმდინარე ოპერაციის დასრულებას დაელოდოს, ან მოთხოვნა უსაფრთხო შემოწმების რიგში გადაიტანოს.
3. თუ გასაღები ახალია, მაგრამ დრო დაკავებულია, შესთავაზეთ მხოლოდ რეალურად თავისუფალი დრო და დადასტურება კალენდრის წარმატებული პასუხის შემდეგ გააჟღერეთ.
4. თუ კალენდრის პასუხი გაურკვეველია, შედეგი ადამიანმა უნდა შეამოწმოს და მეორე მოვლენის შექმნა დაბლოკოს.

ხმოვანი პასუხიც მონაცემთა მდგომარეობას უნდა ემთხვეოდეს. ფრაზა „ჩაგწერეთ“ მხოლოდ წარმატებით ნაპოვნი ან შექმნილი მოვლენის შემდეგ გამოიყენეთ. მიმდინარე ან გაურკვეველი ოპერაციისას თქვით, რომ მოთხოვნა მოწმდება და დაასახელეთ რეალური შემდგომი მოქმედება.

როგორ ჩავატაროთ განმეორებითი მოთხოვნის ტესტი?

განმეორების მიმართ მდგრადობა 5 განსხვავებული შემთხვევით შეამოწმეთ.

• ზუსტად იგივე მოთხოვნა კალენდრის წარმატებული პასუხის შემდეგ;
• იგივე მოთხოვნა მაშინ, როცა წარმატებული პასუხი ინტეგრაციამდე არ დაბრუნდა;
• ახალი ზარი ახალი CallSid-ით, მაგრამ უცვლელი შეთანხმების ველებით;
• შეცვლილი დრო, რომელიც არსებული ვიზიტის გადატანად მუშავდება, და მკაფიოდ მოთხოვნილი ცალკე ახალი ვიზიტი;
• ერთდროულად მიღებული ორი მოთხოვნა ერთი და იმავე გასაღებით.

თითო შემთხვევისთვის წინასწარ ჩაწერეთ მოსალოდნელი კალენდრის მოვლენების რაოდენობა, დაბრუნებული მოვლენის იდენტიფიკატორი, ჟურნალის სტატუსი და მომხმარებლისთვის სათქმელი პასუხი. ტესტი ჩავარდნილია, თუ უცვლელი შეთანხმება მეორე მოვლენას ქმნის, არსებული ვიზიტის გადატანა ძველ მოვლენას დადასტურებული წესით არ აახლებს ან არ აუქმებს, ცალკე დადასტურებული ახალი ვიზიტი ძველ მოვლენას უკავშირდება, ან გაურკვეველი პასუხი წარმატებად ცხადდება.

სად არის ავტომატური გაუქმებისა და ხელით შემოწმების ზღვარი?

ავტომატური გაუქმება დასაშვებია მხოლოდ მაშინ, როცა გუნდი იმავე სტაბილური გასაღებით შექმნილ ზედმეტ ჩანაწერს ერთმნიშვნელოვნად ადასტურებს; გაურკვეველი გასაღები, დაკარგული პასუხი ან შესაძლო ნამდვილი ჯავშანი ხელით უნდა შემოწმდეს. დაუდასტურებელმა წაშლამ შეიძლება ნამდვილ ჯავშანს შეეხოს, როცა კალენდარში მოვლენა შეიქმნა, მაგრამ ადგილობრივ ჟურნალში პასუხი ვერ ჩაიწერა. ოპერაციისთვის წინასწარ განსაზღვრეთ 3 მდგომარეობა: მიმდინარეობს, დასრულებულია და ხელით შესამოწმებელია.

ინტეგრაციის პროცესმა მიმდინარე მდგომარეობისას ახალი მოვლენის შექმნა დროებით უნდა შეაჩეროს. დასრულებული მდგომარეობისას მან იმავე გასაღებისთვის მოვლენის არსებული იდენტიფიკატორი უნდა დააბრუნოს. ხელით შესამოწმებელი მდგომარეობისას პროცესი მომხმარებლისთვის ავტომატური დადასტურების გაგზავნას აჩერებს და პასუხისმგებელ პირს ზარის, გასაღების, მოთხოვნისა და კალენდრის პასუხის სრულ ისტორიას აწვდის.

სტატია არ ამტკიცებს, რომ ეს მდგომარეობები უკვე ჩაშენებულია aiCALL-ში ან კონკრეტულ კალენდართან გამართულად მუშაობს. წარმოდგენილი სქემა არის დანერგვისა და მიღების ტესტის მოთხოვნა.

როგორ შევამოწმეთ ტექნიკური საზღვრები?

Google Calendar-ის პირველწყაროში გადავამოწმეთ კლიენტის მიერ event ID-ის შექმნისა და დუბლირებული მოვლენის თავიდან აცილების აღწერილი შემთხვევა. Twilio-ს პირველწყაროში გადავამოწმეთ, რომ CallSid-ი კონკრეტული ზარის უნიკალური იდენტიფიკატორია. ამ წყაროებში სასწავლო ცენტრის, მატრიცის ან aiCALL-ის რეალური შედეგის მტკიცებულება არ არის. საძიებო მოთხოვნის მოცულობა, პოზიცია და მომავალი ლიდები უცნობია.

შემდეგი პრაქტიკული საკითხები:

• როგორ დავაწესოთ ხელახალი ცდის წესი busy და no-answer ზარებისთვის
• როგორ გავარჩიოთ ხმოვანი ფოსტა და ადამიანთან დასრულებული საუბარი
• როგორ დააზუსტოს ხმოვანმა ბოტმა ბუნდოვანი ქართული თარიღი

რა კითხვები ჩნდება დუბლირებული ჯავშნის თავიდან აცილებისას?

დუბლირებული ჯავშნის თავიდან აცილებისას კითხვები სტაბილური გასაღების შემადგენლობას, ხელახალი ცდის ზღვარსა და არსებული მოვლენის შემოწმებას ეხება.

ერთი ნომერი ყოველთვის ერთ ჯავშანს ნიშნავს?

არა. ერთ ადამიანს რამდენიმე ვიზიტი შეიძლება ჰქონდეს. სტაბილურ გასაღებში უნდა შევიდეს შეთანხმების სხვა დადასტურებული ველებიც.

რატომ ვერ ვიყენებთ მხოლოდ CallSid-ს?

რადგან იგი ზარის კონკრეტულ მცდელობას აღნიშნავს. ხელახალი ზარი სხვა CallSid-ს მიიღებს, მიუხედავად იმისა, რომ მომხმარებელმა იგივე ვიზიტი დაადასტურა.

მოვლენის საკუთარი იდენტიფიკატორი ავტომატურად აგვარებს ყველა დუბლს?

იგი შეცდომის აღწერილ სცენარში დუბლირებული მოვლენის შექმნას ხელს უშლის, მაგრამ სწორ ბიზნესგასაღებს, ერთდროულ მოთხოვნებს, ცვლილებებსა და კალენდრის კონფლიქტებს ცალკე მართვა სჭირდება.

როდის შეიძლება ბოტმა თქვას, რომ ჯავშანი დადასტურდა?

მხოლოდ მაშინ, როცა ინტეგრაციამ არსებული ან ახლად შექმნილი მოვლენა სანდოდ იპოვა და საბოლოო დრო მომხმარებლის დადასტურებულ პასუხს ემთხვევა.