Bir çox dəstək komandası şablonlara güvənir.
Düzünü desəm, güvənməlidirlər də.
Hər gün oxşar suallara cavab verəndə hər şeyi sıfırdan yazmaq məntiqli deyil. Müştərilər lisenziyalar, geri ödənişlər, yeniləmələr, quraşdırma, inteqrasiyalar, ödənişlər, uyğunluq və tez-tez rast gəlinən xətalar haqqında soruşur. Yaxşı bir hazır cavab (saved reply) vaxta qənaət edə, səhvləri azalda və komandanın ardıcıl qalmasına kömək edə bilər.
Amma elə təhlükəli bir nöqtə var ki, orada şablonlar faydalı olmaqdan çıxıb problemə çevrilməyə başlayır.
Bu, komanda düşünməyi dayandıranda baş verir.
Hazır cavab bir cümləyə cavab verə bilər. Bir vəziyyəti isə anlaya bilməz.
Əsas dəstəklə əsl dəstək arasındakı fərq də elə budur. Əsas dəstək açar sözlərə reaksiya verir. Əsl dəstək konteksti anlayır.
Müştəri “Plagin işləmir” deyəndə, şablon ona keşi təmizləməyi, plagini yeniləməyi, konfliktləri söndürməyi və ya giriş məlumatlarını göndərməyi təklif edə bilər. Bəzən bu, kifayətdir. Amma bəzən əsl problem onun yazdığı cümlə deyil. Bu, problemin baş vermə vaxtı, indicə qurduğu yeniləmə, qeyd etməyi unutduğu add-on versiyası, hosting mühiti, ödəniş axını, müştərinin biznes təzyiqi, ya da məhsulun özünün yaratdığı bir anlaşılmazlıq ola bilər.
Şablon bunları görmür.
İnsan görməlidir.
Şablonlar faydalıdır, amma onlar dəstək deyil
Mən şablonların pis olduğuna inanmıram. Əksinə, hesab edirəm ki, hər dəstək komandasına onlar lazımdır.
Şablonlar olmadan dəstək yavaş və ardıcıllıqdan məhrum olur. Komandanın bir üzvü nəyisə bir cür izah edir, başqası fərqli izah edir, üçüncü adam isə vacib bir detalı unuda bilər. Şablonlar bunun qarşısını almağa kömək edir. Onlar xüsusilə cavabın sabit olduğu və dərin araşdırma tələb etmədiyi adi suallar üçün çox faydalıdır.
Məsələn:
- Plagini necə quraşdırmaq olar.
- Lisenziyanı necə aktivləşdirmək olar.
- Add-on-u necə yeniləmək olar.
- Shortcode-u necə tapmaq olar.
- Admin girişini necə göndərmək olar.
- PHP versiyasını necə yoxlamaq olar.
- Keşi necə təmizləmək olar.
- Siyasətə uyğun olaraq geri ödənişi necə tələb etmək olar.
Bunlar hazır cavabların çox faydalı ola biləcəyi sahələrdir.
Amma şablon başlanğıc nöqtəsi olmalıdır, tam cavab yox.
Dəstək işçisi müştərinin əsl mesajını diqqətlə oxumadan şablonu köçürən anda keyfiyyət düşür. Müştəri bunu dərhal hiss edir. Bəlkə də nəyin səhv olduğunu dəqiq bilmir, amma cavabın onun üçün yazılmadığını hiss edir.
Bu, etibarı itirməyin ən sürətli yollarından biridir.
Onsuz da əsəbi olan müştəri verdiyi detalları nəzərə almayan ümumi bir paraqraf almaq istəmir. O, kiminsə onun konkret halını anladığını hiss etmək istəyir.
Bu, həmişə uzun cavab yazmaq demək deyil. Bəzən qısa cavab kifayətdir. Amma o, düzgün cavab olmalıdır.
Dəstək göndərdiyin sözlərin sayı ilə ölçülmür. O, cavabının vəziyyəti irəli aparıb-aparmadığı ilə ölçülür.
Dəstəyin ilk işi əsl problemi anlamaqdır
Dəstəkdəki ən böyük səhvlərdən biri çox tez cavab verməkdir.
Müştəri bir şey yazır. Dəstək işçisi tanış bir ifadəni görür. Adi cavabı göndərir. Amma əsl problem fərqli ola bilər.
Məsələn, müştəri “Yeniləmədən sonra sayt çökdü” deyəndə, bu cümlənin arxasında bir çox mümkün məna var.
- Bəlkə yeniləmə həqiqətən bir baq gətirib.
- Bəlkə əsas plagin yenilənib, amma add-on-lar yox.
- Bəlkə müştəri düzgün yeniləmə üsulu əvəzinə ZIP faylını əllə yükləyib.
- Bəlkə server dəstəklənməyən bir PHP versiyası işlədir.
- Bəlkə bir fərdi add-on köhnə bir klasdan asılıdır.
- Bəlkə saytda keşləmə və ya optimallaşdırma konflikti var.
- Bəlkə müştəri saytın yalnız bir hissəsini bərpa edib.
- Bəlkə xəta başqa bir plagindən gəlir, amma eyni vaxtda üzə çıxıb.
Əgər dəstək komandası dərhal “Zəhmət olmasa keşi təmizləyin və yenidən cəhd edin” deyə cavab verirsə, texniki olaraq adi bir şey demiş ola bilər, amma halı həll etmir.
İlk iş cavab vermək deyil. İlk iş anlamaqdır.
Bu, mesajı diqqətlə oxumaq deməkdir. Ekran görüntüsünə baxmaq. Verilibsə, xəta logunu yoxlamaq. Problem başlamazdan əvvəl nəyin dəyişdiyini soruşmaq. Müştərinin yaxınlarda bir yeniləmə, ödəniş, lisenziya migrasiyası, staging sayt və ya add-on quraşdırması qeyd edib-etmədiyini görmək.
Yaxşı dəstək araşdırmaçıdır.
Bu, hər işçinin senior developer olmalı olduğu demək deyil. Amma bu o deməkdir ki, onlar yalnız simptomlarla deyil, səbəblərlə düşünməyə öyrədilməlidir.
Simptom müştərinin gördüyüdür. Səbəb isə onun niyə baş verdiyidir.
Komanda bu ikisini ayırmağı öyrənəndə dəstək xeyli güclənir.
Müştərilər çox vaxt nəticəni təsvir edir, səbəbi yox
Əksər müştərilər problemləri texniki dildə bildirmir. Bu, normaldır.
Onlar nə yaşadıqlarını təsvir edir.
“Rezervasiya forması sınıb.” · “Ödəniş işləmir.” · “Təqvim səhvdir.” · “Müştəri e-poçt almadı.” · “Sistem yavaşdır.” · “Yeniləmə saytımı məhv etdi.” · “Plagininizdə baq var.”
Bu ifadələrin bəziləri doğru ola bilər. Bəziləri natamam ola bilər. Bəziləri emosional ola bilər. Bəziləri bir anlaşılmazlığa əsaslana bilər.
Dəstək hər cümləni hərfi mənada qəbul etməməlidir, amma hər halı ciddi qəbul etməlidir.
Məsələn, müştəri “E-poçtlar göndərilmir” deyəndə, problem bir çox fərqli yerdə ola bilər.
- İş axını (workflow) söndürülmüş ola bilər.
- E-poçt addımı konfiqurasiya edilməmiş ola bilər.
- SMTP qoşulmamış ola bilər.
- Mesaj spama gedə bilər.
- Cron tapşırığı işləməyə bilər.
- Trigger şərti uyğun gəlməyə bilər.
- Müştəri köhnə bir rezervasiya statusu ilə test edirsə bilər.
- Server poçt göndərilməsini bloklaya bilər.
- Alıcı e-poçtu səhv ola bilər.
Əgər işçi yalnız bir ümumi e-poçt nasazlıq şablonu ilə cavab verirsə, əsl səbəbi gözdən qaçıra bilər. Eyni şey rezervasiya əlçatanlığına, ödəniş şlüzlərinə, təqvim sinxronizasiyasına, dil problemlərinə, SaaS icarədar (tenant) problemlərinə və demək olar ki, hər qabaqcıl məhsul funksiyasına aiddir.
Müştərilər adətən nəticəni təsvir edir. Dəstək isə səbəbi tapmalıdır.
Bu isə məhsul biliyi tələb edir.
Məhsul biliyi mükəmməl ifadədən daha vacibdir
Bir çox şirkət dəstək cavablarının nəzakətli səslənməsinə güclü diqqət yetirir. Əlbəttə, nəzakət vacibdir. Kobud bir dəstək komandası yaxşı bir məhsula belə zərər verə bilər.
Amma məhsul anlayışı olmadan mükəmməl ifadə kifayət deyil.
Problemi həll etməyən, gözəl yazılmış bir mesaj yenə də pis bir dəstək cavabıdır.
Texniki dəstəkdə məhsul biliyi dərindən əhəmiyyət kəsb edir. Dəstək işçisi məhsulun necə işlədiyini, fərqli funksiyaların bir-biri ilə necə bağlandığını, hansı parametrin hansı davranışa təsir etdiyini və yeniləmələrdən və ya səhv konfiqurasiyadan sonra hansı problemlərin tez-tez yarandığını anlamalıdır.
Onların hər kod sətrini bilməsinə ehtiyac yoxdur. Amma məhsulun məntiqini anlamalıdırlar.
Məsələn:
- Ödəniş tamamlanıbsa, amma rezervasiya statusu dəyişməyibsə, hara baxmalıyıq?
- Bir vaxt aralığı (time slot) gizlidirsə, hansı parametrlər əlçatanlığa təsir edə bilər?
- Bildiriş göndərilməyibsə, mümkün iş axını şərtləri hansılardır?
- Bir SaaS icarədar funksiyaya çata bilmirsə, bu, icazə problemi, plan problemi, lisenziya problemi, yoxsa add-on problemidir?
- Tərcümə görünmürsə, o, dil faylından, vizual etiketdən, sətir tərcüməsi plaginindən, yoxsa keşlənmiş mətndən gəlir?
Bu cür düşüncə cilalanmış bir şablondan daha dəyərlidir.
Yaxşı bir dəstək cavabı aydın, hörmətli və strukturlaşdırılmış olmalıdır. Amma sözlərin arxasında anlayış olmalıdır.
Müştərilər faydalıdırsa, qısa bir mesajı çox vaxt bağışlaya bilir. Əsl problemi nəzərə almayan uzun bir mesajı isə nadir hallarda bağışlayırlar.
Yaxşı dəstək məhsul komandasını qoruyur
Dəstək yalnız müştərilərə kömək etməkdən ibarət deyil. O, həm də məhsul komandasını qoruyur.
Dəstək zəif olanda hər şey səs-küylü olur.
Developerlər aydın olmayan baq hesabatları alır. Məhsul menecerləri faydalı kontekst olmadan emosional şikayətlər alır. Eyni problem fərqli yollarla dəfələrlə bildirilir. Real baqlar konfiqurasiya səhvləri ilə qarışır. Təcili hallar adi suallardan ayrılmır. Kiçik anlaşılmazlıqlar ictimai narazılığa çevrilir.
Yaxşı dəstək həqiqəti gizlətmədən səs-küyü filtrləyir.
- O, faydalı detalları toplayır.
- Mümkün olduqda problemləri təkrar yaradır (reproduce edir).
- Nümunələri (pattern-ləri) müəyyən edir.
- Baqları səhv konfiqurasiyadan ayırır.
- Müştəriyə təsiri izah edir.
- Developerlərə prioriteti anlamağa kömək edir.
- Məhsul komandasına istifadəçilərin harada çaşdığını bildirir.
Bu, son dərəcə vacibdir.
Yalnız mesajları developerlərə ötürən bir dəstək komandası əslində dəstək etmir. O, sadəcə mesajları bir yerdən başqa yerə daşıyır.
Dəstəyin dəyəri şərhdədir (interpretation).
Məsələn, müştəri hər şeyin sındığını deyən uzun, əsəbi bir mesaj göndərə bilər. Zəif bir dəstək prosesi o mesajı birbaşa developerə ötürür və “Zəhmət olmasa yoxlayın” deyir.
Daha güclü bir dəstək prosesi belə deyir:
Müştəri dünən əsas plagini yeniləyib, amma hələ də köhnə add-on-ları var. Fatal xəta yerli ödəniş ilə rezervasiya yaradılanda üzə çıxır. Xəta logu iş axını hadisə filtrindəki çatışmayan bir klasa işarə edir. Bu, versiya uyğunsuzluğu və ya çatışmayan uyğunluq yoxlaması ilə bağlı ola bilər. Müvəqqəti admin girişi istədim və problemin yalnız bu konkret ödəniş üsulu istifadə olunanda baş verdiyini təsdiqlədim.
Bu cür hesabat vaxta qənaət edir.
Həm də developerin dəstəyə daha çox hörmət etməsinə kömək edir.
Dəstək aydın, texniki, yaxşı təşkil olunmuş kontekst verəndə, bütün məhsul komandası daha sürətli olur.
Ton vəziyyətə uyğun olmalıdır
Şablonlarla bağlı başqa bir problem odur ki, onlar çox vaxt hər vəziyyət üçün eyni tonu istifadə edir.
Amma hər dəstək halı eyni tona ehtiyac duymur.
- Adi bir sual mehriban və qısa bir cavab ala bilər.
- Çaşmış müştəriyə sakit bir izah lazım ola bilər.
- Əsəbi müştəriyə möhkəm, amma hörmətli bir cavab lazımdır.
- Ciddi bir baq hesabatına etiraf və təcillilik lazımdır.
- Geri ödəniş tələbinə aydınlıq və siyasət lazımdır.
- Səhv edən müştəriyə alçaltmadan düzəliş lazımdır.
- Ədalətsiz davranan müştəriyə daha birbaşa bir cavab lazım ola bilər.
Yaxşı dəstək həmişə “çox nəzakətli” deyil. O, münasibdir.
Bəzən çox yumşaq olmaq çaşqınlıq yaradır. Bəzən çox rəsmi olmaq soyuq hiss olunur. Bəzən həddən artıq üzr istəmək, məhsul düzgün işləsə belə, şirkəti günahkar göstərir. Bəzən müdafiə mövqeyi tutmaq müştərini daha da əsəbiləşdirir.
Ton bir məhsul bacarığıdır.
Dəstək işçisi müştərinin emosional vəziyyətini və problemin ciddiliyini anlamalıdır. Canlı biznesi bloklanmış müştəri, parametrin harada olduğunu soruşan biri ilə eyni adi şablonu almamalıdır.
Bu, dəstəyin emosional olmalı olduğu demək deyil. Bu, dəstəyin fərqində olmalı olduğu deməkdir.
Yaxşı bir cavab eyni anda sakit, aydın və möhkəm ola bilər.
Məsələn, müştəri səhv yeniləmə üsulu istifadə edib saytı sındırıbsa, cavab ona hücum etməməlidir. Amma üsulun səhv olduğunu və təkrarlanmamalı olduğunu aydın izah etməlidir. Məhsulun real bir problemi varsa, cavab qeyri-müəyyən dilin arxasında gizlənməməlidir. Problemi etiraf etməli və növbəti addımı izah etməlidir. Müştəri bir funksiyanın necə işlədiyini səhv başa düşürsə, cavab onu axmaq hiss etdirmədən nəzərdə tutulan davranışı aydınlaşdırmalıdır.
Bu tarazlığı təkbaşına şablonlar idarə edə bilməz.
Dəstək yalan vədlər yaratmamalıdır
Dəstəkdəki ən təhlükəli şeylərdən biri çox tez bir şey vəd etməkdir.
- “Bu gün düzəldəcəyik.”
- “Bu, növbəti yeniləməyə daxil olacaq.”
- “Developerlərimiz bu funksiyanı əlavə edəcək.”
- “Bu, mütləq bir baqdır.”
- “Bu, mütləq bizim günahımız deyil.”
- “Geri ödəniş alacaqsınız.”
- “Bu, sadədir.”
Bu cümlələr o an faydalı görünə bilər, amma sonradan daha böyük problemlər yarada bilər.
Dəstək əminliklə ehtiyatlı olmalıdır.
Bəzən problem araşdırma tələb edir. Bəzən bir funksiya tələbi sadə səslənir, amma böyük dəyişikliklər tələb edir. Bəzən bir baq yalnız bir mühitə təsir edir. Bəzən düzəliş testdən asılıdır. Bəzən geri ödəniş tələbi siyasət baxışı tələb edir. Bəzən developer nəyinsə mümkün olub-olmadığını təsdiqləməlidir.
Yaxşı dəstək əminlik uydurmadan tərəqqini çatdırır.
Belə demək daha yaxşıdır:
- “Bunu texniki komanda ilə araşdırmalıyıq.”
- “Bu, yeniləmə ilə bağlı görünür, amma dəqiq səbəbi təsdiqləməliyik.”
- “Bu tələb aydındır, amma təsiri nəzərdən keçirmədən tətbiqi vəd edə bilmərik.”
- “Bu davranış cari məntiqə görə gözləniləndir, amma niyə çaşdırıcı ola biləcəyini başa düşürəm.”
- “Xəta loglarını yoxlayıb sizə aydın bir cavabla qayıdacağıq.”
Bu cür dil dürüst və peşəkardır.
Müştərilər gözləməyi həmişə sevməyə bilər, amma adətən yalan vədlərdən çox aydınlığa hörmət edirlər.
Dəstək komandası müvəqqəti rahatlıq yox, etibar qurmalıdır.
Ən yaxşı dəstək cavabları nəyisə öyrədir
Güclü bir dəstək cavabı bir ticketi həll etməkdən artığını edir. O, müştəriyə məhsulu daha yaxşı anlamağa kömək edir.
Bu, hər cavabı dərsliyə çevirmək demək deyil. Heç kim tez bir düzəlişə ehtiyacı olanda uzun mühazirə oxumaq istəmir.
Amma mümkün olduqda dəstək cavabın arxasındakı səbəbi izah etməlidir.
Məsələn, yalnız belə demək əvəzinə:
“Zəhmət olmasa bütün add-on-ları yeniləyin.”
Daha yaxşı cavab budur:
“Zəhmət olmasa əsas plagini və bütün əlaqəli add-on-ları birlikdə yeniləyin, çünki bəzi add-on-lar ən son əsas (core) strukturundan asılıdır. Yalnız bir hissəni yeniləmək versiya uyğunsuzluğu problemləri yarada bilər.”
Bu kiçik izah müştəriyə addımın niyə vacib olduğunu anlamağa kömək edir.
Yalnız belə demək əvəzinə:
“Zəhmət olmasa real bir cron tapşırığı istifadə edin.”
Daha yaxşı cavab budur:
“Xatırlatma və gecikdirilmiş iş axını addımları planlaşdırılmış tapşırıqlardan asılıdır. Cron tapşırığı müntəzəm işləmirsə, o addımlar vaxtında işə düşməyə bilər.”
Yenə də, müştəri nəyisə öyrənir.
Bu, gələcək dəstək müraciətlərini azaldır. Həm də məhsulu daha şəffaf hiss etdirir.
Yaxşı dəstək təlimatların arxasında gizlənmir. O, istifadəçiyə növbəti dəfə daha yaxşı qərarlar verməsi üçün kifayət qədər izah edir.
Dəstək geribildirimi məhsulu yaxşılaşdırmalıdır
Eyni sual təkrar-təkrar yaranırsa, cavab yalnız daha yaxşı bir şablon yaratmaq deyil.
Daha yaxşı sual budur: müştərilər bunu niyə bu qədər tez-tez soruşur?
- Bəlkə interfeys aydın deyil.
- Bəlkə sənədləri tapmaq çətindir.
- Bəlkə parametrin adı çaşdırıcıdır.
- Bəlkə xəta mesajı həddən artıq texnikidir.
- Bəlkə yeniləmə bildirişi kifayət qədər güclü deyil.
- Bəlkə məhsul istifadəçilərə həddən artıq asanlıqla səhv etməyə imkan verir.
- Bəlkə vacib bir tələb gizlidir.
Dəstək yalnız təkrarlanan problemlərə reaksiya verməməlidir. O, onları aradan qaldırmağa kömək etməlidir.
Dəstəyin məhsul inkişafının bir hissəsinə çevrildiyi yer də elə budur.
Hər təkrarlanan ticket bir siqnaldır.
On müştəri eyni mətni necə tərcümə etməyi soruşursa, bəlkə o mətni tərcümə etmək daha asan olmalıdır. Çoxlu müştəri add-on-ları yeniləməyi unudursa, bəlkə yeniləmə ekranına daha yaxşı bir xəbərdarlıq lazımdır. İstifadəçilər bir qiymət seçimini səhv başa düşürsə, bəlkə etiket səhvdir. Müştərilər iş axınlarını tez-tez səhv konfiqurasiya edirsə, bəlkə iş axını qurucusuna daha yaxşı yönləndirmə lazımdır.
Şablonlar təkrarlanan suallara daha sürətli cavab verməyə kömək edə bilər. Məhsul təkmilləşdirmələri isə o sualların yox olmasına səbəb ola bilər.
Daha yaxşı həll də elə budur.
Dəstək eyni suala əbədi cavab verməklə fəxr etməməlidir. O, daha az müştərinin onu soruşmağa ehtiyacı olanda fəxr etməlidir.
Əsl dəstək mühakimə tələb edir
Günün sonunda, ən vacib dəstək bacarığı mühakimədir.
- Şablonu nə vaxt istifadə etməyi bilmək.
- Onu nə vaxt fərdiləşdirməyi bilmək.
- Nə vaxt daha çox detal istəməyi bilmək.
- Nə vaxt eskalasiya etməyi bilmək.
- Nə vaxt möhkəm olmağı bilmək.
- Nə vaxt üzr istəməyi bilmək.
- Nə vaxt “yox” deməyi bilmək.
- Bir halın nə vaxt təcili olduğunu bilmək.
- Müştərinin nə vaxt məhsulu səhv başa düşdüyünü bilmək.
- Məhsulun özünün nə vaxt çaşdırıcı olduğunu bilmək.
Bu, asan deyil.
Bu, təcrübədən, məhsul biliyindən və diqqətli düşüncədən gəlir.
Yalnız skriptlərə əməl edən bir dəstək işçisi sadə halları idarə edə bilər, amma mürəkkəb hallarda çətinlik çəkəcək. Yaxşı bir dəstək işçisi başa düşür ki, hər ticket kiçik bir araşdırmadır.
Bəzən cavab texnikidir. Bəzən təhsilvericidir. Bəzən emosionaldır. Bəzən siyasətlə bağlıdır. Bəzən bir məhsul qərarıdır.
Şablonlar bu qərarları verə bilməz.
İnsanlar verə bilər.
Yekun fikirlər
Dəstək şablonları faydalıdır. Onlar vaxta qənaət edir, ardıcıllıq yaradır və komandalara hər gün eyni izahları təkrarlamamağa kömək edir.
Amma şablonlar dəstək deyil.
Dəstək müştərinin əslində nə yaşadığını anlamaq, simptomun arxasındakı səbəbi müəyyən etmək, aydın ünsiyyət qurmaq, məhsul komandasını səs-küydən qorumaq və müştəriyə irəli getməyə kömək etmək bacarığıdır.
Hazır cavab bu prosesin bir hissəsi ola bilər. O, prosesi əvəz etməməlidir.
Ən yaxşı dəstək komandaları sadəcə şablon toplamır. Onlar düşünən sistemlər qurur.
- Onlar məhsulu bilir.
- Onlar istifadəçiləri anlayır.
- Onlar daha yaxşı suallar verir.
- Onlar qərarları aydın izah edir.
- Onlar yalan vədlərdən qaçır.
- Onlar problemləri düzgün bildirir.
- Onlar təkrarlanan problemləri məhsul təkmilləşdirmələrinə çevirir.
Ticketlərə cavab vermək ilə əsl dəstək etmək arasındakı fərq də elə budur.
Şablon dəstəyi daha sürətli edə bilər.
Amma dəstəyi yalnız düşüncə yaxşı edə bilər.