Deskhero
Türkçe
Ücretsiz deneyin

← Back to articles

Ekipler İçin Dahili Bilgi Bankası: Kullanılan Bir Sistem Kurun

Ekipler İçin Dahili Bilgi Bankası: Kullanılan Bir Sistem Kurun

Dahili bir bilgi tabanı, ekibinizin prosedürleri, çalışma kılavuzlarını, politikaları, işe alım adımlarını ve geçmiş kararları sakladığı merkezi ve aranabilir alandır; böylece hiç kimsenin aynı soruyu iki kez sorması gerekmez. Bunu zaten biliyor ve harekete geçmek istiyorsanız, bu hafta başlayabileceğiniz yer burasıdır.

  • En sık tekrarlanan 20 sorunuz için son bir aylık Slack ve e-posta yazışmalarını denetleyin.
  • Tek bir makale bile yazmadan önce, her üst düzey kategori için adı belirli tek bir sorumlu atayın.
  • Yalnızca bu önemli soruları kapsayan 20 makalelik bir pilot uygulama başlatın, ardından kapsamı genişletin.

Bu üç şeyi yaptığınızda sonuçları hızla görürsünüz: çalışanları derin çalışmadan koparan daha az kesinti ve her saat komşusunun omzuna dokunmayı bırakan yeni işe alınanlar. Bu kılavuzun geri kalanında bunun neden işe yaradığını ve nasıl doğru şekilde oluşturulacağını ele alıyoruz.

Önemli Çıkarımlar

İşe yarayan bir dahili bilgi tabanı; her kategori için adı belirli bir sorumlu, gerçek sorulardan oluşturulmuş 20 makalelik bir pilot uygulama ve içeriğin güvenilir kalmasını sağlayan 90 günlük bir inceleme döngüsüyle başlar.

Nokta Ayrıntılar
Gerçek sorularla başlayın Herhangi bir şey yazmadan önce, en sık tekrarlanan 20 sorunuz için son 30 ila 60 günlük Slack ve e-posta yazışmalarını denetleyin.
Her kategori için bir sorumlu belirleyin Her üst düzey kategorinin hesap verebilir sorumlusu olarak bir ekip değil, belirli bir kişi atayın.
Sınıflandırmayı küçük tutun Organizasyon şemanızı kopyalamak yerine, işlevlere dayalı az sayıda üst düzey kategori kullanın.
Bir inceleme sıklığı belirleyin Politika değişiklikleri için anında inceleme yapmak üzere her makaleye 90 günlük bir “son incelenme” döngüsü ekleyin.
KB’yi yapay zekâyla güvenli şekilde eşleştirin Deskhero's chatbot ve AI auto-replies yalnızca onaylanmış herkese açık FAQ öğelerinden yanıt verir. Bu özellikler isteğe bağlıdır; otomatik işlemler etiketlenir ve kayda alınır.

İçindekiler

Bir Dahili Bilgi Tabanı, Kendisine Verilenden Daha Fazla Önem Taşır

Şirket bilgi tabanının gerekliliği soyut bir konu değildir. Gartner tarafından yapılan bir ankete göre dijital çalışanların önemli bir bölümü işlerini yapabilmek için ihtiyaç duydukları bilgileri bulmakta zorlanıyor. Bu, şu anda iş gücünüzün neredeyse yarısının, eski bir Slack yazışmasında veya birinin gelen kutusunda zaten var olan bir yanıtı bulmak için sessizce zaman kaybettiği anlamına gelir.

Rakamlarla: Dijital çalışanların büyük bir bölümü işlerini yapmak için ihtiyaç duydukları bilgileri güvenilir biçimde bulamıyor. Yanıtlanmamış her “X belgesini nerede bulabilirim?” sorusu, bu istatistiğin ekibinizde gerçek zamanlı olarak yaşanmasıdır.

İşleyen bir dahili dokümantasyon sistemi bu soruna doğrudan müdahale eder. İnsanlar sormak yerine arama yaptığı için yanıt bulma süresini kısaltır. Bir konu uzmanı daha önce beş kez açıkladığı bir şeyi tekrarlamak için işinden koparılmadığından, bağlam değiştirme maliyetini azaltır. Yeni işe alınan bir çalışan, kıdemli bir mühendisin takviminde zaman beklemek zorunda kalmadan dağıtım kontrol listesini bulabildiği için işe alım sürecini kısaltır.

