Destek ve SLA / Nimex Solutions
İş sürekliliği, sorumluluk ve çözüm odaklı destek.
Bir teslimat doğrulanamadığında deponuzun ihtiyacı bir talep numarası değildir; rampanın yeniden işlemesi ve neden durduğuna dair net bir yanıttır. Uçtan uca 7/24 teknik desteğimiz her olaya bir sorumlu, doğru ortamda bir inceleme, test edilmiş bir düzeltme ve sizin onayladığınız bir kapanış sağlar. Hizmet seviyeleri her sözleşmede yazılı olarak tanımlanır.
- Çalışma yöntemimiz
- Standart Odoo
- Sözleşmeye göre belirlenir
Kanallar
Soru hangi yoldan gelirse gelsin, tek kuyruk.
Her istek; sorumlusu, önceliği ve ekibinizin görebildiği bir durumu olan bir destek talebine dönüşür. Aşağıdaki kanallar işlettiğimiz kanallardır; sözleşmenizin hangilerini ve hangi saatlerde kapsadığı sözleşmede yazılıdır.
Yardım masası portalı ve destek talepleriÇalışma yöntemimiz
Ana kanal: kullanıcılarınız talep açar, ekran görüntüsü ekler ve durumu takip eder. Diğer her şey de burada kayıt altına alınır.
E-postaÇalışma yöntemimiz
Destek adresine gelen mesajlar otomatik olarak destek talebi oluşturur; yanıtlar talebin yazışmasında kalır.
Planlı toplantılarÇalışma yöntemimiz
Kilit kullanıcılarınızla haftalık ya da aylık değerlendirme görüşmeleri: açık talepler, tekrarlayan sorunlar, planlanan değişiklikler.
Telefon ve mesajlaşmaSözleşmeye göre belirlenir
Kritik kesintiler için doğrudan hat ve mesajlaşma kanalları, kapsam saatleriyle birlikte sözleşmeye göre kararlaştırılır.
Önem derecesi örnekleri
Olaylar özellik talebi değildir; ikisinin de net bir yolu vardır.
Öncelik, en yüksek sesle kimin bağırdığına değil işe etkisine göre belirlenir. Aşağıdaki örnekler nasıl sınıflandırdığımızı gösterir; her seviyeye bağlı yanıt hedefleri sözleşmenizde belirlenir.
| Önem derecesi | Tipik örnek | Nedir | Nasıl ele alınır |
|---|---|---|---|
| Kritik kesinti | Kimse oturum açamıyor; ayın son günü faturalar onaylanamıyor; canlı veritabanına erişilemiyor. | Olay. Şirket temel bir süreci yürütemiyor. | Anında sahiplenme; önce geçici çözüm, hizmet geri geldikten sonra kök neden. Hedefler sözleşmeye göre |
| Önemli iş akışı arızası | Bir seri numarası hatası yüzünden teslimatlar doğrulanamıyor; e-faturalar entegratör tarafından reddediliyor. | Olay. Bir iş akışı durdu; bir departman çalışamıyor. | Test ortamında yeniden üretilir, orada düzeltilip test edilir, kararlaştırılan bir pencerede yüklenir. Hedefler sözleşmeye göre |
| Sınırlı kullanıcı sorunu | Bir kullanıcının raporu yanlış bir sütunla yazdırılıyor; bir filtre tek bir kişi için kaydedilmiyor. | Olay. Bir kullanıcı yavaşlıyor; iş akışı devam ediyor. | Kuyruk sırasıyla incelenir; çoğu zaman bir yapılandırma ya da erişim hakkı değişikliğidir. |
| Genel soru | "Bir üretim emrini nasıl bölerim?" "Müşteri bazında marjı hangi rapor gösteriyor?" | Soru. Arıza yok; bilgi gerekiyor. | Talep üzerinde yanıtlanır, kılavuza ya da bir sonraki eğitim turuna eklenir. |
| Geliştirme talebi | İki dilde irsaliye; satınalma siparişlerinde yeni bir onay adımı. | Değişiklik. Yeni davranış, bir hata değil. | Değişiklik olarak tahminlenir ve planlanır; olay olmadığı için asla olay hedeflerine dahil edilmez. Çalışma yöntemimiz |
SLA çerçevesi
Bir destek sözleşmesi neyi tanımlar, neyi tanımlamaz.
"Uçtan uca 7/24 teknik destek" sahiplenme sözümüzdür: bildirilen bir olay asla sorumlusuz kalmaz. Ölçülebilir kısım her sözleşmede ayrıca yazılır; çünkü iki tesisli bir üretici ile on kullanıcılı bir distribütörün aynı kapsama ihtiyacı yoktur. Evrensel yanıt süreleri, çözüm süreleri veya erişilebilirlik yüzdeleri yayımlamayız.
- KapsamÖnem derecesine göre saatler ve günler; sözleşmenizde kritik kesintiler için "7/24"ün ne anlama geldiği.
- Yanıt hedefleriÖnem derecesine göre: bir talebin ne zaman alındığı ve sahiplenildiği, ilerlemenin nasıl raporlandığı.
- EskalasyonKendi irtibat kişileriniz dahil, her seviyede kimin ve ne zaman aranacağı.
- SorumluluklarKilit kullanıcılarınızın ne yaptığı (yeniden üretme, onaylama), bizim ne yaptığımız, barındırma sağlayıcısının ne yaptığı.
- ÖnceliklerYukarıdaki önem derecesi ölçeği, işinizden örneklerle kararlaştırılır.
- Kapsam dışıDeğişiklikler, yeni geliştirmeler, üçüncü taraf kesintileri, veri girişi hataları: ele alınır, ancak olay hedeflerinin dışındadır.
- RaporlamaAylık destek talebi raporu: hacimler, durumlar, tekrarlayan sorunlar, harcanan süre.
- Bakım pencereleriYüklemelerin ve güncellemelerin ne zaman yapıldığı ve nasıl duyurulduğu.
Eskalasyon ve sahiplenme
Yedi adım, her birinde bir sorumlu; siz onaylamadan hiçbir şey kapanmaz.
Bir talep, yalnızca adım gerçekten tamamlandığında ilerler: test edilmemiş bir düzeltme düzeltme değildir; kullanıcının doğrulamadığı bir yükleme çözüm değildir. Aynı yol her önem derecesi için geçerlidir; değişen, her adımın ne kadar hızlı sahiplenildiğidir.
- Kayıtİstek; bildiren kişi, ilgili kayıt ve ekran görüntüleriyle bir destek talebine dönüşür.
- Ön değerlendirmeOlay mı değişiklik mi; işe etkisine göre önem derecesi; sorumlu atanır.
- İncelemeTest ortamında yeniden üretilir; kayıtlar, veriler ve yapılandırma kontrol edilir.
- DüzeltmeDoğru ortamda yapılandırma, veri düzeltmesi ya da kod değişikliği.
- TestDüzeltme ve çevresindeki iş akışı, yüklemeden önce test ortamında test edilir.
- Müşteri onayıKullanıcınız canlı ortamda doğrular; talep bunu bekler.
- KapanışKök neden belgelenir; gerekirse önleyici değişiklik planlanır.
Olay konsolu
Aynı olay, destek ekibinin gözünden.
Önem derecesine göre kuyruk, etkilenen iş akışı, talebi şu anda sahiplenen seviyeyle eskalasyon yolu, bilindiği anda kök neden ve çözüm zaman çizelgesi. Sayaçlar yalnızca bir talep gerçekten durum değiştirdiğinde hareket eder.
Bu konsolun göstermedikleri. Yanıt ya da çözüm süreleri yok: bunlar sözleşmenizdeki hedeflerdir ve gerçek taleplere göre aylık raporlanır. Erişilebilirlik yüzdesi yok: barındırma ve izleme barındırma ve bakım sayfasında anlatılır.
İzleme ve iyileştirme
Bu ayki taleplerin amacı, gelecek ay daha az talep.
Destek, tekrarlayan sorunların önleyici çalışmaya dönüştüğü yerdir. Bunlar bir destek sözleşmesinin arkasındaki rutinlerdir; sunucuların ve veritabanlarının izlenmesi ise barındırma ve bakımın parçasıdır.
Hata analiziÇalışma yöntemimiz
Sunucu ve istemci hataları talebe göre değil nedene göre gruplanır; en sık nedenler için önleyici değişiklik yapılır.
KayıtlarÇalışma yöntemimiz
Uygulama kayıtları yüklemelerden sonra ve her olayda incelenir; saklama süresi barındırma modeline göredir.
Tekrarlayan olaylarÇalışma yöntemimiz
Geri gelen talepler birbirine bağlanır; üçüncü tekrar, üçüncü bir düzeltme yerine bir iyileştirme kalemi açar.
Teknik borçÇalışma yöntemimiz
Geçici çözümler ve hızlı düzeltmeler maliyetleriyle listelenir; liste aylık toplantıda gözden geçirilir.
PerformansÇalışma yöntemimiz
Yavaş raporlar, uzun süren işler ve ağır görünümler, kullanıcılar bildirmeden önce ölçülür ve iyileştirilir.
Önleyici bakımÇalışma yöntemimiz
Kararlaştırılan bakım pencerelerinde planlı güncellemeler, bağımlılık incelemeleri ve temizlikler.
DokümantasyonÇalışma yöntemimiz
Kök nedeni bulunan her kapanmış olay, kılavuzu ya da yapılandırma notlarını günceller.