სიახლეები და ანალიზი
მხარდაჭერის SLA: დროის ათვლისა და ესკალაციის წესები
მხარდაჭერის SLA-ის განსაზღვრა: პასუხისა და გადაწყვეტის მიზნები, სამუშაო საათები, კლიენტის პასუხის მოლოდინი, შიდა ვადები და დარღვევაზე რეაგირება.
ანგარიშში მხარდაჭერა სწრაფია, კლიენტი კი მაინც უკმაყოფილოა: ჯერ ავტომატური წერილი მივიდა, პრობლემა ინჟინრებს გადაეცა, შემდეგ ბილეთი რამდენიმე დღე „მოლოდინში“ იყო. სხვაობას დროის განსხვავებული განსაზღვრება შეიძლება ხსნიდეს. ათვლის დაწყების, შეჩერებისა და დასრულების წესების გარეშე SLA რიცხვია, რომელსაც ბილეთის ისტორიასთან ვერ შეამოწმებ.
HubSpot-ის SLA აღრიცხვის გზამკვლევი პირველ პასუხს, შემდგომ პასუხებს, გადაწყვეტის დროსა და გუნდის მოლოდინში გატარებულ დროს განასხვავებს. აღწერილ მოდელში ავტომატური მიღების დასტური პირველ პასუხად არ ითვლება. ეს საკუთარი განსაზღვრებების სასარგებლო საფუძველია, თუმცა ვალდებულებები, განრიგები და გამონაკლისები კლიენტთან შეთანხმებას უნდა ემთხვეოდეს.
ვადამდე მოვლენა განსაზღვრეთ
განვიხილოთ B2B სერვისი, რომელიც ჩვეულებრივ მოთხოვნებს სამუშაო საათებში ამუშავებს და კრიტიკულ ინციდენტებს ცალკე გზას უთმობს. „სწრაფად უპასუხე“ საკმარისი არ არის. განსაზღვრეთ საწყისი მოვლენა, საჭირო მოქმედება და ვადის კალენდარი.
პირველი პასუხის ათვლა შეიძლება მოთხოვნის მხარდაჭერილ არხში მოხვედრისას დაიწყოს. დასრულება შეიძლება თანამშრომლის შინაარსიან პასუხს ნიშნავდეს გადაწყვეტით ან გასაგები შემდეგი მოქმედებით. თუ AI პასუხობს, ცალკე გადაწყვიტეთ, როდის აკმაყოფილებს მისი შეტყობინება ვალდებულებას: მხოლოდ კითხვის გამეორებამ დრო მხოლოდ ტექსტის გაგზავნის გამო არ უნდა გააჩეროს.
გადაწყვეტას სხვა განსაზღვრება სჭირდება. ბილეთის დახურვა თანამშრომლის მიერ შეიძლება სერვისის დადასტურებულ აღდგენას არ ემთხვეოდეს. ჩაიწერეთ, რა ითვლება გადაწყვეტად, როგორ მოწმდება და რა ხდება ხელახლა გახსნისას. სხვაგვარად სხვადასხვა საფუძვლით დასრულებულ შემთხვევებს ადარებთ.
სამუშაო საათები გასულ დროს არ უდრის
აირჩიეთ სარტყელი, განრიგი, დღესასწაულები და არასამუშაო დროს მიღებული მოთხოვნების წესი. საილუსტრაციო მაგალითში მოთხოვნა პარასკევს საღამოს მოდის, მხარდაჭერა კი ორშაბათს ბრუნდება. სამუშაო საათების კალენდარში დროის ნაწილი მომდევნო ფანჯრის გახსნისას ითვლება; უწყვეტი SLA შაბათ-კვირასაც გრძელდება. სწორ მიდგომას ვალდებულება განსაზღვრავს.
კლიენტს ცალკეული თანამშრომლის განრიგს ავტომატურად ნუ მიუყენებთ. რამდენიმე ცვლა ერთ შეთანხმებულ მომსახურების პერიოდს შეიძლება ფარავდეს. განრიგის ცვლილებასაც ისტორია სჭირდება: ძველი შემთხვევების ახალი წესებით გადათვლამ პერიოდების შედარება შეიძლება შეცდომაში შემყვანი გახადოს.
ბილეთების, კლიენტებისა და პირობების დაკავშირებას CRM ინტეგრაცია სჭირდება. სერვისული ოპერაციების ქეისი როლებისა და მონაცემების კონტექსტს იძლევა; კონკრეტულ SLA-ს ან ამ სტატიის წესების დანერგვას არ ადასტურებს.
ყველა პაუზას მიზეზი სჭირდება
კლიენტის ინფორმაციის მოლოდინი ზოგი მეტრიკიდან შეიძლება გამოირიცხოს, თუ ეს მკაფიოდ შეთანხმებულია. მაგრამ ერთმა „მოლოდინის“ სტატუსმა კლიენტის დაკარგული ინფორმაცია, ინჟინრების სამუშაო და შიდა თანხმობის დაგვიანება არ უნდა გააერთიანოს. ამ მიზეზებს სხვადასხვა პასუხისმგებელი ჰყავს.
თითოეულ პაუზაზე ჩაიწერეთ საწყისი მოვლენა, საჭირო ინფორმაცია და განახლების პირობა. მაგალითად, თანამშრომელი შეკვეთის ნომერს ითხოვს; კლიენტის ახალი პასუხი ბილეთს აქტიურ რიგში აბრუნებს. შეამოწმეთ სხვა არხით მოსული პასუხი, რომლის შეტყობინებები მოგვიანებით გაერთიანდება. მარშრუტიზაციამ ინფორმაციის მოსვლის შემდეგ საათი შეჩერებული არ უნდა დატოვოს.
გუნდის მოლოდინის დროსთან ერთად აჩვენეთ გადაწყვეტამდე სრული გასული დრო. ასე პაუზა კლიენტის გამოცდილებას არ მალავს: შემთხვევა შიდა საზომს შეიძლება აკმაყოფილებდეს, გაგზავნიდან შედეგამდე კი რამდენიმე დღე დასჭირდეს.
ესკალაციამ სამუშაო უნდა გაანაწილოს
SLA მართვის გზამკვლევში HubSpot გარე ვალდებულებებს შიდა ოპერაციულ შეთანხმებებთან, OLA-ებთან აკავშირებს. ავტორები წინასწარ გადაცემების, განრიგებისა და მარშრუტიზაციის შეთანხმებას, შემდეგ კი დარღვევის გამოკვლევას გვირჩევენ. გამოქვეყნებული პროდუქტის წარმადობის რიცხვები სხვა გუნდის პროგნოზი არ არის; აქ მნიშვნელოვანი იდეა პასუხისმგებლობაა.
თუ ინჟინრების გამოკვლევა ხელმისაწვდომი დროის უმეტესობას მოიხმარს, ბოლო წუთს მენეჯერის შეტყობინება პროცესს ვერ გამოასწორებს. კლიენტის ვალდებულებიდან უკან იმუშავეთ: როდის უნდა მიიღონ ინჟინრებმა მოთხოვნა, ვინ იღებს მას და როდის უნდა დაინახოს მენეჯერმა რისკი? გაფრთხილება დარჩენილი მოქმედების შესაძლებლობის მიხედვით დააყენეთ.
ესკალაციამ განსაზღვრული წესით პასუხისმგებელი ან პრიორიტეტი უნდა შეცვალოს და ისტორია შეინარჩუნოს. შეამოწმეთ თავისუფალი თანამშრომლის არყოფნა, ცვლის დასრულება და რამდენიმე ერთდროული სასწრაფო შემთხვევა. ეს გადასვლები პროცესების ავტომატიზაციას ეკუთვნის და არა მხოლოდ შეტყობინების პარამეტრებს.
საუბარი და გაცნობის პროცესი დროის ათვლაზე მოქმედებს
ვადის შესრულებას შემდეგი ნაბიჯის ახსნა მაინც სჭირდება. უკონტექსტო კითხვამ ან პრობლემის გამეორების თხოვნამ შეიძლება კარგი პირველი პასუხის მეტრიკა და ცუდი გამოცდილება შექმნას. დროის საზომებთან ერთად AI მხარდაჭერის საუბრის დიზაინი შეაფასეთ.
ახალი კლიენტებიც გამოყავით. გაშვების შემდეგ განმეორებით კითხვებს შეიძლება უკეთესი გაცნობის პროცესი და განმეორებითი სარგებელი სჭირდებოდეს და არა უფრო მკაცრი SLA. მათი ინციდენტებთან შერევა დატვირთვის მიზეზებს აბუნდოვანებს.
წესები ბილეთის ისტორიასთან შეამოწმეთ
გაშვებამდე რამდენიმე სცენარი გაიარეთ: ჩვეულებრივი პასუხი, კლიენტის მოლოდინი, შაბათ-კვირა, პრიორიტეტის ზრდა, ინჟინრებზე გადაცემა და ხელახლა გახსნა. მოვლენები და მოსალოდნელი დროის შედეგები ხელით მონიშნეთ, შემდეგ სისტემას შეადარეთ. პრიორიტეტის შეცვლამ გასული დრო ჩუმად არ უნდა წაშალოს.
დარღვევისას აღდგენის მოქმედება დანიშნეთ და კლიენტს განახლებული მოლოდინი მიეცით. გუნდის განხილვაში მიზეზები გამოყავით: უპასუხისმგებლო რიგი, არასაკმარისი ხელმისაწვდომობა, განრიგის შეცდომა, რთული სამუშაო ან გამოტოვებული განახლება. გაუმჯობესება კონკრეტული მიზეზის მოგვარებაა და არა წესების შეცვლით უფრო ლამაზი შესრულების პროცენტის მიღება.