Faydalar birkaç öngörülebilir noktada ortaya çıkar:

  • Yeni işe alınanlar için daha hızlı işe uyum; çünkü ilk hafta sorularının, birinin zihninde kilitli kalan kurumsal bilgi yerine yazılı yanıtları vardır.
  • Yanıt aranabilir bir yerde bulunduğu ve kapalı bir yazışmada kalmadığı için daha az tekrarlanan destek talebi veya Slack mesajı.
  • İnsan arama motoru gibi çalışmayı bırakan kıdemli çalışanlar için daha az bağlam değiştirme.
  • Herkes beş farklı sözlü açıklama yerine aynı kaynaktan bilgi aldığı için daha tutarlı yanıtlar.

Kendi ekibiniz için kabaca bir hesap yapın: Beş kişi, bir ekip bilgi tabanının yanıtlayabileceği soruları yanıtlamak için her gün 20'şer dakika harcarsa, haftada sekiz saatten fazla kıdemli çalışan zamanı geri kazanılır. Bunu bir çeyrek döneme yaydığınızda, tek bir yeni çalışan almaya bile gerek kalmadan fayda kendini gösterir.

Öncelikle Bilgi Tabanınızda Neler Yer Almalı?

Hiçbir dahili dokümantasyon aracının ilk günden her şeyi barındırması gerekmez. Tüm şirketi aynı anda belgelemeye çalışmak, bilgi tabanı projelerinin çoğunun kullanıma sunulmadan önce durmasının nedenidir. İnsanların birbirlerinin sözünü kesmesini gerçekten engelleyen içerik türleriyle başlayın.

Şu sırayla önceliklendirin:

  1. Tekrarlanan acil durumlar için çalışma kılavuzları ve sorun giderme rehberleri (sunucuyu yeniden başlatma prosedürü, geri ödeme iş akışı, yaygın bir hata düzeltmesi).
  2. İlk hafta ve ilk ay için işe alım kontrol listeleri.
  3. Sürekli sorulan politikalar (ücretli izin, masraf onayı, uzaktan çalışma kuralları).
  4. Tekrarlanabilir görevler için nasıl yapılır makaleleri (erişim talep etme, satın alma siparişi gönderme).
  5. Altı ay sonra kimsenin aynı konuyu yeniden tartışmaması için bir şeyin neden seçildiğini açıklayan karar kayıtları.
  6. Yeni işe alınanların kafasını karıştıran kurum içi jargon ve kısaltmalar için terim sözlükleri.
  7. En çok sorulan destek ve dahili sorularınızdan doğrudan oluşturulan SSS’ler.
  8. Ekibinizin tekrar tekrar yazdığı belgeler için şablonlar.

İlham alabileceğiniz birkaç örnek sayfa biçimi:

  • SOP veya çalışma kılavuzu şablonu: tetikleyici koşul, adım adım işlemler, kime eskale edileceği, beklenen çözüm süresi.
  • İlk hafta işe alım kontrol listesi: kurulacak hesaplar, tanışılacak kişiler, ilk teslimat, takıldığınızda kime sorulacağı.
  • Kısa politika sayfası: üstte tek paragraflık özet, ardından tüm ayrıntılar ve son olarak istisnalar bölümü.

Türü ne olursa olsun her makalenin en üstünde aynı meta veriler bulunmalıdır: bir sorumlu, bir son incelenme tarihi, bir durum etiketi (güncel, inceleme gerekli, arşivlendi) ve aramanın yalnızca resmî terimi değil, insanların soruyu gerçekten ifade etme biçimini de yakalayabilmesi için birkaç alternatif ad.

Dahili Bilgi Tabanı Nasıl Oluşturulur ve Yapılandırılır?

Üçüncü aydan sonra da varlığını sürdüren bir çalışan bilgi veritabanı oluşturmak, işleri doğru sıraya koymaya bağlıdır. Denetimi atlayıp doğrudan yazmaya başlarsanız, kimsenin aramadığı makalelerle sistemi doldurursunuz. İşte yaklaşık dört haftada uygulayabileceğiniz, aşamalara ayrılmış bir plan.

Dört aşamalı dahili bilgi tabanı oluşturma zaman çizelgesi

1. Aşama: Denetim (1. ila 5. Günler)

