Yardım merkezi makale oluşturucu: destek taleplerini gerçekten azaltan 7 bölüm

Bir destek talebi aldınız. Şöyle diyor:

“Yardım makalesini takip ettim. İşe yaramadı.”

Makaleyi açıyorsunuz. Yeni. Dost canlısı. Hatta bir insanın yazdığına benzeyen sevimli bir giriş cümlesi bile var.

Ve bir şekilde, bir yardım makalesinin sahip olduğu tek işi yine de başaramıyor: kullanıcıyı tahmin yürütmek zorunda bırakmadan bitiş çizgisine ulaştırmak.

Otomatik yazılan yardım içerikleri hakkındaki rahatsız edici gerçek budur. Adımlar belirsiz olduğunda, ön koşullar eksik olduğunda ve sorun giderme kısmı “tekrar deneyin” dediğinde, “sıcak bir ton” için kimse bonus puan almaz.

Bir yardım merkezi makale oluşturucuyu değerlendiriyorsanız, onu şu standartta tutarım: genel geçer ifadeler değil, gerçek ürün durumları ve gerçek hata modlarıyla eşleşen, uygulanabilir ve test edilebilir talimatlar. Intercom’un kendi yardım içeriği türleri dökümü de temelde aynı şeyi haykırıyor: amaç önemlidir ve farklı makale türlerinin var olmasının bir nedeni vardır.

Bir yardım merkezi makale oluşturucu ne yapmalı#

Bir yardım merkezi makale oluşturucu, ürün bilgisini yapılandırılmış destek dokümantasyonuna dönüştüren bir sistemdir: net hedefler, eksiksiz ön koşullar, kontrol noktaları içeren numaralandırılmış adımlar ve gerçek hatalara bağlı sorun giderme. Ekiplerin müşteri self-servisini ölçeklendirmesine ve görev tamamlamayı hızlı ve net hale getirerek destek taleplerini azaltmasına yardımcı olur.

Destek taleplerini azaltan destek dokümantasyonu, görev başarısıyla başlar#

“Otomatik yazılmış” olması önemsizdir.

Önemli olan tek soru şudur: Bir kullanıcı, bir destek talebi açmadan görevi kendi başına hızlıca tamamlayabilir mi?

Ölçülebilir bir “harika” istiyorsanız, gerçeklikle eşleşen metrikler kullanın:

• Görev tamamlama oranı: kullanıcılar tırmandırma olmadan sona ulaşır.
• Yanıt süresi: sayfaya inişten başarıya kadar geçen süre.
• Talep azaltma oranı: destekle iletişime geçmeden çözülen sorunların yüzdesi (HubSpot, talebi azaltmayı temel bir self-servis metriği olarak tanımlar).
• Arama başarı oranı: kullanıcılar arama yaptıklarında doğru makaleyi buluyor mu.
• Takip sorusu oranı: sessiz katil. Kullanıcılar sürekli “bunu nerede bulabilirim?” diye soruyorsa, adımlarınız sızdırıyor demektir.

Ayrıca, müşteriler bunu istiyor. Zendesk, müşterilerin %91'inin ihtiyaçlarını karşılaması durumunda bir bilgi tabanı kullanacağını belirtti. O “eğer” çok fazla iş yapıyor.

Bu yüzden bir oluşturucuyu değerlendirirken “insan gibi mi duyuluyor?” diye sormayın.\n“Belirsizliği ortadan kaldırıyor mu?” diye sorun.

Ön koşullar havada kaldığında müşteri self-servisi bozulur#

Otomatik yazılan makalelerin çoğu 1. Adımdan önce başarısız olur.

Adımlar yanlış olduğu için değil. Makale, adımların çalışabileceği koşulları asla belirtmediği için.

Bir oluşturucunun, ön koşulları bir mühendisin bağımlılıkları yönettiği gibi yönetmesi gerekir:

