მხარდაჭერის სამსახური & ტიკეტები
ჩანაწერი შიდა შენიშვნად ხვდება ტიკეტში, რომელსაც თანამშრომელი უკვე უყურებს — და არა ახალ, არავის მოთხოვნილ საქმედ.
1. კითხვა, რომელსაც ფუნქციამ ჯერ უნდა უპასუხოს
რომელ ტიკეტს?
ყველა იდენტიფიცირებულ სესიაზე ტიკეტის შექმნა სპამი იქნებოდა: გუნდი არავის გახსნილ საქმეებს იპოვიდა. იმ ადამიანის ყველა ძველ ტიკეტზე შენიშვნის დამატებაც სპამია, ოღონდ ნელი.
ამიტომ: შიდა შენიშვნა გამომგზავნის უახლეს ღია ტიკეტზე. თუ ღია ტიკეტი არ არის, არაფერი ხდება. ასე კლიენტის არდაწყებულ საქმეს არ ვქმნით და თანამშრომელი ჩანაწერს სწორედ იქ პოულობს, სადაც უკვე უყურებს.
შიდაა, არასდროს საჯარო. ბმული MousePlayer-ში მიდის. კლიენტმა ის არ უნდა ნახოს და მაინც ვერ გახსნიდა.
2. Zendesk Support და Freshdesk
ორივეს მხარს ვუჭერთ; ერთ საქმეს განსხვავებულად აკეთებს. ამაზე ფიქრი არ გჭირდებათ, მაგრამ ხსნის, რატომ ითხოვს ფორმა ცოტა განსხვავებულ მონაცემებს.
| Zendesk Support | Freshdesk | |
|---|---|---|
| ქვედომენი | acme acme.zendesk.com-იდან | acme acme.freshdesk.com-იდან |
| თანამშრომლის ელფოსტა | საჭიროა — Zendesk შედის ასე: email/token | არ სჭირდება, ცარიელი დატოვეთ |
| API ტოკენი | ადმინისტრირების ცენტრი → აპები და ინტეგრაციები → API-ები | თქვენი პროფილის პარამეტრები |
| შენიშვნა ხდება | შიდა კომენტარი ტიკეტზე | პირადი შენიშვნა ტიკეტზე |
თუ უფრო მარტივია, ქვედომენის ველში მთელი URL ჩასვით — საჭირო ნაწილამდე ვამოკლებთ, ამიტომ https://acme.zendesk.com/agent/tickets/1 იქცევა მნიშვნელობად acme.
3. როდის ირთვება
სესიის იდენტიფიცირების მომენტში — როცა საიტი იძახებს MousePlayer.setUserId(), ანალიტიკის ხიდი distinct ID-ს კითხულობს ან სერვერი identify ენდპოინტს იძახებს.
მხოლოდ ელფოსტით
ტიკეტი გამომგზავნს ეკუთვნის, მხარდაჭერის სისტემა კი მას ელფოსტით იცნობს. ხელშეკრულების ნომერი ვერაფერს იპოვის, ამიტომ არაფერი იგზავნება.
მხოლოდ ღია ტიკეტებისთვის
გადაწყვეტილი და დახურული ტიკეტები გამოტოვებულია. აღარავინ ნახულობს და შენიშვნა ვერავის ეხმარება; უმიზეზოდ თანამშრომლებს დახურულ საქმეს დაუბრუნებდა.
თუ გამომგზავნს ღია ტიკეტი არ აქვს, შესრულებულად ითვლება და არა ჩავარდნილად — ეს ჩვეულებრივი შემთხვევაა და ხელახალი ცდა ვერაფერს შეცვლიდა.
4. რას ხედავს თანამშრომელი
ერთი შიდა შენიშვნა: MousePlayer: სესიის ჩანაწერი <email>-ისგან შემდეგ ბმულით. ერთი დაწკაპუნება და ხედავს, რა გააკეთა ადამიანმა, ზუსტად მისი წერილის გვერდით.
სად ამართლებს თავს
- ტიკეტები „არ მუშაობს“. ჩანაწერი ოც წამში ჩვეულებრივ აჩვენებს იმას, რასაც ელფოსტის სამი გაცვლა ვერ აჩვენებდა.
- გამეორების ნაბიჯები, რომლებსაც ვერავინ იმეორებს. აღარ გჭირდებათ — სესია გაქვთ.
- გაბრაზებული და უშედეგო დაწკაპუნებები, რომლებსაც კლიენტი არ ახსენებს, რადგან ჰგონია, პროდუქტი ასე მუშაობს.
ტოკენი ჩვენს სერვერს არასდროს ტოვებს
ინახება AES-256-GCM-ით დაშიფრულად, შენახვის შემდეგ აღარ ჩანს და დავალების შიდა რიგში განზრახ არ ხვდება.
5. Help Scout, Front და Gorgias
კიდევ სამი სისტემა. სამივე ღია საუბარზე შიდა შენიშვნას ამატებს და სამივე განსხვავებულად აღწევს ამას.
| რას აწვდით | ქვედომენი | |
|---|---|---|
| Help Scout | შიდა აპის კლიენტის ID და საიდუმლო | არ სჭირდება |
| Front | API ტოკენი და გუნდის წევრის ID | არ სჭირდება |
| Gorgias | თანამშრომლის ელფოსტა და API გასაღები | საჭიროა |
Help Scout საუბრამდე ცვლის
კლიენტის საიდუმლოს პირდაპირ არ იღებს. ხიდი მას ჯერ მოკლევადიან წვდომის ტოკენში ცვლის — client credentials პროცესი ინტეგრაციისთვის, რომელიც საკუთარი სახელით მოქმედებს და არა მომხმარებლის. ტოკენი თავისი ვადის განმავლობაში მეხსიერებაშია; საიდუმლო ბაზაში რჩება.
Front-ის კომენტარს ავტორი სჭირდება
Front-ში კომენტარი გუნდის წევრის სახელით ჩანს და API მას მოითხოვს. აქ თანამშრომლის ველი ამას ინახავს — არა შესვლის მონაცემს, მხოლოდ ID-ს, რომლის სახელითაც შენიშვნაა.
Gorgias-ს ერთის ნაცვლად ორი კითხვა სჭირდება
მისი ტიკეტების სია იფილტრება მხოლოდ customer_id მნიშვნელობით — ელფოსტის ფილტრი არ არის. ამიტომ ხიდი ჯერ კლიენტს ეძებს და მერე მის ტიკეტებს ითხოვს. სტატუსითაც ვერ ფილტრავს, ამიტომ ღია ტიკეტი ჩვენს მხარეს ირჩევა, როგორც Freshdesk-ისთვის.
აქ დასახელებული ყველა სავაჭრო ნიშანი შესაბამის მფლობელს ეკუთვნის. MousePlayer-ს ამ პროვაიდერებთან საქმიანი კავშირი არ აქვს.