İnsanların gerçekten sorduğu soruları çıkarın. Tekrarlanan temalar için son 30 ila 60 günlük Slack, e-posta ve destek taleplerinizi arayın. En güvenilir başlangıç noktası, bölümünüzün teorik olarak belgeleyebileceği her şeyin varsayımsal bir listesi değil, çalışanların gerçekten sorduğu en önemli 20 sorudur.

  • Kim: projeden sorumlu kişi; üç veya dört bölüm yöneticisinden bilgi toplar.
  • Ne: en sık tekrarlanan 20 ila 30 sorunun sıralanmış listesi.
  • Teslimat: soru, tahmini sıklık ve önerilen sorumluyu içeren bir elektronik tablo.
  • Kabul kriterleri: listedeki her soru denetim döneminde en az iki kez sorulmuş olmalıdır.

2. Aşama: Sınıflandırma ve Sorumluluk (6. ila 10. Günler)

Ayrıntılı bir kategori ağacı oluşturma isteğine direnin. İşlevlere göre düzenlenmiş az sayıda üst düzey kategori, kullanılabilir bir sınıflandırma oluşturur. Organizasyon şemanızı kopyalamak yerine “Başlarken”, “BT ve Erişim”, “İK ve Politikalar” ve “Müşteri Destek Prosedürleri” gibi başlıklar düşünün. Her üst düzey kategori için adı belirli tek bir sorumlu atayın. Bir ekip değil. Bir kişi. Bir isme bağlanmayan sorumluluk, makalelerin çürümesinin yoludur.

  • Kim: yazılı olarak onaylanmış kategori sorumluları.
  • Ne: işlevlere dayalı üst düzey kategorilerden oluşan özlü bir sınıflandırma.
  • Teslimat: her dalın yanında sorumlunun adının yer aldığı bir sınıflandırma haritası.
  • Kabul kriterleri: her kategorinin, görevi kabul etmiş tam olarak bir hesap verebilir sorumlusu olmalıdır.

3. Aşama: Pilot Uygulamayı Oluşturma (11. ila 20. Günler)

20 makalelik pilot uygulamayı doğrudan denetim listenizden yazın. Her makalenin aynı biçime sahip olması için önceki bölümdeki şablonları kullanın. Eski vikinin tamamını buraya taşımayın. Yakın zamanda gerçekten kullanılmış veya referans verilmiş içerikleri seçerek aktarın, eski ya da yarım kalmış görünen her şeyi yeniden yazın ve geri kalanını alışkanlıkla ileri taşımak yerine arşivleyin.

  • Kim: her biri kendi makalelerini yazan veya atayan kategori sorumluları.
  • Ne: pilot uygulamanın en önemli sorularına karşılık gelen 20 tamamlanmış makale.
  • Teslimat: yazarın ekibi dışından en az bir kişi tarafından incelenmiş, yayımlanmış bir pilot bölüm.
  • Kabul kriterleri: test okuyucusu, takip sorusu sormadan her makaleyi iki dakikadan kısa sürede bulabilmeli ve anlayabilmelidir.

4. Aşama: Aramayı Entegre Etme ve Kademeli Kullanıma Sunma (21. ila 28. Günler)

Bilgi tabanını ekibinizin gününü zaten geçirdiği yerlere, ister Slack, Microsoft Teams ister destek talebi aracınız olsun, bağlayın. Ayrı bir sekme açmayı gerektiren bir KB’nin varlığı unutulur. Önce tek bir bölüme kademeli olarak sunun, geri bildirim toplayın, bariz eksikleri giderin ve ardından şirket genelinde kullanıma açın.

  • Kim: proje sorumlusu ve pilot bölümlerden bir veya iki gönüllü.
  • Ne: arama entegrasyonu ve kısa bir dahili duyuru.
  • Teslimat: ilk iki haftaya ait kullanım verileri ve geri bildirim maddeleri listesi.
  • Kabul kriterleri: pilot grubun en az yarısı, ilk on gün içinde herhangi bir yönlendirme olmadan KB’yi kullanmış olmalıdır.

Uzman İpucu: Kendinizi rahat hissettiğinizden daha dar bir kapsamla kullanıma sunun. Gerçekten kullanılan, sıkı kapsamlı 20 makalelik bir pilot, göz ardı edilen geniş kapsamlı 200 makalelik bir yığından çok daha fazla kurum içi güven oluşturur.

