Microsoft 365 destek süreci nasıl değerlendirilir?

Microsoft 365 destek süreci nasıl değerlendirilir?

Microsoft 365 sorunlarını değerlendirirken önce etkilenen kullanıcılar, uygulamalar ve iş akışı belirlenmelidir. Oturum açma hatası, posta akışı sorunu ve cihaz bağlantısı aynı inceleme yolunu gerektirmeyebilir. Sağlıklı bir destek kaydı başlangıç zamanını, belirtileri ve son değişiklikleri gösterir; yapılan müdahalenin sonucu da aynı kullanım senaryosu üzerinden kontrol edilir. Uygulama kapsamı için Microsoft 365 yönetimi sayfasındaki açıklamalar da değerlendirilebilir.

Microsoft 365 danışmanlık hizmeti ise tekrar eden sorunların nedenini değerlendirme, mevcut yapıyı gözden geçirme ve uygulanacak değişiklikleri planlama ihtiyacına odaklanabilir. Tek bir destek olayının çözümüyle kapsamlı ortam değerlendirmesi ayrı teslimlerdir. Başvurunuzda acil sorun incelemesi mi, düzenli destek mi yoksa danışmanlık çalışması mı istediğinizi belirtmeniz, ihtiyacınıza uygun iş kalemlerinin konuşulmasını kolaylaştırır. Üreticiye veya diğer ekiplere bağlı konular kapsam içinde ayrıca açıklanmalıdır.

Desteklenecek alanları ürün adına bırakmayın

“Microsoft 365 desteği” ifadesi tek başına yeterince belirli değildir. Teklif; kullanıcı oturum açma, Exchange Online, Teams, OneDrive, SharePoint veya masaüstü uygulamalarından hangilerini içerdiğini açıklamalıdır. Bunun yanında işletim sistemi, ağ bağlantısı ve üçüncü taraf eklentilerin sınırı çizilmelidir. Kullanıcı sorunu bir uygulamada görse bile neden başka bileşende olabilir. Sağlayıcının bu ayrımı inceleyip incelemediği, yoksa doğrudan başka ekibe mi yönlendirdiği önceden bilinmelidir.

Karşılaştırma için kısa bir kapsam tablosu hazırlayabilirsiniz: desteklenen kullanıcı sayısı, uygulamalar, cihazlar, lokasyonlar, çalışma saatleri ve ek projeler. Her sağlayıcı aynı tabloyu yanıtladığında bedellerin neyi karşıladığı anlaşılır. Çalışan cihazının yenilenmesi, eski verinin aktarılması veya yeni güvenlik projesi ayrıca ele alınabilir. Sözleşmede bunların ayrı olması sorun değildir; önemli olan arıza sırasında ilk defa öğrenilecek belirsizliğe dönüşmemesidir.

İyi bir talep kaydı hangi bilgileri toplar?

İlk kayıtta sorunun ne zaman başladığı, hangi kullanıcıların etkilendiği, hangi uygulamada görüldüğü ve iş üzerindeki etkisi bulunmalıdır. Hata mesajı varsa kişisel veya hassas bilgileri gereksiz yere yaymadan paylaşılabilir. Sorunun tek cihazda mı, farklı cihazlarda mı tekrarlandığı önemli bir ipucudur. Son yapılan değişikliklerin bilinmesi de incelemeye yardımcı olur. “Mail çalışmıyor” ifadesiyle “üç kullanıcı tarayıcıdan giriş yapabiliyor, masaüstü uygulaması hata veriyor” açıklaması aynı araştırma değerini taşımaz.

Destek sağlayıcıdan talep formu veya örnek kayıt alanlarını göstermesini isteyin. Kullanıcının bütün teşhisi kendisinin yapması beklenmemelidir; form yalnız başlangıç bilgisini düzenlemelidir. Gerekirse teknik ekip telefon veya uzaktan görüşmeyle ayrıntıları tamamlar. Parola, doğrulama kodu ve kalıcı erişim anahtarı talep açıklamasına yazılmamalıdır. Birden fazla kişi aynı sorunu bildiriyorsa kayıtların ilişkilendirilmesi, çalışanların aynı bilgiyi tekrar tekrar anlatmasını ve ekiplerin birbirinden kopuk işlem yapmasını azaltabilir.

Servis sağlığı kontrolü neden ilk adımlardan biridir?

Bir kesinti her zaman şirket ayarından kaynaklanmaz. Microsoft’un servis sağlığı kontrolü belgesi, kuruluşun kullandığı hizmetlerde bilinen olayların yönetim merkezinden incelenebildiğini açıklar. Teknik ekip sorun araştırırken bu bilgiyi yerel belirtilerle birlikte değerlendirebilir. Bilinen bir olayın bulunması, gereksiz ayar değişiklikleri yerine etkiyi izleme ve çalışanları bilgilendirme yaklaşımını destekleyebilir. Ancak gösterge ekranı tek başına bütün yerel sorunları dışlamaz.

