
Bu şablonu kullanın
Ürün desteği, müşterilerin şirketiniz hakkında kalıcı izlenimini oluşturduğu yerdir. Trupeer ile ücretsiz bir ürün desteği SOP şablonuyla başlayarak, marka yönergeleriniz ile özelleştirerek ve her prosedürü net bir video anlatımına dönüştürmek için AI SOP oluşturucumuzu kullanarak destek dokümantasyonunda saatler kazanabilirsiniz.
Ürün desteği SOP şablonu ne için kullanılır?
Ürün desteği SOP’si, bir ürünle ilgili olarak tekrarlayan bir müşteri temasını yönetmek için yazılı prosedürdür: ne sorulmalı, ne kontrol edilmeli, nasıl çözülmeli, ne zaman yükseltilmeli ve müşteriye ne söylenmeli.
Şablon, yeniden kullanılabilir bir iskelet sağlar. Tetikleyici, ön koşullar, adımlar, çözüm, yükseltme, müşteri ifadeleri.
Müşteri hizmetleri SOP’siyle yakından ilişkilidir ve aynı doküman değildir; çünkü bu sayfadaki her şeyi şekillendiren tek bir neden vardır. Ürün desteğinde bir ürün vardır ve ürün yanlış olabilir. Müşteri hizmetleri prosedürü bir durumu ele alır. Ürün desteği prosedürü çoğu zaman bir arızayı ele alır ve bu arızayla ne yaptığı, önümüzdeki iki yıl boyunca temas hacminizin artıp azalacağını belirler.
Genel yapı için SOP şablonumuz bunu kapsar; IT SOP şablonumuz ise dahili teknik operasyonları kapsar. Bu sayfa, destek olduğunuz şeyin başka birinin düzeltebileceği bir ürün olması durumunda nelerin değiştiğini ele alır.
Her destek prosedürünün iki çıktısı vardır; biri değil
Bir destek SOP’si genellikle tek bir şeyle değerlendirilir: teması hızlı ve tutarlı şekilde çözüyor mu? Bu makul bir ölçüdür ve işin yarısıdır.
Diğer yarısı ise sinyaldir. Destek, organizasyondaki tüm arızaların hacimle birlikte ve kanıt eklenmiş şekilde ortaya çıktığı tek noktada konumlanır. Kimse başka bu deseni görmez. Mühendislik, kendisine bildirilen hataları görür. Ürün, yol haritasını görür. Destek ise ayda dört yüz kez müşterilerde gerçekte ne olduğunu görür.
Bu nedenle her prosedürün iki olası çıktısı vardır: bu müşteri için çözüm ve bunu durdurabilecek kişiler için rapor.
Neredeyse hiçbir destek SOP’si ikincisini içermez. Adımlar, “müşterinin memnun olduğunu doğrulayın ve talebi kapatın” ile biter. Tekrarlayan bir çözümün ne zaman çözüm olmaktan çıkıp kusur haline gelmesi gerektiğini, kime neyin yükseltilmesi gerektiğini, hangi kanıtla ve hangi noktada yapılacağını belirten bir alan yoktur.
Bu çıkışı her prosedüre eklediğinizde kütüphane değişir. Olmadığında destek, arızaları emen çok verimli bir mekanizmaya dönüşür; arızaları emme verimliliği ise birisi hacme baktana kadar onları hiç yokmuş gibi görünür.
Trupeer’da bu şablon nasıl özelleştirilir
Adım 1: Şablonlar Bölümünü Açın
Ana navigasyondan Şablonlar bölümüne gidin.

Adım 2: Bir Şablon Seçin ve Açın
Açmak istediğiniz herhangi bir şablonun üzerine tıklayın.

Adım 3: Şablon Görünümünü Genişletin
Gerekirse, tam düzeni ve ayrıntıları net şekilde görmek için şablon görünümünü genişletin.

Adım 4: Şablonu Düzenleyin
Seçili şablonda değişiklik yapmaya başlamak için Düzenle’ye tıklayın.

