როგორ ავაშენოთ დახმარების ცენტრის ბილეთების სისტემა: ბილეთები, სტატუსები, მინიჭება და ელფოსტა

დახმარების ცენტრის ბილეთების სისტემა გარდაქმნის მიმოფანტულ მოთხოვნებს — ელფოსტებს, შეტყობინებებს, „სწრაფ კითხვებს“ დერეფანში — ბილეთებად: თითო პრობლემა ერთ ჩანაწერად, პატრონით, სტატუსით, პრიორიტეტით და მთელი საუბრით. ასაშენებლად გჭირდებათ ბილეთის შექმნის გზა, საერთო რიგი ფილტრებით, მინიჭება, ძაფი, რომელიც საჯარო პასუხებსა და შიდა შენიშვნებს ერთმანეთისგან ჰყოფს, და შეტყობინებები, რომ არავინ დარჩეს უპასუხოდ. AI აპის შემქმნელს ერთი შუადღის განმავლობაში შეუძლია კარგი პირველი ვერსიის აშენება შიდა IT, HR ან ობიექტების მოთხოვნების ცენტრისთვის. მომხმარებელზე ორიენტირებული მხარდაჭერა ელფოსტის ძაფებით, რეაგირების ვადებითა და ანგარიშებით უფრო დიდ ყურადღებას მოითხოვს — და სწორედ აქ იმსახურებენ დადგენილი დახმარების პროდუქტები თავიანთ საფასურს.

რა სჭირდება სისტემას

მონაცემები

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

გვერდები

• მომთხოვნი: „მოთხოვნის გაგზავნის“ ფორმა კატეგორიითა და დანართებით, „ჩემი მოთხოვნები“ სია და ყოველი ბილეთის ძაფი.
• აგენტი: რიგი (ჩემი ბილეთები, მინიჭებელი, ყველა ღია), ფილტრები და ძიება, ბილეთის ხედი პასუხის, შენიშვნის, სტატუსის, პრიორიტეტისა და პასუხისმგებლის მართვის ღილაკებით.
• ადმინი: კატეგორიები, გუნდები, აგენტები, მზა პასუხები და მარტივი ანგარიში.

წვდომა

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

გადაწყვეტილებები და კომპრომისები

ფორმა, ელფოსტა თუ ორივე

ვებფორმა ყველაზე მარტივია და სუფთა მონაცემებს იძლევა: კატეგორია, პრიორიტეტი და სავალდებულო ველები. ელფოსტით მიღება — ადამიანები წერენ support@-ზე და ბილეთი ჩნდება — ის არის, რასაც მომხმარებლები ელიან, მაგრამ საჭიროებს ელფოსტის მომწოდებელს, რომელსაც შეუძლია წერილების მიღება და აპში გადაგზავნა, პლუს ძაფებს, რომ პასუხები სწორ ბილეთს მიებას (ჩვეულებრივ, ბილეთის ნომერი თემაში ან უნიკალური პასუხის მისამართი). დაიწყეთ ფორმით; ელფოსტა დაამატეთ მას შემდეგ, რაც სამუშაო ნაკადი დამტკიცდება. ელფოსტის გაგზავნა აპიდან გამავალ ნაწილს აშუქებს.

მინიჭება

ვარიანტებია: აგენტები არამინიჭებული რიგიდან ირჩევენ; თანმიმდევრობით (round-robin) გუნდის შიგნით; ან კატეგორიის მიხედვით. რიგიდან არჩევა პატარა გუნდებისთვის მუშაობს. ავტომატური მინიჭება მაშინ ეხმარება, როცა ბილეთები პატრონის გარეშე რჩება.

პრიორიტეტები და რეაგირების ვადები

განსაზღვრეთ ორი ან სამი პრიორიტეტი, თითოეულს პირველი პასუხის ვადით („სასწრაფო: 1 საათი, ჩვეულებრივი: 1 სამუშაო დღე“). ყოველ ბილეთზე დარჩენილი დროის ჩვენება უფრო სასარგებლოა, ვიდრე თვიური ანგარიში, რომელსაც ვერავინ კითხულობს. სამუშაო საათები ამას ართულებს — ადრე გადაწყვიტეთ, ითვლება თუ არა ღამე და შაბათ-კვირა.

შერწყმა და დუბლიკატები

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

მაგალითი პირველი მოთხოვნისთვის

ააშენე შიდა IT დახმარების ცენტრი 60-კაციანი კომპანიისთვის. თანამშრომლები აგზავნიან მოთხოვნებს ფორმით: თემა, კატეგორია (ტექნიკა, პროგრამა, წვდომა, ქსელი, სხვა), პრიორიტეტი (დაბალი, ჩვეულებრივი, სასწრაფო), აღწერა და დანართები. თითო ბილეთს აქვს ნომერი და სტატუსები: ახალი, ღია, ელის მომთხოვნს, გადაწყვეტილი, დახურული. IT აგენტებს აქვთ რიგი ჩანართებით: არამინიჭებული, ჩემი და ყველა ღია, ფილტრები კატეგორიით, პრიორიტეტით და სტატუსით, და ძიება. ბილეთის გვერდი აჩვენებს ძაფს საჯარო პასუხებითა და შიდა შენიშვნებით მკაფიოდ გაყოფილი; თანამშრომლები არასდროს ხედავენ შიდა შენიშვნებს. აგენტებს შეუძლიათ მინიჭება, სტატუსისა და პრიორიტეტის შეცვლა, მზა პასუხების გამოყენება და დუბლიკატების შერწყმა. აკონტროლე პირველი პასუხისა და გადაწყვეტის დრო და აჩვენე ყოველ ბილეთზე ბოლო განახლებიდან გასული დრო. თანამშრომლებს აქვთ გვერდი „ჩემი მოთხოვნები“. როლები: თანამშრომელი, აგენტი, ადმინი. ყველაფერი შეინახე მონაცემთა ბაზაში. მარტივი, მკვრივი, სწრაფი ინტერფეისი — სიჩქარე დეკორაციაზე მეტად.