• İzinler ve rol (yönetici ve üye akışları genellikle farklılaşır)
• Plan kademesi ve haklar (bunu asla tahmin etmeyin)
• Özellik bayrakları ve beta durumları
• Başlangıç durumu (“X'in zaten oluşturulmuş olması gerekir”)
• Veri gereksinimleri (örnek veri, API anahtarları, doğrulanmış alan adı vb.)
• Platform (web, mobil ve masaüstü farklılıkları)

Microsoft’un prosedürlerle ilgili stil rehberi, insanların keyif alabileceği hisler değil, insanların takip edebileceği talimatlar yazma konusunda nettir.

Kuralım: genel ön koşullar hiç olmamasından daha kötüdür çünkü yanlış bir güven duygusu yaratırlar. “Erişiminiz olduğundan emin olun”, dokümantasyon dünyasında “daha uzun boylu olun” demenin eşdeğeridir.

İyi bir oluşturucu, erişimin “nereden doğrulanacağı” (ayarlar sayfası, yönetici konsolu, faturalandırma sayfası) dahil olmak üzere kesinliği zorunlu kılmalıdır. Doğrulayamıyorsa, kendinden emin bir yalan değil, bir doğrulama adımı çıkarmalıdır.

Harika bir oluşturulmuş makalenin anatomisi#

İşte her seferinde gerektirdiğim yapı. İstisnasız.

Hedef#

İyi bir sonuç neye benzer:

• Bitiş durumunu test edilebilir terimlerle belirtir: “X etkinleştirilmiş ve Y'de görünür olacak.”
• Kime uygulandığını belirtir (roller, planlar, platformlar).
• Ne zaman kullanılmaması gerektiğini belirtir. Intercom, amaç konusunda net olmayı ve makale türünü işle eşleştirmeyi vurgular.

Kötü hedef: “Panoların nasıl kullanılacağını öğrenin.”\nİyi hedef: “Sonunda, bir pano oluşturacak ve ekibinizle paylaşacaksınız.”

Ön koşullar#

İyi bir sonuç neye benzer:

• Rol, plan, özellik bayrakları
• Gerekli girdiler (API anahtarı, CSV, alan adı)
• Başlangıç durumu (zaten neyin var olması gerektiği)
• Erişimin “nereden doğrulanacağı”

Oluşturucu plan kısıtlamasını doğrulayamıyorsa, şunu yazmalıdır:\n“Planınızın X'i içerdiğini doğrulayın: Ayarlar → Faturalandırma → Plan detayları kısmına gidin.”

Bu cümle destek taleplerini kurtarır.

Adımlar#

Adımlar operatör düzeyinde olmalıdır: belirsiz olmayan, taranabilir, dayanıklı.

Microsoft’un kullanıcı arayüzü yazma rehberi, girdiden bağımsız talimatları ve tutarlı fiilleri zorlar.

İyi bir sonuç neye benzer:

• Görev tabanlı alt başlıklara sahip numaralandırılmış bir prosedür
• Her adım konum ile başlar, ardından eylem gelir
• Her adım bir beklenen sonuç kontrol noktası içerir

Örnek model (işin püf noktası budur):

1. Ayarlar → Bildirimler kısmında, E-posta uyarıları'nı seçin.\n Beklenen sonuç: E-posta uyarıları “Açık” olarak görünür.

O “beklenen sonuç” satırı süs değildir. Sessiz başarısızlığı önleyen ve “yaptım ama hiçbir şey olmadı” taleplerini azaltan yerleşik bir kendi kendini kontrol mekanizmasıdır.

Notlar ve uç durumlar#

Notlar, bilgi göstermek için değil, destek taleplerini durdurmak için vardır.

İyi bir sonuç neye benzer:

• Platform farklılıkları (web vs mobil)
• Rol farklılıkları (sadece yönetici düğmeleri)
• Özellik bayrağına göre kullanıcı arayüzü varyasyonları
• Sert sınırlar (hız sınırları, maksimum dosya boyutları)

Kısa tutun. Bir not kafa karışıklığını veya başarısızlığı önlemiyorsa, silin.

Sorun giderme#

Yapay zeka taslaklarının genellikle çuvalladığı yer burasıdır.

NN/g’nin hata mesajlarıyla ilgili rehberliği şu noktaya varır: hataları görünür, net ve yapıcı hale getirin. Bu zihniyet doğrudan sorun giderme bölümlerine uygulanır.

İyi bir sonuç neye benzer:

• Belirti → muhtemel neden → çözüm → nasıl doğrulanır
• Mümkün olduğunda tam hata metni
• Destek taleplerine, kayıtlara veya makrolara dayalı (hayal gücüne değil) en iyi 3 hata modu

Örnek:

Belirti: “Bu işlemi gerçekleştirmek için izniniz yok.”\nMuhtemel neden: Yönetici değil, üyesiniz.\nÇözüm: Bir yöneticiden Ayarlar → Ekip → Roller kısmından “Entegrasyonları yönet” izni vermesini isteyin.\nDoğrulama: Sayfayı yenileyin ve Entegrasyonlar menüsünün göründüğünü kontrol edin.

Bu destek düzeyindedir. Bunun dışındaki her şey bir omuz silkmedir.

SSS#

SSS, artıkları boşaltmak için değil, dallanmayı azaltmak için olmalıdır.

Intercom, SSS'leri nasıl yapılır ve sorun gidermeden bir nedenle ayırır. Farklı işler, farklı şekiller.

İyi SSS'ler, “Bu mobil cihazda çalışıyor mu?” veya “Bunu geri alabilir miyim?” gibi akışa temiz bir şekilde uymayan yüksek frekanslı sorulardır.

Oluşturulan yardım makalelerini incelemek için 60 saniyelik bir değerlendirme cetveli#

Ekibiniz bir yapay zeka taslağını hızlıca değerlendiremiyorsa, asla tutarlı bir şekilde yayın yapamazsınız.

İncelemeleri hızlı ve acımasız tutmak için kullandığım bir cetvel:

Her birini 0'dan 2'ye kadar puanlayın. Toplam ≥ 8/10 ise yayınlayın.

1. Sonuç netliği

• 0: belirsiz hedef
• 1: hedef var ama test edilebilir değil
• 2: belirli bitiş durumu + kapsam sınırları

1. Ön koşulların eksiksizliği

• 0: eksik ön koşullar
• 1: kısmi (rol VEYA plan VEYA başlangıç durumu)
• 2: rol + plan + başlangıç durumu + nereden doğrulanacağı

1. Adım kalitesi

• 0: belirsiz adımlar (“gidin”, “şeye tıklayın”)
• 1: çoğunlukla net, kontrol noktaları eksik
• 2: konum → eylem → beklenen sonuç tutarlı

1. Kurtarma kalitesi

• 0: sorun giderme yok
• 1: genel sorun giderme
• 2: belirti → neden → çözüm → doğrula, gerçek hatalara bağlı

1. Güven sinyalleri

• 0: tazelik göstergesi yok
• 1: sadece tarih
• 2: “Son doğrulama” + kapsam notları (platform/rol) + bilinen bilinmeyenler

Oluşturucunun neleri çıkarması ve neleri tahmin etmekten kaçınması gerektiği#

Bir yardım merkezi makale oluşturucu, gerçek sinyallerden çıkarabileceği şeyleri çıkarmalıdır:

• kullanıcı niyeti ve görev sınırları
• kararlı kullanıcı arayüzü öğeleri
• gözlemlenebilir olduğunda gerekli izinler
• durum geçişleri (“kaydettikten sonra X'i göreceksiniz”)

Ancak şunları tahmin etmemelidir:

• plan kısıtlaması
• güvenlik etkileri
• geri alınamaz eylemler
• ürün gerçekliğine dayandıramadığı her şey

Buradaki favori modelim, bilinen-bilinmeyenler bloğu olarak adlandırdığım şeydir:

“Eğer X'i görmüyorsanız, Y'yi doğrulayın. Eğer Y doğruysa ve X hala görünmüyorsa, destek ekibiyle iletişime geçin ve Z ekran görüntüsünü ekleyin.”

Mütevazı ama kullanışlı. Ayrıca üreticinin halüsinasyon görmesini engelliyor.

Üretim gerçeği: tutarlılık, yazım yeteneğinden üstündür#

Dokümantasyon bakımı yapmıyorsunuz. Yerinde durmayan bir ürünün yaşayan haritasını yönetiyorsunuz.

Help Scout, bilgi tabanını self-servisin omurgası olarak tanımlıyor ve bunun anlamı çok açık: omurga eskirse, her şey acı verir.

Bu yüzden sürdürülebilirliği bir gereklilik haline getirin:

• Mümkün olduğunda temel amacı kırılgan kullanıcı arayüzü etiketlerinden ayırın
• Bir tazelik iş akışı ekleyin: “Son doğrulama tarihi: YYYY-AA-GG”
• Makale başına “UI değişim riski”ni takip edin (yüksek riskli sayfalar her sürümde gözden geçirilir)

Clevera'yı taklit edilmesi en zor şeyden, yani gerçek iş akışından yola çıkarak inşa etmemizin nedeni de bu. Clevera, bir ekran kaydını ilgili ekran görüntüleriyle adım adım bir makaleye dönüştürür, ardından Notion benzeri bir düzenleyicide düzenlemenize ve Help Scout, Notion veya Confluence gibi platformlara aktarmanıza olanak tanır.

Ürününüz hızlı güncelleniyorsa, o “bir kez kaydet, oluştur, düzenle, dışa aktar” döngüsü kusursuz bir metinden daha önemlidir.

Bağlamsal CTA: Üreticinin her seferinde tutarlı bir yapı sunmasını istiyorsanız, Clevera'nın dokümantasyon iş akışı (/features/docs) ile başlayın ve bunu makalenin en üstündeki eşleşen bir video eğitim sürümü (/features/video-tutorials) ile eşleştirin.

Yayınlamadan önceki QA kapıları (böylece müşteriler sizin yerinize QA yapmaz)#

Yapay zeka taslakları, insan taslaklarıyla aynı yayın disiplinini hak eder. Belki daha fazlasını.

İşte uygulayacağım kapılar:

Kapı 1: “soğuk deneme” testi#

Taslağı, özelliği geliştirmemiş birine verin.

Eğer tek seferde tamamlayamazlarsa, makale başarısızdır. Tartışmaya kapalı.

Kapı 2: prosedür formatı kontrolü#

Google'ın stil kılavuzunda prosedürler ve hatta tek adımlı biçimlendirme hakkında özel rehberlik bulunur. Bunu temeliniz olarak kullanın.

Kontrol listesi:

• çok adımlı görevler için numaralandırılmış adımlar
• adım başına bir eylem
• tutarlı fiiller
• adımlar içinde gizli dallanma yok

Kapı 3: sorun giderme gerçekle eşleşmelidir#

Her sorun giderme öğesi şunlarla eşleşmelidir:

• bir bilet etiketi kategorisi, veya
• bir destek makrosu, veya
• bir hata günlüğü modeli

Eğer gerçekle bağdaştıramıyorsanız, kesin atın.

Kapı 4: taranabilirlik için cümle düzeninde başlıklar#

Bu küçük bir detay gibi görünebilir, ancak tutarlılık bilişsel yükü azaltır.

Google'ın stil kılavuzu bile açıkça başlıklar ve isimler için cümle düzenini önerir.

Kapı 5: tazelik ve kapsam etiketleri#

Ekleyin:

• güncellenme tarihi
• platform
• rol
• “son doğrulama” (dahili olması yeterli)

Otomatik yazılan yardım içeriklerinde gördüğüm yaygın başarısızlık modları#

Acıyı önlemek istiyorsanız, şunlara dikkat edin:

• Kontrol noktaları olmayan adımlar (sessiz başarısızlığa yol açar)
• Zor kısımlardan kaçan ön koşullar (plan, izinler, başlangıç durumu)
• Herkese uyan tek tip akışlar (yönetici ve üye yollarının birbirine karışması)
• Çözmek yerine özür dileyen sorun giderme
• Ekran görüntüsü spam'i (ekran görüntüleri net olmayan talimatları kurtaramaz)

Ekran görüntüleri yardımcı olur, ancak yalnızca hedefe yönelik olduklarında. Görseller ekliyorsanız, onları açıklayın: oklar, kutular, adım numaraları.

Kaliteyi gerçekten önemsediğinizde Clevera nerede devreye girer#

Eğer yardım merkezi makale oluşturucunuz sadece metin istemlerinden başlıyorsa, kullanıcı arayüzü gerçekliği hakkında tahminde bulunuyor demektir.

Clevera doğrudan iş akışından başlar: görevi kaydedersiniz, ardından Clevera cilalı bir video ve ekran görüntüleri ile düzenlenebilir yapıya sahip ayrıntılı bir makale üretir; böylece güncellemeler haftalar süren yazım sprintleri yerine dakikalar içinde tamamlanır.

Bu, haftalık kullanıcı arayüzü değişiklikleri yayınlayan, sınırlı yazım kapasitesine sahip ve birbirinin ayağına basmamaya çalışan birden fazla katkıda bulunanın olduğu ekipler için önemlidir.

Hızlı SSS (zombi olmayan sürüm)#

Bir yardım merkezi makale oluşturucusu her seferinde hangi bölümleri içermelidir?
Amaç, ön koşullar, beklenen sonuçları içeren numaralandırılmış adımlar, kapsamlı notlar, sorun giderme (belirti → neden → çözüm → doğrulama) ve sık sorulan dallanma soruları için küçük bir SSS.

Bir yardım merkezi makale oluşturucusu gerçekten destek biletlerini azaltabilir mi?
Evet, eğer belirsizliği en aza indirir ve gerçek sorun giderme adımlarını içerirse. Eğer sadece metni yeniden yazıyorsa, yanlış bir güven yaratarak bilet sayısını artırabilir.

Farklı roller ve plan seviyeleri için ön koşulları nasıl yazarsınız?
Rolü ve planı en başta belirtin, “nerede doğrulanır” kontrolleri ekleyin ve yönetici ile üye ekranları farklılaştığında akışı bölün. Oluşturucunun plan kısıtlamalarını tahmin etmesine asla izin vermeyin.

Yapay zeka tarafından oluşturulan yardım makaleleri için en hızlı QA yöntemi nedir?
60 saniyelik değerlendirme ölçeğini uygulayın, ardından uzman olmayan biriyle “soğuk deneme” testi yapın. Eğer tereddüt ederlerse veya doğaçlama yaparlarsa, adımlar uygulanabilir olana kadar yeniden yazın.

Yapay zeka tarafından oluşturulan makaleler ekran görüntüleri içermeli mi?
Evet, ancak yalnızca açıklama ile ve yalnızca görseller belirsizliği gideriyorsa. Ekran görüntüleri net olmayan adımların yerini tutamaz.

Sizin meydan okumanız#

En iyi 10 bilet sürücünüzden birini seçin ve yukarıdaki değerlendirme ölçeğinden geçirin.

Eğer makale 10 üzerinden 8'in altında puan alırsa, girişi yeniden yazmayın. Ön koşulları düzeltin, kontrol noktaları ekleyin ve gerçek hatalara bağlı gerçek sorun giderme adımları yazın.

Ardından bir sonraki sürüm döngüsünde bilet hacmine ne olduğuna bakın.