Düzenleyicide şunları yapabilirsiniz:
Yeni bölümler ekleyin
Biçimlendirme kurallarını tanımlayın veya güncelleyin
Bir logo ekleyin ve konumunu ile ilgili ayarları düzenleyin
Adım 5: Özelleştirilmiş Şablonunuzu Kaydedin
Gerekli tüm değişiklikleri yaptıktan sonra, güncellenmiş şablonu kendi şablonunuz olarak saklamak için Kaydet’e tıklayın.

Adım 6: Şablonu Önizleyin ve İnce Ayar Yapın
Özelleştirilmiş şablonunuzun nasıl göründüğünü görmek istediğinizde Önizleme’yi açın.

Önizleme ekranından, gerekirse doğrudan ayarlamalar yapmaya devam edebilir; böylece şablonun tam olarak istediğiniz gibi göründüğünden emin olursunuz.
Ürün desteği SOP şablonuyla şunları yapabilirsiniz:
Yazmaya ayırdığınız saatlerden tasarruf edin: Destek prosedürleri için oluşturulmuş bir yapıyla boş sayfayı atlayın.
Destek kalitesini standartlaştırın: Her temsilci yaygın sorunları aynı şekilde ele alsın.
Markanızla uyumlu kalın: Trupeer’ın marka kitini kullanarak logonuzu, tonunuzu ve renklerinizi uygulayın.
Çözüm süresini kısaltın: Net prosedürler, temsilcilerin sorunları daha hızlı çözmesine yardımcı olur.
Temsilcileri daha hızlı dahil edin: Yeni işe başlayanları hızlıca yetiştirmek için SOP’leri video anlatımlarla eşleştirin.
Küresel ekiplere ulaşın: Destek SOP’lerini tek tıkla 65+ dile çevirin.
Çözüm yolu kütüphaneniz sayılmamış bir hata birikimi
Bu argümanın bu hafta üzerinde harekete geçebileceğiniz versiyonu burada.
Destek prosedürlerinizin üzerinden geçin ve çözüm yolu (workaround) olduğunu gösteren ifadeleri arayın. Geçici bir önlem olarak. Bu bilinen bir sorun. Müşteriye şunu önerin. Sıfırlayıp yeniden denesin. Çalışmazsa, şunu deneyin.
Bunların her biri, birinin yaşamayı seçtiği bir ürün kusurudur. Çoğu durumda bilerek değil. Birisi, ekip arkadaşlarının bir problemi yönetmesine yardımcı olacak iyi bir prosedür yazdı; prosedür çalıştı, temaslar verimli şekilde ele alındı ve arıza artık çözmek için baskı üretmeyi bıraktı.
Bunları saydığınızda, organizasyonun başka hiçbir yerinde var olmayan bir hata birikiminiz olur. Her birini temas hacmi ve ele alma süresiyle çapraz referanslayın; böylece bu birikimi maliyete göre sıralanmış halde görürsünüz. Bu, gerçek birikimi için çoğu ürün ekibinin sahip olduğu olandan daha fazlasıdır.
Rahatsız edici içgörü şudur: çok iyi bir çözüm yolu SOP’su yazmak, düzeltmeyi aktif olarak geciktirir. Prosedür ne kadar iyiyse, arızanın çıkardığı gürültü o kadar az olur ve o kadar uzun süre hayatta kalır.
SOP’lerinizde zaten bulunan çözüm yolları nasıl bulursunuz
Bir öğleden sonra işi ve kimsenin iş birliğini gerektirmez.
Yukarıdaki ifadeler için prosedür kütüphanenizde arama yapın. Çoğu kütüphanede bu, prosedürlerin %15 ila %30’u arasında bir sonuç verir.
Her bir eşleşme için şunları kaydedin: hangi prosedür, altta yatan temel arıza nedir, son on iki ayda kaç temas üretti, ortalama ele alma süresi ve daha önce hiç bir kusur olarak yükseltildi mi.
Son sütun insanların sürpriz yaşadığı yerdir. Belgelenmiş çözüm yollarının büyük bir kısmı hiç resmi olarak bildirilmemiştir; çünkü prosedürü yazan kişi problemi, kendisine sunulan şekilde çözmüştür: bir prosedür yazarak.
Temasları ele alma süresiyle çarpıp saatleri bulun, saatleri yüklü maliyetinizle çarpıp bir sayı elde edin. Azalan sırayla sıralayın. İlk beş genellikle toplamın çoğunu oluşturur ve aşağıda açıklanan kayıt için sizin vakalarınız bunlardır.
Bunu destek ekibinin bir başarısızlığı gibi sunmayın. Onlar ellerinden geleni yaptılar ve bunu iyi yaptılar.
Düzeltmeyi kusura dönüştüren tekrarlama tetikleyicisi
Bunu engelleyen mekanizma, prosedürün bizzat içine yazılmış bir eşiğe dayanır.
Tek bir kök nedene bağlı çeyreklik temas sayısı | Prosedürün ne söylemesi gerekir | Kim harekete geçer |
|---|---|---|
10’un altında | Belgelendirilmiş adımları kullanarak çözün | Yalnızca destek |
10 ila 50 | Çözün ve bilinen sorun kaydıyla birlikte günlüğe kaydedin | Desteğin, kaydın ürüne görünür olduğu şekilde |
50’nin üstünde | Çözün ve prosedür otomatik olarak bir kusur incelemesini tetiklesin | Belirtilen bir süre içinde ürün ve mühendislik |
Arka arkaya iki çeyrekte 50’nin üstünde | Çözüm yolu bir düzeltme tarihi ya da kalıcı olarak kabul etmeye yönelik açık bir karar gerektirir; kaydedilir ve imzalanır | Ürün liderliği |
Bu sayılar kendi hacimlerinize göre belirlenmelidir. Önemli olan, bir eşiğin var olması ve bunu aşmanın, kimsenin başlatmak için cesur olması gerekmeyen bir eylem üretmesidir.
Son satır davranışı değiştiren satırdır. Kalıcı bir çözüm yolunu kabul etmek meşru bir karardır ve açıkça, bunu almaya yetkili biri tarafından verilmeli ve kaydedilmelidir. Meşru olmayan şey, bu kararın varsayılan olarak verilmesi; yani kimsenin bunu hiç gündeme getirmemesiyle.
Ücretsiz ürün desteği SOP şablonu: kopyalanacak yapı
Buradan kopyalayın. Yıldız işaretli alanlar, standart bir SOP’ye yapılan eklerdir.
Başlık. Prosedür numarası ve başlığı; dahili nedeni değil, müşterinin yaşadığı belirtiyi yansıtacak şekilde yazın. Sahibi. Son doğrulama tarihi. Etkilenen ürünler ve sürümler. Tahmini ele alma süresi. Bilinen sorun referansı (varsa).
Belirti. Müşterinin kendi ifadeleriyle nasıl tarif ettiği; yaygın varyasyonlar dahil. Temsilcilerin aradığı kısım budur.
Bu prosedürü kullanmayın. Yanlış prosedür olduğu koşullar; doğru olan prosedüre yönlendirme ile birlikte.
Tanılama soruları. Herhangi bir şey yapmadan önce, en hızlı şekilde en çok vakayı eleyen sırayla neyin tespit edilmesi gerektiği.
Çözüm adımları. Numaralı; her adımda tek bir eylem ve beklenen sonuç. Eğer bir adım bilinen bir arıza için bir çözüm yoluyorsa, bunu amaçlanan davranış gibi sunmak yerine “çözüm yolu” olarak işaretleyin.
Müşteri ifadeleri. Ne söylemeniz gerektiği; ne vaat etmemeniz gerektiği dahil. Bu bölüm, on iki temsilcinin aynı arıza için on iki farklı anlatım vermesini durdurur ve bizim help desk yanıt şablonumuz bu ifadeleri daha derinlemesine ele alır.
Yükseltme. Kime, hangi noktada ve hangi bilgiler eklenmiş şekilde.
Kusur yolu. Ürün veya mühendisliğe neyin, hangi formatta iletileceği ve gereken kanıt. Bunu opsiyonel değil zorunlu yapan tekrarlama eşiğini ekleyin.
Doğrulama. Müşteri için gerçekten çözüldüğünü nasıl doğrulayacağınız; gecikmeden sonra ancak görülebilecek her şey dahil.
Buraya kadar kopyalayın. En önemli iki alan bilinen sorun referansı ve kusur yoludur; size genel bir SOP şablonunun vermeyeceği iki şey de bunlardır.
Otuz bir gizli kusuru olan ses şirketi
Vantree Audio tüketici kablosuz hoparlörler ve kulaklıklar üretir. İki lokasyonda yaklaşık doksan destek temsilcisi, ayda kabaca on dört bin teması yönetir.
Geleneksel ölçütlere göre destek fonksiyonu iyi durumdaydı. İyi bakımı yapılmış yüz kırk dokümante prosedür, hedefin içindeki çözüm süreleri, beş üzerinden dört nokta iki müşteri memnuniyeti.
Uymayan sayı, satılan birim başına düşen temas sayısıydı ve bu, üç ardışık yıl boyunca artmıştı.
Birisi prosedür kütüphanesinde çözüm yolu dili için arama yaptı. Yüz kırk prosedürün otuz biri, bilinen bir ürün arızası için dokümante edilmiş bir çözüm yolu içeriyordu.
Bilet hacmiyle çapraz referanslandığında, bu otuz bir prosedür tüm temasların yüzde otuz sekizini oluşturuyordu.
En büyük tekil örnek, bir modelde Bluetooth eşleştirme arızasıydı; çözüm yolu altı adımlı bir sıfırlama dizisiydi. On iki ayda iki bin dokuz yüz temas, ortalama ele alma süresi on bir dakika; bu da tek bir arıza için yaklaşık beş yüz otuz temsilci saati demekti.
Bu prosedür, model piyasaya çıktıktan sonraki üçüncü ayda, ekip arkadaşlarına yardımcı olmak için kıdemli bir temsilci tarafından yazılmıştı. Yirmi altı ay sonra hâlâ kütüphanedeydi. Prosedür işe yaradığı için mühendisliğe hiç söylenmemişti. Temaslar verimli ve tutarlı şekilde ele alındı; bu nedenle arıza hiçbir yerde düzeltme baskısı üretmedi.
Otuz bir çözüm yolunun on dokuzu hiç kusur olarak yükseltilmemişti. Sekizi bir kez yükseltilmiş ama takip edilmemişti. Dördü mühendislik tarafından biliniyordu ve bilerek ertelenmişti.
Otuz birin tamamında yıllık maliyet yaklaşık beş bin üç yüz temsilci saatine ulaştı; sadece ele alma için bile yaklaşık yüz altı bin pound civarındaydı; iadelerin veya memnuniyet üzerindeki etkilerin hesabı yapılmadan.
Üç değişiklik yapıldı. Her prosedür bir kusur yolu kazandı. İçine bir tekrarlama tetikleyicisi yazıldı; böylece bir çözüm yolu içeren ve bir çeyrekte elliden fazla kez çağrılan herhangi bir prosedür otomatik olarak bir kusur incelemesini tetikledi. Ayrıca, temaslar ile ele alma süresinin çarpımıyla sıralanan bir çözüm yolu kaydı oluşturuldu; bu kayıt ürün ve mühendislikle birlikte aylık olarak gözden geçirildi.
Kayıda eklenen kural önemli olanı belirliyordu: bir çözüm yolu iki çeyrek boyunca var olabilir; ardından ya bir düzeltme tarihi ya da kalıcı olarak kabul etmeye yönelik kaydedilmiş bir karar gerekir.
On iki ay sonra, otuz birin on biri ürün veya firmware tarafında düzeltilmişti. Bu on birindeki temaslar yaklaşık yüzde yetmiş dört azaldı. Tüm aralık boyunca satılan birim başına düşen temaslar yüzde on dokuz düştü. Kayıt, on dört açık çözüm yolunda duruyordu; bunların dokuzunda karşılarında düzeltme tarihi vardı.
Bluetooth arızası, kayıt başlatıldıktan dört ay sonra bir firmware sürümünde düzeltildi; iyi şekilde ele alınarak yirmi altı ay hayatta kalmıştı.
Önce hangi ürün desteği SOP’leri yazılmalı
Karmaşık olanlar değil. Hacmin yüksek olduğu ya da temsilcilerin şu anda doğaçlama yaptığı prosedürleri yazın; çünkü tutarlılığın işe yaradığı iki yer burasıdır.
Temas nedenlerinizi hacme göre sıralayın ve ilk on’u yazın. Çoğu destek operasyonunda ilk on, tüm temasların yarısından fazlasını oluşturur ve genellikle gösterişli değildir: kurulum ve ilk kullanım, bağlantı, hesap ve oturum açma, faturalandırma sorguları, iade ve garanti, firmware veya yazılım güncellemeleri, uyumluluk soruları ve mevcut ürünlerinize özgü iki ya da üç arıza.
Ardından, yanlış yapmanın sık olmaktan çok pahalı olduğu durumları ekleyin. Güvenlikle ilgili temaslar, geri çağırma veya düzenleyici bir yükümlülük içeren her şey, veri veya gizlilik talepleri ve yanlış yanıtın yasal bir taahhüt oluşturduğu her temas.
Temsilcilerin aradaki kısa referanslara ihtiyaç duyduğu, yani tam bir prosedür yerine arama anında gereken kısa bilgiler için genellikle SOP’yi uzatmaktan daha iyi sonuç veren bir job aid kullanılır.
Hacim listenizi kapsayan on ila on beş prosedür artı yüksek sonuçlu vakalar, çalışan bir kütüphanedir. Sıfırdan başlayıp yüz kırk prosedür denemek, bu projelerin takılma şeklidir.
Bir destek SOP’si nasıl yazılır: adım adım
Ürün dokümantasyonundan değil, gerçek temaslardan başlayın. Konuyla ilgili son yirmi talebi okuyun ve belirtinin müşterinin kendi ifadeleriyle nasıl tarif edildiğini alın; çünkü temsilciler de ararken bunu kullanacaktır.
Tanılama sorularını, en hızlı şekilde en çok vakayı eleyen sırayla yazın. Çoğu prosedür, soruları en hızlı çözen sırayla değil, ürünün nasıl inşa edildiği sırayla sorar.
Adımları, birinin canlı bir vakayı nasıl çözdüğünü izleyerek yazın; bunun nasıl çalışması gerektiğinden değil.
Her çözüm yolunu çözüm yolu olarak işaretleyin. Bu tek alışkanlık, daha sonra yukarıdaki denetimin mümkün olmasını sağlayan şeydir.
Müşteri ifadelerini yazın; ne denmemesi gerektiği dahil ve ürünün dış mesajlarından sorumlu olan kim varsa onunla bunu onaylatın.
Yayınlamadan önce kusur yolunu ve tekrarlama eşiğini belirleyin; sonradan değil.
Ardından, bu temas türünü hiç ele almamış birinin, siz izlerken ve hiçbir şey söylemeden prosedürden gerçek bir vakayı çözmesini sağlayın.
Yükseltme, ciddiyet ve sorun giderme ne zaman durdurulmalı
Destek prosedürlerinin rutin olarak eksik olduğu diğer alan bir durdurma kuralıdır.
Temsilciler sorun gidermeye devam eder; çünkü durmak pes etmek gibi gelir ve çoğu destek ekibinde yükseltmenin sosyal bir maliyeti vardır. Bu yüzden on iki dakikadan sonra yükseltilmesi gereken bir temas kırk dakikaya uzar ve müşteri hem gecikmeyi hem de nihai devri yaşar.
Durdurma kuralını prosedürün içine yazın. Belirtilen sayıda tanılama adımından sonra ya da belirtilen geçen süre sonunda ya da belirli bir bulguda prosedür biter ve yükseltme başlar. Bunu bir yargı değil, bir talimat haline getirin.
Bunu, betimleyici değil gözlemlenebilir ciddiyet tanımlarıyla eşleştirin. “Yüksek etki” değil; örneğin: müşteri temel işlevi kullanamaz ya da bir güvenlik endişesi raporlanır ya da bugün birden fazla müşteri aynı belirtiyi bildirmiştir.
Ayrıca yükseltmeyle birlikte nelerin iletileceğini tanımlayın. Ekli bir tanılama geçmişi olmayan bir yükseltme geri gönderilir; bu da müşterinin bir başka döngü daha yaşamasına neden olur. Bu devirin çalışması için gereken alanları bizim ticket and resolution template kapsar.
Ürün desteği SOP’si mi, müşteri hizmetleri SOP’si mi?
İkisi de var; örtüşüyorlar ve ayrımı korumaya değer; çünkü farklı şekillerde başarısız oluyorlar.
müşteri hizmetleri SOP’si ilişkiyi ve işlemi yönetir: siparişler, şikayetler, iadeler, hesap değişiklikleri, genel sorular. Değişken müşterinin durumudur ve iyi bir prosedür tutarlı, adil bir sonuç üretir.
ürün desteği SOP’si ise bir ürünle ilgili teknik bir sorunu yönetir. Değişken ürünün davranışıdır ve iyi bir prosedür bir çözüm üretir; ürün kusurluysa bir sinyal de üretir.
Çoğu destek organizasyonu ikisine de ihtiyaç duyar ve prosedürler tek bir kütüphanede yaşamalıdır; her birinin hangi tür olduğunu belirten net bir işaret olmalıdır; çünkü temsilciler bu ayrımı deneyimlemez ve zorunda da kalmamalıdır.
Ekibiniz teknik kusurları hiç ele almıyorsa, istediğiniz yapı müşteri hizmetleri yapısıdır. Ekibiniz düzenli olarak çözüm yollarını dokümante ediyorsa, bu sayfa daha alakalıdır ve çözüm yolu denetimini bu hafta çalıştırmaya değer.
Word veya Excel’de ürün desteği SOP şablonu alabilir miyim?
Prosedürün kendisi için Word veya Google Docs. Bu, numaralı adımlar ve müşteri ifadeleri içeren bir metindir; sıralanmak yerine okunur.
Bireysel prosedürden daha önemli olan iki şey için Excel. Prosedür kaydı: her SOP’nin sahibi, son doğrulama tarihi, temas hacmi, ortalama ele alma süresi ve çözüm yolu içerip içermediği. İkinci olarak, çözüm yolu kaydı: arıza, temaslar, saatler, bir kusurun yükseltilip yükseltilmediği ve düzeltme tarihi ya da kabul edilen karar.
İkinci sayfa, bu sayfanın tamamının üretmek için var olduğu çıktıdır. Oluşturması bir öğleden sonra sürer ve genellikle iş dünyasındaki ilk kez, düzeltilmemiş kusurların maliyetinin tek bir yerde görüldüğü andır.
Destek ekibinin dışında paylaşılan her şey için PDF; örneğin bir partner anlaşmasına ekli bir prosedür veya bir denetim sırasında gösterilen içerikler.
Ürün piyasaya çıktıkça destek prosedürlerini güncel nasıl tutarsınız
Ürün desteği prosedürleri, diğer her türden daha hızlı eskir; çünkü anlattıkları şey, başkasının yayın takviminde değişir. Bir firmware güncellemesi bir menüyü değiştirir, bir yazılım sürümü bir ayarı kaldırır ve destek ekibinin haberdar edilmediği bir haftada kırk prosedür ince ince yanlış hale gelir.
Pratik sonuç şudur: kütüphaneyi sürdürmek, temasları ele almakla rekabet eder ve temasları ele almak her zaman kazanır.
Trupeer AI maliyetin çoğunu ortadan kaldırır. Bir temsilci, kayıt çalışırken teması bir kez çözer ve çıktı, adımlar ile ekran görüntüleri zaten yakalanmış şekilde yazılı bir prosedür olur; böylece sıfırdan bestelemek yerine kontrol etmeye hazır hale gelir. Bir sürümden sonra kırk prosedürü güncellemek, kimsenin başlatmadığı bir proje yerine bir güne dönüşür.
Kaydedin. Markalayın. Çevirin. Trupeer’layın.
Aynı kayıt, genellikle aynı anda ihtiyaç duyulan ve nadiren yazılan müşteriyle yüz yüze sürümü de üretir; ayrıca knowledge base article templates bu yapıyı kapsar. SOP creator dahili prosedürleri kapsar ve ikisi de tutarlı bir marka kimliğiyle knowledge base içinde yaşar. Kurulum talimatları document template setup guide içinde yer alır.
Sık Sorulan Sorular
Word’de ücretsiz bir ürün desteği SOP şablonu var mı?
Yukarıdaki yapı, bilinen sorun referansı ve genel SOP şablonlarının atladığı kusur yolu alanları dahil olmak üzere doğrudan Word veya Google Docs’a yapıştırılır. Kilitli bir indirme yoktur ve form yoktur. Zaten kullandığınız her şeye ilk eklenmeye değer alan, her adımda bir çözüm yolu olduğuna dair işaret koymaktır.
Excel’de ücretsiz bir ürün desteği SOP şablonu var mı?
Excel, prosedürden ziyade iki kayıt için uygundur. Hacim ve ele alma süresiyle birlikte prosedür kaydı ve arıza, maliyet ve düzeltme tarihiyle birlikte çözüm yolu kaydı. İkincisini oluşturmak, çoğu destek fonksiyonu için mevcut olan en yüksek geri dönüşlü tek öğleden sonradır.
PDF’de ücretsiz bir ürün desteği SOP şablonu var mı?
Ekip dışı paylaşılan her şey için prosedürleri PDF’ye aktarın ve çalışan sürümleri düzenlenebilir halde tutun. Destek prosedürleri her ürün sürümüyle değişir; bu nedenle dondurulmuş bir kütüphane çoğu zaman daha hızlı bozulur.
Word veya PDF’de genel bir SOP şablonunu nerede bulabilirim?
Ürün desteği alanları olmadan standart yapıyı istiyorsanız, SOP şablonumuz bunu kapsar; IT SOP şablonumuz ise hangi prosedürlerin yazılmaya değer olduğuna nasıl karar verileceği dahil dahili teknik operasyonları kapsar.
Bir ekip kaç tane ürün desteği SOP’si yazmalı?
En yüksek hacimli temas nedenlerinizi kapsayan on ila on beş prosedür artı hacimden bağımsız olarak yüksek sonuçlu vakalar. Yaklaşık kırktan sonra bakım, bağlayıcı kısıt haline gelir ve gerçekten güncel olan daha küçük bir kütüphane, temsilcilerin güvenmemeyi öğrendiği büyük bir kütüphaneden daha iyidir.
Ürün desteği SOP’lerini kim yazmalı?
Deneyimli temsilciler; kütüphanenin sahibi olan kim varsa onun tarafından düzenlenmeli ve bilinen bir kusuru anlatan her şey için ürün veya mühendislik onayı alınmalıdır. Son inceleme, bir çözüm yolunu yerel bir düzeltme olmaktan çıkarıp görünür bir kusura dönüştüren şeydir; bu da bu sayfanın tüm argümanıdır.
Destek SOP’leri ne sıklıkla gözden geçirilmeli?
Takvime göre değil, ürün sürümlerine göre. Her firmware veya yazılım sürümü, değişen şeylere dokunan prosedürlerin kontrolünü tetiklemelidir. Her çeyrekte hacme göre ilk yirmi için döngüsel bir gözden geçirme ekleyin ve yükseltme üreten her şeyi yeniden doğrulayın.
Destek SOP’si mi, knowledge base makalesi mi: ne farklı?
SOP dahili bir dokümandır ve bir temsilcinin teması nasıl ele alacağını anlatır; neyin yükseltileceği ve neyin vaat edilmeyeceği dahil. Makale müşteriyle yüz yüzedir ve müşterinin bunu kendi başına nasıl çözeceğini anlatır. Genellikle aynı araştırmadan gelirler ve iyi bir makale teması tamamen ortadan kaldırdığı için birlikte yazılmalıdır.