Tamamlandı olarak işaretlemeden önce bulunabilirliği test edin. İçeriği yazma sürecine dahil olmayan birine beş gerçek soru verin ve yanıtı bulmasının ne kadar sürdüğünü ölçün. Bir dakikadan uzun sürüyorsa daha fazla makaleye değil, sınıflandırmanızın veya etiketlemenizin iyileştirilmesine ihtiyacınız vardır.

Gereğinden Fazla Düşünmeden Doğru Bilgi Tabanı Aracını Seçme

Gereğinden Fazla Düşünmeden Doğru Bilgi Tabanı Aracını Seçme, genel bakış diyagramı

Araç seçimi birçok ekibi felç eder. Çözüm, kısa bir kontrol listesi ve boyutunuz için neyin olmazsa olmaz, neyin tercih sebebi olduğunu net biçimde bilmektir.

Aday bilgi yönetimi platformlarını şu kontrol listesinden geçirin:

  • Yalnızca tam anahtar kelime eşleşmelerini değil, yazım hatası toleransını ve eş anlamlı eşleşmesini de içeren arama kalitesi.
  • Hassas İK veya finans sayfalarının herkes tarafından görülememesi için SSO ve ayrıntılı izinler.
  • Yanıtların insanların zaten iletişim kurduğu yerde görünmesi için Slack veya Microsoft Teams entegrasyonu.
  • Özellikle ileride yapay zekâ asistanları bağlamayı planlıyorsanız bir API veya temiz dışa aktarma özelliği.
  • Hangi makalelerin görüntülendiğini, hangi aramaların sonuç vermediğini ve insanların nerede vazgeçtiğini gösteren analizler.
  • Hantal bir yazma aracı daha az katkı yapılmasını garanti edeceği için rahat bir düzenleyici deneyimi.
  • Atanabilir incelemeciler ve görünür son güncelleme tarihleri gibi içerik sahipliği özellikleri.

Her adayı genel bir özellik listesine göre değil, kendi ölçeğinize göre değerlendirin:

  1. Küçük ekipler (30 kişinin altında): arama, izinler ve düzenleyici deneyimi olmazsa olmazdır. Ayrıntılı analizler ve API erişimi tercih sebebidir.
  2. Orta ölçekli ekipler: Slack veya Teams entegrasyonunu ve temel analizleri olmazsa olmazlar listesine ekleyin.
  3. Kurumsal ekipler: uyumluluk ve ölçek bunları gerektirdiği için API erişimi, SSO ve ayrıntılı izinler tercih sebebi olmaktan çıkarak olmazsa olmaz hâline gelir.

Ürünleri karşılaştırırken bir satış sayfasındaki özellik listesinin uzunluğuna güvenmek yerine, arama kalitesini ve yönetici kontrollerini kendi içeriğiniz ve izin modelinizle test edin. İleride yapay zekâyı üzerine eklemeyi planlıyorsanız markdown veya temiz bir API sunan araçları tercih edin; yapılandırılmış içerik, tutarsız biçimlendirmelerle dolu bir yığına kıyasla erişim sistemlerinin tutarlı şekilde kullanması için daha kolaydır.

Yanıtları Gerçekten Bulunabilir Hale Getirme

Kimsenin bulamadığı bir bilgi tabanı, yalnızca markası daha iyi olan bir dosya dolabıdır. Bulunabilirlik, dahili dokümantasyon araçlarının çoğunun sessizce başarısız olduğu noktadır ve birkaç somut alışkanlıkla düzeltilebilir.

Resmî bir başlığı nasıl yazacağınız için değil, insanların gerçekten nasıl arama yaptığı için etiketleyin. Faturalandırma politikası makalenizin başlığı “Alacak Hesapları Prosedürleri” ise ancak herkes “geri ödemeyi nasıl alırım?” diye arıyorsa bu ifadeyi alternatif ad olarak ekleyin. Yaygın yazım hatalarını ve kısaltmaları da ekleyin. Ardından içeriği KB’nin kendi arama çubuğundan çıkarıp insanların her gün kullandığı araçlara taşıyın; bu, doğrudan KB makalelerinden yanıt veren bir Slack botu veya destek talebi sisteminizin içindeki bir araç olabilir.

