
Bu şablonu kullanın
Yönetilen hizmet sağlayıcıları için dokümantasyon, sadece “olsa iyi olur” değil; ürünün kendisidir. Trupeer ile ücretsiz MSP dokümantasyon şablonlarıyla başlayarak, marka yönergeleriniz ile özelleştirerek ve herhangi bir teknisyenin kullanabileceği video anlatımlara dönüştürerek MSP dokümantasyon yazmaya ayırdığınız saatleri azaltabilirsiniz.
MSP dokümantasyonu nedir ve onu farklı kılan ne?
MSP dokümantasyonu, bir yönetilen hizmet sağlayıcısının başka kuruluşların teknolojisini çalıştırmak için yazdığı her şeydir: varlık envanterleri, ağ diyagramları, kimlik bilgileri, runbook’lar, eskalasyon yolları, müşteriyle ilgili özel durumlar ve müşterinin gördüğü raporlar ile incelemeler.
İç BT dokümantasyonundan yapısal olarak farklı kılan iki şey var ve neredeyse her şablon ikisini de göz ardı ediyor.
Sahip olmadığınız mülkleri dokümante ediyorsunuz. Müşterinin yazdıklarınızın bir kısmı üzerinde hak iddiası vardır; geri kalanında yoktur ve bu çizgi ticari, sözleşmesel ve ilişki sona erdiği gün açısından kritik önemdedir.
Ayrıca aynı prosedürü aynı anda birçok mülkte dokümante ediyorsunuz. Dahili bir ekip tek bir yedekleme geri yükleme runbook’u yazar. Bir MSP ise bunu bir kez yazar; ancak kimsenin tam olarak hatırlamadığı farklılıklar bulunan otuz ya da kırk farklı ortamda doğru kalmasını sürdürmek zorunda kalır.
İkinci sorun, bir MSP’nin kâr marjını sessizce yiyen sorundur; bu sayfa da tam burada başlar. Tek bir mülk sürümünde, IT dokümantasyon şablonumuz genel durumu kapsar.
Neden tek bir runbook’un kırk kopyası gerçek sorun
Neredeyse her MSP aynı şekilde başlar. İyi bir runbook seti oluşturun. Bir müşteriyi sisteme alın. Mühendisin destek talebi üzerinde çalışırken her şeyi tek yerde bulabilmesi için runbook’ları o müşterinin klasörüne ya da alanına kopyalayın. Tekrar edin.
Bu, makul bir içgüdüdür ve yavaş bir felaket üretir. Dört yıl boyunca otuz civarı müşteriyle çalıştığınızda binin üzerinde dokümanınız olur; bunların çoğu birbirinin neredeyse aynı kopyalarıdır ve hangisinin güncel olduğunu söylemenin bir yolu yoktur.
Arıza, dokümanların kötü olması değildir. Her kopya, yapıldığı anda doğruydu. Arıza şudur: yöntemdeki iyileştirmeler artık otuz kez uygulanmak zorundadır ve biri acil bir şeye çekilmeden önce bu iyileştirmeler beş ya da on kez uygulanır.
Mühendislerin bir sonraki adımda yaptığı iş pahalı kısımdır. Bir teknisyen, ortamla uyuşmayan bir runbook yüzünden iki kez yanıldığında runbook okumayı bırakır. Bunun yerine daha yavaş, daha az tutarlı ve destek talebi hâlâ kapandığı için raporlamanızda tamamen görünmez olan ilk prensiplerle çalışır.
Bu nedenle bir MSP dokümantasyon yapısı, standart güncellemeyi tek bir yerde yapılabilir kılmalıdır. Aşağıdakilerin hepsi bundan kaynaklanır.
Bu şablon Trupeer’da 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 görmek için şablon görünümünü genişletin.

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