Sağlayıcıya, Microsoft kaynaklı bir olay sırasında ne teslim edeceğini sorun. Etkilenen uygulamanın açıklanması, uygun durum güncellemeleri ve hizmet düzeldikten sonraki kullanıcı kontrolü somut çıktılardır. “Sorun Microsoft’ta” denilerek kaydın açıklamasız kapatılması işletmenin iletişim ihtiyacını karşılamayabilir. Öte yandan bağımsız bir ekip, üreticinin müdahalesine bağlı kesintinin her koşulda belirli dakikada biteceğini taahhüt edemez. Bu bağımlılık teklifin süre ve sorumluluk tanımlarında açıkça belirtilmelidir.

Öncelik, yanıt ve çözüm sürelerini ayırın

Öncelik, yalnız talebi açan kişinin unvanına göre verilmemelidir. Etkilenen çalışan sayısı, yürütülemeyen iş ve alternatif çalışma imkanı değerlendirilmelidir. Şirket genelinde giriş yapılamamasıyla bir kullanıcının eski cihazındaki görüntü sorunu farklı öncelik taşıyabilir. Kapsam görüşmesinde kendi işinizden birkaç örnek verin ve sağlayıcının nasıl sınıflandıracağını sorun. Bu örnekler, sözleşmedeki genel ifadelerin günlük kullanımda ne anlama geldiğini ortaya çıkarır.

İlk yanıt süresi, teknik incelemenin başlaması ve kalıcı çözümün tamamlanması farklı ölçülerdir. Sağlayıcıdan hangi süreyi taahhüt ettiğini ve hangi koşulların ölçümü etkilediğini belirtmesini isteyin. Müşteri onayı, kullanıcının ulaşılabilirliği veya üçüncü taraf yanıtı beklenebilir. Bunların kayda nasıl yazılacağı ve bekleyen işin kimin takibinde kalacağı anlaşılmalıdır. Yanıt geldiği halde hiçbir sonraki adımın tanımlanmadığı kayıtlar, yalnız süre tablosuna bakıldığında olduğundan daha iyi görünebilir.

Uzaktan erişim ve değişiklikler nasıl onaylanmalı?

İnceleme için gereken erişim sorunun türüne göre değişir. Kullanıcı ekranındaki hata için geçici uzaktan oturum yeterli olabilirken, kuruluş ayarını kontrol etmek farklı rol gerektirebilir. Her talepte en geniş yönetici yetkisinin kullanılması zorunlu değildir. Microsoft’un yönetici rolleri rehberi görevlerle uyumlu yetkilerin belirlenmesine yardımcı olur. Sağlayıcının hangi rolü neden istediğini açıklayabilmesi satın alma görüşmesinde değerlendirilebilecek bir ölçüttür.

İşletme genelini etkileyen ayarlar için değişiklik onayı, uygulama zamanı ve işlem sonrası kontrol belirlenmelidir. Bir hatayı gidermek amacıyla koruma ayarının kapatılması düşünülüyorsa etkisi ve alternatifleri ayrıca değerlendirilmelidir. İşlemi yapan kişinin kaydı, değişen ayarın özeti ve sonucu raporda bulunabilir. Uzaktan oturum sonunda geçici erişimin durumu da kontrol edilmelidir. Bu kayıt düzeni, bir sonraki sorun araştırmasında nelerin değiştiğini anlayabilmeyi sağlar ve farklı ekipler arasındaki devri kolaylaştırır.

Üreticiye ve başka ekiplere aktarım nasıl yürümeli?

Bazı olaylar şirketin hizmet sağlayıcısı tarafından tek başına çözülemez. Ürün davranışı için Microsoft’a, bağlantı sorunu için internet ekibine veya özel entegrasyon için yazılım geliştiricisine başvurmak gerekebilir. Teklifte bu aktarımı kimin yapacağı ve müşteriyle kimin iletişimde kalacağı belirtilmelidir. Teknik kayıt, tekrarlama adımları ve yapılan kontroller düzenlenirse yeni ekip incelemeye daha açık bilgiyle başlayabilir. Yalnız bir telefon numarası iletmek, koordinasyon hizmetiyle aynı teslim değildir.

Microsoft’un işletmeler için destek açıklaması, destek yolunun aboneliğin satın alındığı kanala göre değişebildiğini belirtir. Bu nedenle şirketin sözleşme ve abonelik yapısı incelenmeden tek bir üreticiye başvuru yöntemi vaat edilmemelidir. Sağlayıcıdan mevcut durumda hangi kanalın kullanılacağını ve açılan kaydın nasıl izleneceğini sorun. Üreticiye aktarım, ilk talebin sonucunu takip etme sorumluluğunu otomatik olarak ortadan kaldırmamalıdır.

Danışmanlık çalışmasının teslimini somutlaştırın

Tekrarlayan oturum açma sorunları, düzensiz yetkiler veya farklı ekiplerin tutarsız uygulama kullanımı ayrı bir inceleme ihtiyacı doğurabilir. Danışmanlık teklifinde başlangıç durumu, hedeflenen karar ve teslim edilecek belge belirtilmelidir. Örneğin erişim yapısının değerlendirilmesi, sorunların önceliklendirilmesi ve uygulanabilir değişiklik sırası hazırlanması bir çalışma olabilir. Bu inceleme, gerekli lisans ve gerçek ortam doğrulanmadan belirli ürünün satın alınmasıyla sonuçlanacak şekilde kurgulanmamalıdır.