Üst düzey sınıflandırmayı işlevlere göre düzenli tutun, her kategori içinde aynı makale türünü tutarlı biçimde kullanın ve fark ettiğiniz anda yinelenen sayfaları kaldırın; aynı politikaya biraz farklı yanıtlar veren iki sürüm, hiç sayfa olmamasından daha kötüdür.

Aramanın gerçekten işe yarayıp yaramadığını üç metrik gösterir:

  • Sıfır sonuç oranı: bir aramanın ne sıklıkla hiçbir sonuç döndürdüğü; eksik içeriği veya kötü etiketlemeyi gösterir.
  • Aramadan makaleye tıklama oranı: insanların bir sonuca tıklayıp tıklamadığını veya vazgeçip bunun yerine bir kişiye soru sorup sormadığını gösterir.
  • Slack veya sohbet aracınız içindeki ilk yanıt süresi; otomatik ya da KB kaynaklı bir yanıtın insan yanıtından daha hızlı olup olmadığını izler.

Sıfır sonuç oranınız yükseliyorsa bu, içerik sorunundan önce bir sınıflandırma ve etiketleme sorunudur. Bulunabilirlikle ilgili önceki noktaya dönersek: çalışanların neredeyse yarısı zaten bilgiyi bulmakta zorlandığını bildiriyor; dolayısıyla kendi KB aramanızdaki yüksek sıfır sonuç oranı, bunu düzeltmek üzere tasarlanmış bir aracın içinde aynı başarısızlığın yaşanmasıdır.

Bilgi Tabanını Zaman İçinde Güvenilir Tutma

Kimse onu izlemekle görevlendirilmediği anda bir bilgi tabanı eskimeye başlar. Yönetişim, ikinci yılında hâlâ yararlı olan bir KB’yi güncelliğini yitirmiş ekran görüntülerinin sessizce biriktiği bir mezarlıktan ayıran şeydir.

Üç rolü net biçimde tanımlayın:

  • Her kategori için doğrudan sorumlu kişi (DRI); sınıflandırma aşamanızdaki aynı adı belirli sorumlu, doğruluktan hesap verebilir.
  • Editörler; küçük düzeltmeler için DRI onayı gerekmeksizin içeriği güncelleyebilir.
  • İncelemeciler; birinin sorunu fark etmesini beklemek yerine, belirlenmiş bir programa göre doğruluğu kontrol eder.

Bazı ekipler KB birkaç yüz makaleyi aştığında bilgi operasyonları komitesi ekler; ancak çoğu kuruluş için her kategoriye atanmış net bir DRI başlangıçta yeterli yapıyı sağlar.

Yalnızca kullanıma sunulma tarihi değil, her makale için bir inceleme sıklığı belirleyin. Çoğu operasyonel içerik için 90 günlük inceleme döngüsü iyi çalışır: her makalede bir “son incelenme” alanı bulunur ve inceleme yapılmadan 90 günü aşan her içerik DRI’si için işaretlenir. Politika değişikliğiyle bağlantılı içerik, kendi sırasını beklemek yerine döngü dışı derhâl incelenir.

  1. Okuyucular fark etmeden önce ihmali gösteren inceleme tarihini aşmış makalelerin yüzdesini takip edin.
  2. İçerik boşluklarını gösteren sıfır sonuç döndüren aramaların yüzdesini takip edin.
  3. Gerçekte nelerin kullanıldığını görmek için makale başına tekil ziyaretçileri ve görüntülemeleri, yani benimsenme oranını takip edin.
  4. KB mevcut olmadan önce ve olduktan sonra bir sorunun çözülmesinin ne kadar sürdüğünü karşılaştırarak yanıt süresindeki iyileşmeleri takip edin.

Uzman İpucu: “Son incelenme” tarihini bir yönetici paneline gömmek yerine doğrudan makalenin üzerinde, okuyucuların görebileceği şekilde gösterin. Bir tarih görmek güven oluşturur; tarih görememek ise güveni sessizce aşındırır.

Yapay Zekânın Tahmin Yürütmesine İzin Vermeden Kullanılması

Yapay zekâ, doğru koruma mekanizmalarıyla sınırlandırıldığında ekibin bilgi tabanını kullanma hızını anlamlı ölçüde artırabilir. Denetimsiz bırakılırsa yapay zekâ asistanı, bilmediğini kabul etmek yerine kulağa güven verici gelen bir yanıtı memnuniyetle uydurur.