Düzenleyici içinde ş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.
MSP dokümantasyon şablonlarıyla şunları yapabilirsiniz:
Yazmaya ayırdığınız saatlerden tasarruf edin: MSP operasyonları için oluşturulmuş yapılarla boş sayfayı atlayın.
MTTR’yi azaltın: Net dokümantasyon, herhangi bir teknisyenin herhangi bir müşteriye hızlıca destek vermesine yardımcı olur.
Markanızda kalın: Trupeer’ın marka kitini kullanarak logonuzu, yazı tiplerinizi ve renklerinizi uygulayın.
Tecnician’ları daha hızlı sisteme alın: Yeni teknisyenler, net ve video tabanlı dokümanlarla hızla uyum sağlar.
Denetime hazır kalın: Yerleşik bölümler SOC 2, ISO 27001 ve müşteri denetimlerini destekler.
Küresel ekiplere ulaşın: MSP dokümanlarını tek tıkla 65+ dile çevirin.
İyi bir MSP dokümantasyonu, yönetilen hizmetler işinin ölçeklenmesini sağlayan şeydir. Bu şablonları kullanarak her müşteriyi, her sistemi ve her prosedürü net ve tutarlı şekilde kaydedin.
Standart dokümanı bir kez oluşturun, yalnızca sapmayı kaydedin
Tek bir standart kütüphane. Her dokümanın tek kopyası. Sürüm yönetimli, sahipli ve yöntemin var olduğu tek yer.
Ardından müşteri bazında, o müşterinin standarttan nerede farklılaştığını kaydeden tek bir kısa doküman ve bunun dışında hiçbir şey. Düzenlemelerle birlikte runbook’un bir kopyası değil. Sadece istisnaların listesi.
Müşteri sapma kayıt defteri tüm hilenin kendisidir. Müşteri farklı bir yedekleme ürününü kullanıyorsa bu tek bir satırdır. Güvenlik duvarları farklı bir satıcıysa yine tek bir satır. Finans direktörleri mesai dışı herhangi bir işi onaylamak zorundaysa yine tek bir satır. Kayıt defterinde olmayan her şey tanım gereği standarttır; bu da bir mühendisin tek bir klasördeki kopyanın güncel olup olmadığını aramak yerine iki dokümanı okumasını sağlar.
Kayıt defterleri küçük kalır. Uygulamada olgun bir müşteri genellikle sekiz ile yirmi satır arasında bir yerde durur ve tek bir doküman yazma çalışması çoğu zaman kimsenin daha önce hiçbir yerde kaydetmediği üç ya da dört sapmayı ortaya çıkarır.
Daha sonra ortaya çıkan ikinci bir fayda daha vardır. Bir müşteriye dair standart dışı olan her şeyin kısa listesi, çok iyi bir satış ve marj dokümanıdır. Sapmalar, zamanınızın aktığı yerdir.
Müşteri sapma kayıt defteri ve içine neler girer
Her sapma için bir satır, beş alan.
Ne farklı. Standartla karşılaştırmalı olarak belirtilir; yani “yedekleme bizim standart Veeam yerine Datto’dur” gibi, “Datto kullanır” gibi değil.
Hangi standart dokümanı etkiler. Referans; böylece runbook’u okuyan bir mühendis buraya yönlendirilebilir.
Neden. Müşteri tercihi; önceki bir sağlayıcıdan devralınmış olabilir, bir uyumluluk gereksinimi olabilir ya da teknik bir kısıt olabilir. Bu alan, sapmanın kaldırılmaya değer olup olmadığını belirler.
Ne zamandan beri ve ne zaman gözden geçirildi. Bir tarih. Onboarding sırasında devralınan sapmalar çoğu zaman kimse tekrar bakmadığı için yıllarca devam eder.
Emek veya risk. Size maliyeti hakkında kısa bir not. Bu alan, kayıt defterini yalnızca teknik değil aynı zamanda ticari bir dokümana da dönüştürür.
Bir başlık ekleyin: müşterinin adı, bu kayıt defterinin dayandığı standart kütüphane sürümü ve hesap sahibi. Kayıt defterlerini çeyreklik olarak gözden geçirin. Nedeni ve maliyeti olmayan sapmalar standardize edilmek için adaydır ve bunu yapmak genellikle bir MSP’nin yapabileceği en yüksek geri dönüşlü dokümantasyon işidir.
Kategorilere göre bir MSP’nin gerçekten ihtiyaç duyduğu dokümanlar
Kategori | Dokümanlar | Standart mı yoksa müşteri bazlı mı | Kim görür |
|---|---|---|---|
Müşteri mülkü | Varlık envanteri, ağ diyagramı, lisans envanteri, kimlik bilgileri | Müşteri bazlı ve müşterinin verisidir | Dahili, talep üzerine paylaşılır |
Prosedürler | Runbook’lar, geri yükleme prosedürleri, onboarding ve offboarding adımları | Sapmalar not edilerek standart | Yalnızca dahili |
Müşteri özelikleri | Sapma kayıt defteri, kişiler, eskalasyon, onay kuralları, mesai dışı şartlar | Müşteri bazlı | Dahili, kısmen paylaşılır |
Değişiklik ve olay | Prosedür yöntemi değişiklik başına, olay kayıtları, olay sonrası incelemeler | Olay başına | Dahili, seçici olarak paylaşılır |
Müşteriye yönelik | Aylık rapor, çeyreklik iş incelemesi, saha denetimi, onboarding kontrol listesi | Standart format, müşteri verileri | Müşteri |
Ticari | Hizmet açıklaması, SLA, fiyatlandırma modeli, sözleşme ekleri | Standart | Müşteri |
Dahili iş | Çalışan el kitabı, güvenlik politikası, araç standartları | Standart | Dahili |
Çoğu MSP ilk ve beşinci satırlarda güçlü, üçüncü satırda zayıftır; bu da tam tersidir; çünkü üçüncü satır, ikinci satırı kullanılabilir kılan şeydir.
Bunlardan ikisinin, doğrudan kullanmaya değer kendi şablonları vardır. Kimlik bilgileri ve lisans envanteri, uygulama ve kimlik bilgileri kayıt defterimiz içinde doğal bir yere sahiptir; runbook’ların kendisi de IT SOP şablonumuzdaki yapıyı izler.
Ücretsiz MSP dokümantasyon şablonları: oluşturmak için standart kütüphane
Buradan kopyalayın. Bu, minimum standart kütüphanedir ve çoğu MSP’nin beklediğinden daha küçüktür.
Onboarding paketi. Keşif kontrol listesi, saha denetimi, varlık kaydı, kimlik bilgisi kaydı, sapma kayıt defteri ilk doldurma, ilk ay incelemesi. Tek doküman; her müşteri için bir kez çalıştırılır.
Runbook’lar, her tekrarlayan görev için bir tane. Yedekleme geri yükleme, kullanıcı oluşturma ve devre dışı bırakma, posta kutusu geri yükleme, uç nokta yeniden oluşturma, parola sıfırlama, VPN erişimi, yazıcı dağıtımı, sertifika yenileme, yama istisnası. Her şeyi kapsatmaya çalışmak yerine en çok destek talebi üreten on göreviyle başlayın.
Eskalasyon ve nöbet. Bir destek talebinin nasıl eskale olduğu, her kademede kimin aranacağı, acil durumun neyi ifade ettiği ve mesai dışı yetkilendirme kuralı.
Olay ve değişiklik. Olay sonrası inceleme formatı ve müşteri altyapısında planlı değişiklikler için bir prosedür yöntemi formatı.
Müşteriye yönelik raporlar. Aylık rapor, çeyreklik iş incelemesi ve saha denetimi çıktısı. Sabit format, doldurulmuş müşteri verileri.
Offboarding paketi. Müşterinin aldığı şey, sizin neyi sakladığınız, hangi formatta ve ne zamana kadar. İhtiyaç duyduğunuzdan önce yazılır.
Sapma kayıt defteri şablonu. Yukarıdaki beş alan.
Buraya kopyalayın. On ila on beş runbook plus altı adet sabit doküman, çalışan bir kütüphanedir. Önce kırk runbook yazma içgüdüsü, çoğu MSP dokümantasyon projesinin ikinci ayda takılmasının nedenidir.
Dahili ve harici MSP dokümantasyonu ve kimin sahip olduğu
Çoğu rehberin çizdiği ayrım dahili ile müşteriye yönelik arasındadır; bu da ton belirlemek için faydalıdır. Daha önemli ayrım ise sahipliktir ve offboarding sırasında gerçek olur.
Genel olarak ve sözleşme ile yargı yetkisine göre değişmekle birlikte, müşterinin verisi müşterinindir: ekipmanlarını anlatan varlık kayıtları, ağ topolojileri, kimlik bilgileri, lisans hakları, konfigürasyonları. Siz bunu bir hizmet sağlayıcı olarak tutarsınız; sahip olmazsınız.
Sizin yönteminiz sizindir: standart runbook’lar, rapor formatlarınız, oluşturma standartlarınız, fiyatlandırma modeliniz, dahili prosedürleriniz. Bir müşteri ayrıldığında, sizin runbook kütüphanenize hak kazanmaz.
Sapma kayıt defteri bu ikisinin arasında garip bir yerde durur; bu yüzden sözleşmenizde açıkça adlandırmaya değer. Müşterinin ortamını anlatır; bu da “onlarınki” argümanını destekler; ancak sizin standartlarınıza göre yazıldığı için “redakte edilmiş bir sürüm” argümanını da destekler.
Bunu çıkış anında tartışmak yerine hizmet sözleşmesinde yazılı olarak netleştirin. Bu sayfa hukuki tavsiye değildir ve sözleşme ile yargı yetkisine göre konum değişir; bu nedenle avukatınızın dokümantasyon sahipliği ve iade hükümlerini gözden geçirmesini sağlayın. Bunu bir kez yapmak bir saat tutar. Bunu offboarding sırasında yapmak ise aşağıdaki gibi çok daha maliyetlidir.
1.360 dokümanı olan ve dokuz adet güncelliğini yitirmiş runbook’u bulunan MSP
Thornbury IT, yirmi iki çalışanıyla otuz dört müşteri için yönetilen hizmetler yürütüyordu; bunların dokuzu mühendisdi. Her onboarding’de runbook setlerini yeni müşterinin alanına kopyalıyorlardı; bu da dördüncü yıla gelindiğinde müşteri başına yaklaşık kırk doküman ve toplamda yaklaşık bin üç yüz altmış doküman anlamına geliyordu.
Sorun bir olay sırasında ortaya çıktı. Bir mühendis, bir müşterinin restore runbook’unu takip ederek o müşteri için başarısız bir yedekleme çalıştırdı; bu runbook, Veeam iş adlandırma kuralını referans alıyordu. Müşteri, on dört ay önce farklı bir yedekleme ürününe geçmişti. Standart runbook güncellenmişti. O müşterinin klasöründeki kopya güncellenmemişti.
Sonrasında on iki müşterinin restore runbook’unu örneklediler. Dokuz tanesi güncel standarttan farklıydı ve bu dokuz farkın beşi sadece güncelliğini yitirmişti; bilerek yapılmış değildi.
Ölçülebilir maliyet işin ele alınma süresindeydi. İş genelinde ortalama ikinci kademe ele alma süresi kırk yedi dakikaydı. Runbook’ları güncelliğini yitirmiş olan müşterilerde bu yetmiş bir dakikaydı; çünkü bu hesaplardaki mühendisler dokümantasyona güvenmeyi bırakmış ve her seferinde yeniden çözümlemişti.
Ayrıca üçüncü yılda bir müşteri ayrılmış ve dokümantasyonunu istemişti. Thornbury, müşterinin klasörünü gönderdi; bu klasörde müşterinin varlık kayıt defteri ve kimlik bilgileriyle karışmış kendi standart runbook’ları vardı. Kimse çizgiyi hiç çekmemişti. Müşterinin neye hak kazandığı konusundaki tartışma altı hafta sürdü ve iki firmanın avukatlarını da içerdi.
Yeniden oluşturma, tek bir kişinin bir ayını aldı. Tek standart kütüphane, tek kopya, sürüm yönetimli. Müşteri bazında yalnızca sapma kayıt defteri. Ortanca kayıt defteri uzunluğu on bir satırdı.
Bin üç yüz altmış doküman, kırk standart dokümana ve otuz dört kayda dönüştü; toplam yetmiş dört oldu. İkinci kademe ele alma süresi tüm hesaplarda kırk dört dakikaya yakınsad. Ve offboarding paketi o tarihten itibaren sözleşmede tanımlandı: müşteri varlık kayıt defterini, kimlik bilgilerini, diyagramlarını ve sapma kayıt defterini alır; Thornbury ise standart kütüphaneyi saklar.
GitHub’da ücretsiz MSP dokümantasyon şablonları var mı?
Evet ve gerçekçi beklentilerle bakmaya değer.
Karşılaşacağınız şeyler; runbook koleksiyonlarına dair topluluk depoları, gömülü dokümantasyon içeren PowerShell script kütüphaneleri, markdown tabanlı dokümantasyon çerçeveleri ve bazen de bir MSP’nin işe alım ya da pazarlama çalışması olarak yayınladığı tam bir dokümantasyon yapısıdır. MSP runbook’larını ya da IT dokümantasyonunu markdown veya docs-as-code ile birlikte aramak, çoğunun ortaya çıkmasını sağlar.
Bu depolarda gerçekten faydalı olan şeyler yapı ve kapsamdır: yetkin bir MSP’nin sürdürdüğü runbook’ların listesi, kendi kontrol listeniz için iyi bir başlangıçtır. Nadir faydalı olan ise içeriktir; çünkü runbook’lar belirli bir araç yığınına özeldir ve başkasının yedekleme ürünü ile RMM’i için bir geri yükleme prosedürü, şablondan çok çalışılmış bir örneğe daha yakındır.
İki uyarı. Ticari bir dokümantasyon kütüphanesine herhangi bir şeyi dahil etmeden önce lisansı kontrol edin; izin verici lisanslar yaygındır ama evrensel değildir. Ayrıca gerçek müşteri tanımlayıcıları, ağ ayrıntıları veya kimlik bilgilerine benzeyen herhangi bir şey içeren bir depoyu asla uyarlamayın; çünkü bunlar kamu depolarında olması gerekenden daha sık karşımıza çıkar.
Docs-as-code yaklaşımının kendisi, yani sürüm kontrolünde markdown kullanılması, bir MSP için meşru bir seçenektir ve tek kopya sorununu zarifçe çözer. Zayıf yönü şudur: zaman baskısı altındaki mühendisler bir depoya taahhüt etmez; bu nedenle benimseme genellikle araçlardan ziyade sınırlayıcı faktör olur.
MSP dokümantasyon yazılımı ve satıcıya kilitlenme sorunu
MSP’lere yönelik dokümantasyon platformları, kendi başınıza inşa etmesi zor olan konularda iyidir: yapılandırılmış varlık ilişkileri, RMM ve PSA’nızla entegrasyon, denetim iziyle kimlik bilgisi yönetimi ve izinlerle müşteri bazında ayrım.
Takas şudur: dokümantasyonunuz onların veri modeline göre şekillenir ve onu tekrar kullanılabilir bir biçimde dışarı çıkarmak, satış sürecinin ima ettiğinden çoğu zaman daha kötüdür. Dışa aktarma genellikle, mühendislerinizin gerçekten kullandığı okunabilir dokümanlar yerine bir kayıtlar seti anlamına gelir.
Taahhüt etmeden önce sorulmaya değer iki soru var. İlişkiler ve ekler dahil olmak üzere her şeyi, başka bir ürünü hiç satın almasaydınız bile kullanılabilir kalacak bir formatta dışa aktarabilir misiniz? Ve müşteriler arasında geçerli tek bir standart dokümanı tek başına sürdürebilir misiniz; yoksa model müşteri başına bir kopyayı zorunlu kılıyor mu ve bu da bu sayfanın anlattığı tam sorunu yeniden mi getiriyor.
İkinci soru, beklediğinizden daha fazla ürünü eleyebilir. Bir platform müşteri başına kopyaları zorunlu kılıyorsa, standart kütüphaneyi onun dışında daha sade bir yerde tutun ve platformu müşteri mülkü verisi için kullanın; çünkü platformun gerçekten iyi olduğu şey budur. Standart kütüphanenin nerede yaşarsa yaşasın yapılandırılmasını knowledge base şablonumuz kapsar.
Bir müşteri ayrıldığında dokümantasyona ne olur?
Offboarding, dokümantasyon kalitesinin genellikle zaten memnun olmayan kişilere görünür hale geldiği yerdir.
Paketin içeriğini sözleşmede tanımlayın. Makul bir yaklaşım şudur: müşteri varlık kayıt defterini, ağ diyagramlarını, lisans envanterini, kimlik bilgileri güvenli şekilde aktarılmış halde, sapma kayıt defterini ve teslimat olarak ödemiş olduğu herhangi bir dokümantasyonu alır. Siz standart runbook’larınızı, rapor formatlarınızı ve dahili prosedürlerinizi saklarsınız.
Aynı madde içinde bir zaman çizelgesi ve format belirleyin; çünkü “dokümantasyon sağlanacaktır” ifadesi anlaşmazlıkların başladığı yerdir. Otuz gün ve belirtilmiş bir format normaldir.
Kimlik bilgisi devrini bir elektronik tablo üzerinden değil, düzgün bir süreçle yapın ve neyin ne zaman aktarıldığını kaydedin; çünkü bu kayıt, daha sonra bir şeylere erişilirse iki tarafı da korur.
Ayrılış, başka bir sağlayıcıya transfer şeklindeyse ve dahili değilse, yapılandırılmış bir devretme doküman dökümünden çok daha ucuzdur; ayrıca knowledge transfer SOP bunu nasıl yürüteceğinizi kapsar.
MSP dokümantasyon şablonlarını PDF olarak alabilir miyim?
PDF, bunların ikisi için doğru; geri kalanı için yanlış.
Müşteriye yönelik dokümanlar için doğru: aylık rapor, çeyreklik inceleme, saha denetimi çıktısı. Bunlar bir anın görüntüsüdür; dondurmak doğrudur ve marka kimliğinizi taşımalıdır.
Runbook’lar, sapma kayıt defteri ve varlık kayıt defteri için yanlış; çünkü bunların hepsi değişir ve hepsinin aranabilir olması gerekir. Yukarıdaki çalışılmış örnekteki gibi bir PDF runbook kütüphanesi, sorunun daha yavaş bir sürümüdür; çünkü bir PDF, okuyucuya güncel olmadığını söyleyemez.
Standart kütüphane için, mühendislerinizin baskı altında gerçekten arayacağı her şeyi kullanın ve tek bir kopya tutun. Müşteri teslimatları için, ayrı bir kopya sürdürmek yerine PDF’yi bu kaynaktan üretin.
Standart kütüphaneyi tüm müşterilerde güncel nasıl tutarsınız
Tüm yapı, standart kütüphanenin gerçekten sürdürülebilir olmasına dayanır; genellikle sürdürülememesinin nedeni de bir runbook’u güncellemenin, zaten nasıl kullanılacağını bildikleri bir araç için adımları ekran görüntüsü alıp kırpıp yeniden yazmayı gerektirmesidir.
Trupeer AI bunun büyük kısmını ortadan kaldırır. Bir mühendis görevi bir kez kamerada gerçekleştirir ve çıktı, adımlar ve ekranlar zaten yerinde olacak şekilde biçimlendirilmiş bir runbook olur; yazmak yerine incelemeye hazırdır. On runbook’luk bir yenileme çeyrek yerine bir güne iner.
Kaydedin. Markalayın. Çevirin. Trupeer’layın.
Müşteriye yönelik içeriklerde marka kimliği ticari açıdan önemlidir ve marka kitleri, müşterinin aldığı raporun ve rehberin bir şablondan değil sizden gelmiş gibi görünmesini sağlar. Dokümantasyon ve teknik dokümantasyon, standart kütüphaneyi ve müşteri mülkü kayıtlarını birlikte tutar; SOP oluşturucu ise runbook’ların kendisini kapsar. Kurulum talimatları doküman şablonu kurulum kılavuzunda yer alır.
Sık Sorulan Sorular
PDF olarak ücretsiz MSP dokümantasyon şablonları var mı?
Bu sayfadaki yapılar ücretsiz kopyalanabilir ve mantıklı ayrım şudur: runbook’ları ve kayıt defterlerini aranabilir bir yerde tutarken, müşteriye yönelik raporları PDF’ye dışa aktarın. Kilitli bir indirme yok ve form yok. Referans için standart kütüphanenin bir PDF’sini istiyorsanız, ayrı ayrı sürdürmek yerine canlı kopyanızdan üretin.
En iyi ücretsiz MSP dokümantasyon şablonları hangileri?
En iyi set, güncel tutacağınız en küçük settir: en yüksek destek talebi hacimlerinizi kapsayan on ila on beş runbook, bir onboarding paketi, bir eskalasyon dokümanı, bir sapma kayıt defteri formatı ve üç müşteriye yönelik rapor formatı. Herhangi bir şablon kütüphanesini, standardı müşteri başına istisnadan ayırıp ayırmadığına göre değerlendirin; çünkü bunu belirleyen kısım, otuz müşteride hayatta kalıp kalmayacağını belirler.
Bir MSP dokümantasyonunu nerede tutmalı?
Müşteri mülkü verisi, RMM ve PSA’nızla entegre olan ve kimlik bilgilerini doğru şekilde yöneten bir platformda bulunmalıdır. Standart kütüphane ise mühendislerin en hızlı arayacağı yerde olmalıdır; bu aynı platform olabilir ya da daha sade bir şey de olabilir. Belirleyici soru, platformun tüm müşteriler için geçerli tek bir dokümanı sürdürmenize izin verip vermediğidir.
Onboarding sırasında yeni bir müşteri ne kadar dokümantasyon almalı?
Standart kütüphanenizin hiçbiri ve onların tüm mülk verisi. Uygulamada, müşterinin onboarding’de değer verdiği teslimat varlık kayıt defteri, ağ diyagramı ve bulduklarınız ile önerdiklerinizin sade bir özetidir. Onboarding’de runbook göndermek yaygın bir içgüdüdür ve ticari bir karşılık olmadan yönteminizin tamamını verir.
Müşteri, sistemleri hakkında yazdığımız dokümantasyonun sahibi mi?
Genellikle verileri evet, yönteminiz genellikle hayır ve sınırın çıkış anında tartışılmak yerine hizmet sözleşmesine yazılması gerekir. Varlık kayıt defterleri, diyagramlar, kimlik bilgileri ve konfigürasyonlar onların mülkünü anlatır. Standart runbook’larınız ve rapor formatlarınız ise sizin fikri mülkiyetinizdir. Sözleşme maddesinin kendi avukatınız tarafından gözden geçirilmesini sağlayın; çünkü konum sözleşme ve yargı yetkisine göre değişir.
Mühendislerin dokümantasyonu atlamasını nasıl engelleriz?
Önce standart kütüphaneyi güvenilir hale getirin. Mühendisler dokümantasyonu okumayı atlar; çünkü daha önce yanlış olmuştur; okumayı sevmemeleri yüzünden değil. Tek kopya sorununu çözün, ele alınma sürelerini yakınsadın ve davranış kendiliğinden değişir. Dokümantasyon güncellemelerini yalnızca destek talebi kapanışında zorunlu kılmak, kütüphane güncellenmeye değer hale geldikten sonra işe yarar.