Danışmanlık raporunda bulgu, iş etkisi, öneri, bağımlılık ve karar sorumlusu ayrı gösterilebilir. Böylece işletme hangi önerinin hemen uygulanabileceğini, hangisinin bütçe veya süreç kararı gerektirdiğini anlar. Bir raporun uzunluğu tek başına değeri göstermez; şirketin sonraki adımı seçmesine yardımcı olması gerekir. Uygulama da satın alınacaksa bunun ayrıca kapsamlandırılması, testinin ve geri dönüş yaklaşımının belirlenmesi istenebilir. Günlük destek sözleşmesinin bütün dönüşüm projelerini kendiliğinden içerdiği varsayılmamalıdır.

Örnek olayla sağlayıcının yöntemini değerlendirin

Varsayımsal olarak satış ekibindeki birkaç kullanıcının aynı sabah masaüstü uygulamasından e-posta gönderemediğini düşünün. Bazı kullanıcılar tarayıcıyla çalışabiliyor olabilir. İyi bir başlangıç, etkiyi doğrulamak, servis sağlığını kontrol etmek, cihaz ve uygulama farklarını incelemek ve son değişiklikleri araştırmaktır. Bu örnek gerçek müşteri vakası veya sonuç iddiası değildir. Amaç, sağlayıcının sorunu tek bir hazır çözüme bağlamadan nasıl araştıracağını karşılaştırabilmektir.

Görüşmede bu senaryoyu vererek hangi bilginin isteneceğini, kimin onayının bekleneceğini ve kullanıcıya ne söyleneceğini sorun. Şirketin tamamını etkileyecek değişiklik yapılmadan önce hangi doğrulamanın aranacağını öğrenin. Sorun giderildiğinde hem teknik sonuç hem çalışan deneyimi kontrol edilmelidir. Tarayıcıdan geçici çalışma olanağı sağlanmış olması, masaüstü sorununun kalıcı çözüldüğü anlamına gelmez. Geçici çözüm, açık neden araştırması ve nihai kapanış ayrı durumlar olarak raporlanabilir.

Sağlayıcı değişikliği olasılığını da görüşmeye dahil edin. Açık taleplerin, önemli değişiklik kayıtlarının ve kuruluşun ihtiyaç duyduğu teknik belgelerin nasıl aktarılacağı belirlenebilir. Destek sürecinin yalnız bir uzmanın kişisel hafızasına dayanması, ekip değişiminde bilgi kaybına yol açabilir. Devir çıktısının önceden tanımlanması, hizmetin sürekliliğini değerlendirmek için somut bir ölçüt sunar.

Microsoft 365 teknik destek fiyatını etkileyen işler

Teknik destek için teklif; etkilenen kullanıcı sayısı, sorunun kapsamı, incelenecek uygulamalar ve gerekli çalışma biçimine göre değerlendirilmelidir. Tek cihazdaki hata ile şirket genelinde görülen erişim sorununun araştırılması aynı iş değildir. Uzaktan erişim, gerekiyorsa yerinde çalışma ve başka sağlayıcılarla koordinasyon ihtiyaçları da belirtilmelidir. İlk inceleme sonunda ortaya çıkabilecek ek işin nasıl onaylanacağı baştan anlaşılmalıdır.

Düzenli destek talebinde çalışma saatlerini, talep kanallarını ve öncelik düzenini sorun. Danışmanlık isteniyorsa inceleme raporu, önerilen değişiklikler ve uygulamanın dahil olup olmadığı ayrı yazılsın. İlk yanıt, inceleme ve kalıcı çözüm süreleri birbirinden ayrılmalıdır. Gerçek ortam değerlendirilmeden kesin çözüm süresi veya bütün sorunların tek bedelle giderileceği sözü verilmemelidir. Teklifin değeri, bu sınırları açık göstermesiyle de değerlendirilir.

Uygulama öncesi son kontroller

Destek başvurusunda sorunun başlangıcını, etkilenen çalışan sayısını, uygulamayı ve görünen hata mesajını belirtin. Varsa tarayıcıyla çalışıp masaüstü uygulamasında çalışmaması gibi farkları ekleyin. Ekran görüntülerindeki gereksiz kişisel bilgileri kapatın; parola ve doğrulama kodu göndermeyin. Teknik teşhisi tamamlamanız beklenmez. Sorunun işinizi nasıl etkilediğini açıklamanız, incelemenin önceliğinin ve başlangıç kapsamının değerlendirilmesine yardımcı olur.

Son kontrol listesinde olay kaydı, etkilenen uygulamalar, gerekli erişimler, ekip koordinasyonu ve kapanış testleri birlikte yer almalıdır. Tamamlanan kontrolleri ve açık kalan işleri ayrı kaydedin. Sorumluları ve sonraki adımları belirlemek, uygulama sonucunu başlangıçta tanımlanan kapsamla karşılaştırmayı kolaylaştırır.

Teklif için Microsoft 365 yönetimi sayfasına gidin.

Sık Sorulan Sorular