Yararlı uygulamalar belirgindir: onaylanmış makalelerden oluşan kontrollü bir kümeden yanıt veren bir chatbot, gönderilmeden önce bir insanın incelediği yapay zekâ taslaklı yanıtlar, bir Kullanıcıya destek talebi devam ederken gösterilen ilgili makaleler ve ekibinizin daha önce çözdüğü taleplerden oluşturulan SSS önerileri.

Bunların hiçbiri koruma mekanizmaları olmadan güvenli biçimde çalışmaz:

  • Yapay zekânın açık internetten veya kendi eğitim verilerinden değil, yalnızca onaylanmış içerikten bilgi almasını sağlayan kaynakla sınırlandırılmış yanıtlar.
  • Taslakların gönderilmeden önce kontrol edilmesini ve otomatik gönderimin bilinçli olarak etkinleştirilmesini sağlayan insan incelemesi ve açık kontroller.
  • Her otomatik işlemin geriye dönük izlenebilmesini ve daha sonra incelenebilmesini sağlayan kayıtlar ve denetim izleri.
  • Düşük güvenli yanıtların tahmin yürütmek yerine bir insana aktarılmasını sağlayan güven eşikleri.

Uzman İpucu: Yapay zekâ asistanınızın doğruluk oranını diğer tüm KPI’lar gibi ele alın. Yanıtlarının bir örneklemini her hafta rastgele kontrol edin; yanlış yanıtlar artmaya başlarsa bu, ilerlemeyi sürdürmek yerine kaynak içeriği yeniden dizine eklemeniz gerektiğinin işaretidir.

Deskhero’s Yaşayan Bilgi Tabanı Yaklaşımı

Herhangi bir dahili bilgi merkezini test etmenin yararlı bir yolu, statik bir wiki olarak kenarda durmak yerine taleplerde gerçekleşen çalışmaya bağlanıp bağlanmadığına bakmaktır. Deskhero’da çözümlenmiş talepler, önerilen herkese açık SSS öğelerine katkıda bulunabilir. Müşteriye dönük chatbot veya yapay zekâ otomatik yanıtları bu önerileri kullanmadan önce bir Kullanıcı her öneriyi inceler ve onaylar.

Temel güvenlik önlemi basittir: Deskhero's customer-facing chatbot ve AI auto-replies yalnızca onaylanmış herkese açık SSS’yi kullanır. Chatbot güvenle yanıt veremezse iletişim formuna yönlendirir.

Bu onay döngüsü, herhangi bir araçta kontrol etmeye değer belirli bir dizi kontrolle desteklenir:

  • Önerilen bir SSS öğesi herkese açılmadan önce insan onayı gereklidir.
  • Hiçbir şeyin sessizce gerçekleşmemesi için her otomatik işlemin etiketlenerek kayda alınması.
  • Chatbot ve yapay zekâ otomatik yanıtlarının yalnızca onaylanmış herkese açık SSS’yi kullandığı anlamına gelen kaynakla sınırlandırılmış müşteri yanıtları.
  • Grup başına yapay zekâ otomatik yanıtları ve widget başına chatbot için isteğe bağlı etkinleştirme kontrolleri.
  • Chatbot’un en az 100 onaylanmış herkese açık SSS öğesi gerektirmesi nedeniyle net bir etkinleştirme eşiği.

Deskhero bu iş akışını iki yönlü Gmail, Google Workspace ve Microsoft 365 senkronizasyonu, kapsamlı bir REST API, Google ve Microsoft SSO ve 14 kullanıcı arayüzü dili desteğiyle birleştirir. Dahili KB ve diğer çalışma alanı bilgileri Kullanıcılar için taslak önerileri beslerken, onaylanmış herkese açık SSS müşteri odaklı chatbot’u ve yapay zekâ otomatik yanıtlarını güçlendirir.

Kimsenin Sizi Uyarmadığı Tuzaklar

Birçok bilgi tabanı başarısızlığı içerik değil, sahiplik başarısızlığıdır. Ekipler haftalarca özenle hazırlanmış makaleler yazabilir; ancak güncellemelerden sorumlu kimse kalmadığında kütüphanenin çürümesine izin verir.