ასაშენებელი ეტაპები

1. ბილეთის მოდელი და ფორმა. გაგზავნა, სია, ბილეთის გახსნა, პასუხი.
2. რიგი და ფილტრები. არამინიჭებული, ჩემი, ყველა ღია; ფილტრი და ძიება; დალაგება პრიორიტეტითა და ასაკით.
3. როლები და შესვლა. მომთხოვნი, აგენტი, ადმინი — შიდა შენიშვნები სერვერზე იმალება მომთხოვნისგან.
4. მინიჭების, სტატუსისა და პრიორიტეტის მართვა, აქტივობის ჟურნალით ყოველი ცვლილებისთვის.
5. შეტყობინებები. მომთხოვნს ელფოსტა საჯარო პასუხებზე, აგენტს — ახალ მინიჭებებზე, თქვენი ელფოსტის მომწოდებლით.
6. მზა პასუხები და შერწყმა.
7. რეაგირების ვადები და მარტივი ანგარიში: ღია ბილეთები ასაკის მიხედვით, პირველი პასუხის დრო, ბილეთები კატეგორიის მიხედვით.
8. ელფოსტით მიღება, როცა დანარჩენი მუშაობს, ძაფების კარგად შემოწმებით.
9. პილოტი ერთი გუნდით ორი კვირის განმავლობაში, სანამ ყველას გადაიყვანთ.

გავრცელებული შეცდომები

• შიდა შენიშვნები, რომლებიც მომთხოვნებს ჩანს, იმიტომ, რომ მხოლოდ ინტერფეისში იყო დამალული.
• ზედმეტად ბევრი სტატუსი და კატეგორია. აგენტები პირველს ირჩევენ, რომელიც ახლოს ჩანს. დაიწყეთ მაქსიმუმ ხუთი ყოველი ტიპისთვის.
• დროის ნიშნების არქონა პირველი პასუხისა და გადაწყვეტისთვის. რიცხვები დაგჭირდებათ იმ დღეს, როცა ვინმე იკითხავს „უფრო სწრაფები ვართ?“
• ელფოსტის პასუხები ქმნიან ახალ ბილეთებს ძაფების ნაცვლად. გამოსცადეთ პასუხი ტელეფონის ელფოსტის აპიდან, რომელიც ხშირად თემას ცვლის.
• ყველა მინიჭებულია, მაგრამ არავინ პასუხობს. ერთი პასუხისმგებელი ბილეთზე; დანარჩენებისთვის გამოიყენეთ თვალყურის მიმდევრები (watchers).
• დანართები საჯარო URL-ებით. შეცდომის შეტყობინების ეკრანის ანაბეჭდები ხშირად კერძო მონაცემებს შეიცავს. შეინახეთ ფაილები პირადად და მიაწოდეთ მხოლოდ მათ, ვისაც ბილეთის ნახვა შეუძლია.

როდის სჯობს მზა პროდუქტი

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

საკუთარი აშენება ერგება შიდა მოთხოვნების ცენტრებს (IT, HR, ობიექტები, ფინანსური მოთხოვნები), ნიშურ სამუშაო ნაკადებს, სადაც ბილეთი სინამდვილეში დავალებაა კონკრეტული ნაბიჯებით, და გუნდებს, რომლებსაც მოთხოვნები სხვა მონაცემებთან აქვთ დაკავშირებული. ის ასევე თავიდან აცილებს აგენტზე დაფუძნებულ ფასს, როცა ბევრი ადამიანი დროდადრო ამუშავებს ბილეთებს. უფრო ფართოდ, შიდა ინსტრუმენტების კატეგორიაზე იხილეთ შიდა ინსტრუმენტის გზამკვლევი.

როგორ ავაშენოთ Mythex-ით

Mythex-ში აღწერთ დახმარების ცენტრს ჩატში, ამოწმებთ ცოცხალ გადახედვაში და აქვეყნებთ თქვენი გუნდისთვის. ბილეთები ინახება Postgres მონაცემთა ბაზაში, რომელსაც აგენტი ამატებს, როცა მონაცემების შენახვა გჭირდებათ, ხოლო დანართები მიდის პროექტის ფაილების საცავში. მომთხოვნებისა და აგენტების შესვლა და ყველა ელფოსტა შემომავალი და გამავალი თქვენი მომწოდებლებით მუშაობს — Mythex-ს არ აქვს ჩაშენებული ბოლო მომხმარებლის შესვლის ან ელფოსტის პროდუქტი; მიდგომა ნაჩვენებია ელფოსტის გაგზავნის რეცეპტში. გუნდის წევრებს შეუძლიათ აპის შექმნაში დახმარება საერთო სამუშაო სივრცით, Mythex-ზე მომხმარებლის ფასის გარეშე.

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

კითხვები