En büyük sorun adı belirli bir sorumlunun olmamasıdır. “Ekip” hiçbir şeyin sahibi değildir; belirli bir kişi işlerin sahibidir. İkinci sorun aşırı taşımadır: tüm eski belgeleri ilk günden yeni sisteme taşımak, bunların yarısının hatalı olmasını garanti eder ve okuyucular güncelliğini yitirmiş bir sayfayla ilk kez karşılaştıklarında tüm KB’ye güvenmeyi bırakır. Üçüncü sorun ise aşırı kategorilendirmedir; yeterli içeriğiniz olmadan önce ayrıntılı bir sınıflandırma oluşturmak.

Bilgi tabanını tamamladığınız bir proje olarak değil, sonsuza dek bakımını yaptığınız bir altyapı olarak ele alın. Kendinizi rahat hissettiğinizden daha küçük başlayın, insanların ilk ay içinde gerçekten kullanıp kullanmadığını ölçün ve buradan hareketle ayarlamalar yapın.

Yerleşik Bilgi Tabanına Sahip Entegre Bir Helpdesk’i Deneyin

Mevcut vikinizin üzerine yapay zekâ eklemeyi mi, yoksa iki sistemi ilk günden birbirine bağlamak üzere tasarlanmış bir araçla başlamayı mı değerlendiriyorsanız, Deskhero ekleme adımını atlar. Mevcut Gmail, Google Workspace veya Microsoft 365 posta kutunuzu, Kullanıcı odaklı taslak önerileri için bir Dahili KB ve yalnızca onaylanmış herkese açık SSS’den yanıt veren bir yapay zekâ chatbot’u içeren, taleplerle çalışan bir helpdesk’e dönüştürür.

Deskhero

E-posta taşıma işlemine veya yönetilecek yeni bir adrese gerek yoktur. Müşteri soruları paylaşılan bir gelen kutusuna talepler olarak gelir ve çözümlenmiş görüşmeler önerilen herkese açık SSS öğelerine katkıda bulunabilir. Bir Kullanıcı bunları onayladıktan sonra bu SSS öğeleri web sitesi chatbot’una ve yapay zekâ otomatik yanıtlarına güç sağlayabilir. Dahili KB ve diğer çalışma alanı bilgileri, Kullanıcıların incelemesi için yanıt taslaklarına yardımcı olur. Otomatik işlemler kayda alınır ve etiketlenir; tamamen otomatik müşteri yanıtları ise açık bir isteğe bağlı etkinleştirme gerektirir. Küçük veya orta ölçekli bir destek ekibi için bilgi tabanı yazılımı değerlendiriyorsanız, kredi kartı gerektirmeyen 30 günlük ücretsiz denemeyi Deskhero ile başlatın.

Kaynaklar

SSS

Dahili Bilgi Tabanı Nedir?

Prosedürleri, politikaları, işe alım adımlarını ve geçmiş kararları kapsayan; çalışanların bir iş arkadaşına sormak yerine yanıtları kendilerinin bulabilmesi için oluşturulmuş, merkezi ve aranabilir bir şirket bilgisi deposudur.

Dahili Bilgi Tabanlarına Bazı Örnekler Nelerdir?

Yaygın örnekler arasında parola sıfırlama ve erişim talepleri için bir BT yardım merkezi, yan haklar ve ücretli izin için bir İK politika merkezi, olaylara müdahale için bir mühendislik çalışma kılavuzu kütüphanesi ve sunum dosyaları ile itirazların ele alınması için bir satış destek vikisi bulunur.

Bilgi Yönetimi Sistemine Örnek Nedir?

Aranabilir bir içerik kütüphanesini kategorilendirme, analizler ve kullanıcı geri bildirimleriyle birleştiren platform, bilgi yönetimi sistemi olarak nitelendirilir. Deskhero, bir Dahili KB’yi ve onaylanmış herkese açık SSS öğelerini taleplerle çalışan bir helpdesk’e bağlayarak bu modeli genişletir. Chatbot’u yalnızca onaylanmış herkese açık SSS’den yanıt verir.

Bilgi Tabanı İçin Başka Hangi Terim Kullanılır?

Satıcıya veya onu kullanan ekibe bağlı olarak bilgi tabanının şirket vikisi, dahili dokümantasyon sistemi, çalışan bilgi veritabanı veya bilgi yönetimi platformu olarak da adlandırıldığını duyabilirsiniz.