Bir e-pin satış scripti satın alırken çoğu işletme sahibi karşılaştırmayı özellik listesi üzerinden yapar: kaç ödeme yöntemi var, kaç bayi entegrasyonu geliyor, tema kaç renk. Oysa lisansı aldıktan sonraki ilk altı ayda hayat kalitesini belirleyen şey bu liste değil. Belirleyen şey, cuma akşamı 21:30'da ödeme sayfası patladığında kime yazdığın ve o mesaja kaç dakikada cevap geldiğidir.
Teknik destek, satın alma anında görünmez olduğu için de kolayca atlanır. Satıcı "destek dahildir" der, alıcı bunu sınırsız ve süresiz sanır. Sonra ilk kriz gelir ve "dahil" kelimesinin ne kadar geniş yorumlandığı ortaya çıkar. Bu yazıda bir dijital ürün satış yazılımı alırken destek sürecini nasıl denetlemen gerektiğini, SLA'nın gerçekte hangi sayılardan oluştuğunu ve destek talebini nasıl yazarsan çözüm süresini yarıya indireceğini anlatıyorum.
"Destek dahil" ifadesi tam olarak neyi kapsıyor?
Destek kelimesi tek başına hiçbir taahhüt içermez. Aynı ifadenin arkasında üç bambaşka hizmet olabilir. Birincisi kusur giderme: yazılım belgelendiği gibi çalışmıyorsa üretici düzeltir. İkincisi kurulum ve yapılandırma yardımı: sunucuya yerleştirme, alan adı bağlama, ödeme anahtarlarının tanımlanması. Üçüncüsü özelleştirme: senin işine özel yeni bir modül, farklı bir bayi entegrasyonu, tema değişikliği.
Ciddi bir sağlayıcı bu üçünü ayrı ayrı tanımlar ve ilk ikisini lisans kapsamında, üçüncüsünü ayrı bir iş kalemi olarak sunar. Bunu peşinen söylemek dürüstlüktür, gizlemek ise ileride yaşanacak tartışmanın tohumudur. Satın almadan önce tek bir soru sor: "Şu üç örnek talep kapsam içinde mi?" Örnekleri sen ver — bir ödeme sağlayıcısı ekleme isteği, bir SQL hatası, bir tema renk değişikliği. Gelen cevabın netliği, o firmanın destek kültürü hakkında broşürden çok daha fazlasını anlatır.
SLA aslında hangi sayılardan oluşuyor?
SLA, yani hizmet seviyesi taahhüdü, tek bir süre değildir. En az dört ayrı sayıyı içerir ve bunları karıştırmak en yaygın yanılgıdır. İlk yanıt süresi, talebine bir insanın dönmesi için geçen süredir. Çözüm süresi, sorunun gerçekten bitmesi için geçen süredir. Çalışma penceresi, desteğin hangi gün ve saatlerde aktif olduğudur. Öncelik sınıfı ise hangi sorunun hangi süreyle işlendiğini belirler.
Bir arıza "kritik" ise satış tamamen durmuştur; "yüksek" ise satış sürüyor ama bir modül bozuktur; "normal" ise rahatsızlık vardır ama para akışı etkilenmez. Bu sınıfları kim belirliyor sorusu da önemlidir: sen mi, sağlayıcı mı, ikisi birlikte mi? Aşağıdaki tablo, bir e-pin yazılımı için makul kabul edilebilecek seviyeleri gösteriyor. Teklif aldığın rakamları bu satırlarla karşılaştır.
| Öncelik | Örnek durum | İlk yanıt | Çözüm hedefi | Kanal |
|---|---|---|---|---|
| Kritik | Site kapalı, ödeme alınamıyor | 1-4 saat | Aynı gün | Telefon / anlık mesaj |
| Yüksek | Teslimat gecikiyor, bir bayi API'si bozuk | 4-8 saat | 1-2 iş günü | Ticket + mesaj |
| Normal | Rapor ekranı yanlış toplam veriyor | 1 iş günü | 3-5 iş günü | Ticket |
| Düşük | Metin düzeltmesi, küçük görsel kusur | 2 iş günü | Sürüm planına göre | Ticket |
| Talep | Yeni modül, özel entegrasyon | 2 iş günü | Teklifle | Ticket |
Destek talebini nasıl yazarsan cevabı iki kat hızlanır?
Destek ekibinin ilk işi senin sorununu yeniden üretmektir. Bunu yapamazsa sana soru sorar ve her soru-cevap turu en az yarım gün ekler. "Sistem çalışmıyor" yazan bir talep, ne kadar iyi bir sağlayıcıya gitse de yavaş çözülür. Buna karşılık iyi yazılmış tek bir mesaj, sorunu ilk turda bitirebilir.
İyi bir talep şunları içerir: ne yapmak istedin, ne bekledin, ne oldu; hangi sayfada ve hangi saatte; etkilenen sipariş numarası; tam hata metni; ekran görüntüsü veya kısa video; kaç kullanıcının etkilendiği ve sorunun her seferinde mi yoksa ara ara mı tekrarladığı. Bir de şunu ekle: son 48 saatte sistemde ne değiştirdin? Eklenti, sunucu ayarı, PHP sürümü, yeni ödeme anahtarı. Arızaların çok büyük kısmı son değişiklikle ilgilidir ve bunu baştan söylemek tanı süresini dramatik biçimde kısaltır.
E-pin satıcılarının açtığı destek taleplerinin gerçek dağılımı
- Yapılandırma ve kullanım soruları 47%
- Üçüncü taraf kaynaklı sorunlar 23%
- Gerçek yazılım kusuru 18%
- Özelleştirme istekleri 12%
Sorun yazılımda değil de sunucuda ya da sağlayıcıdaysa ne oluyor?
Bu, destek sürecinin en çok yanlış anlaşılan noktası. Bir e-pin panelinin çalışması için en az beş tarafın uyumlu olması gerekir: yazılım, sunucu, ödeme sağlayıcısı, bayi API'si ve alan adı altyapısı. Arıza bunlardan herhangi birinde çıkabilir, ama müşteri her durumda yazılımı satan kişiye yazar. Sağlığı yerinde bir süreçte sağlayıcı, sorunun hangi tarafta olduğunu kanıtlayarak gösterir: istek ve yanıt kayıtlarını paylaşır, hangi adımın hangi hatayı döndüğünü işaret eder.
Burada senin de bir sorumluluğun var: paylaşımlı hosting üzerinde çok düşük kaynak limitleriyle çalışıyorsan, zamanlanmış görev desteği olmayan bir pakette teslimat kuyruğu bekliyorsan, sorun yazılımda değildir. Bu yüzden lisans almadan önce asgari sistem gereksinimlerini yazılı olarak isteyin ve barındırmanızı ona göre seçin. Bu tek adım, ilk aydaki destek yükünün yarısını ortadan kaldırır.
Lisans parasını ödemeden önce satış öncesi kanaldan teknik bir soru sor: "Sunucumda cron yok, teslimat kuyruğu nasıl çalışır?" Gelen cevabın hızı ve derinliği, satış sonrası alacağın desteğin en dürüst göstergesidir. Pazarlama metni yalan söyleyebilir, yanıt süresi söyleyemez.
Destek kalitesini kendi tarafından nasıl ölçersin?
Taahhüt edilen süreleri ölçmezsen, taahhüt yoktur. Basit bir tablo tut: talep tarihi, öncelik, ilk yanıt saati, çözüm saati, kaç tur gitti geldi, kalıcı çözüldü mü. Üç ay sonra elinde bir gerçeklik var olur ve yenileme görüşmesine duyguyla değil veriyle girersin. "Son çeyrekte kritik taleplerde ilk yanıt ortalaman 9 saat, taahhüt 4 saatti" cümlesi, herhangi bir şikayetten çok daha etkilidir.
Bir de tekrarlayan talepleri ayrı işaretle. Aynı sorun üçüncü kez açıldıysa çözüm değil yama alıyorsun demektir. İyi bir e-pin satış yazılımı sağlayıcısı, tekrarlayan bir kusuru sürüm notlarında kalıcı olarak kapatır ve bunu sana bildirir. Aşağıdaki liste, süreci denetlemek için kullanabileceğin somut maddeleri içeriyor.
| Denetim maddesi | Ne arıyorsun | Zamanı | Önem |
|---|---|---|---|
| Kapsam tanımı yazılı mı | Kusur / kurulum / özelleştirme ayrımı | Satın alma öncesi | Kritik |
| Öncelik sınıfları tanımlı mı | Kritik-yüksek-normal eşikleri | Satın alma öncesi | Kritik |
| Çalışma penceresi | Hafta sonu ve gece kapsamı | Satın alma öncesi | Yüksek |
| Kayıtlı talep kanalı | İz bırakan ticket sistemi var mı | Kurulumda | Yüksek |
| Güncelleme politikası | Sürüm sıklığı ve geriye uyumluluk | Satın alma öncesi | Yüksek |
| Sistem gereksinimleri | PHP, veritabanı, cron, bellek | Barındırma seçiminde | Kritik |
| Devir / erişim | Kaynak koda ve veriye erişim hakkın | Sözleşmede | Yüksek |
| Kendi ölçüm tablon | Yanıt / çözüm sürelerinin kaydı | Sürekli | Orta |
Desteği sözleşmede değil, ilk mesajda göster
Pinova'nın teknik destek kapsamı, öncelik sınıfları ve sistem gereksinimleri baştan yazılı olarak paylaşılır. Lisans seçeneklerini incele, satın almadan önce bize teknik bir soru sor.
Teknik destek ne kadar süre boyunca ücretsiz olmalı?
Piyasada yaygın uygulama, lisansla birlikte belirli bir süre kusur giderme ve kurulum desteğinin dahil olmasıdır. Önemli olan sürenin uzunluğu değil, kapsamın yazılı olmasıdır; sınırsız denip kapsamı belirsiz bırakılan bir taahhüt hiçbir şey ifade etmez.
SLA ihlal edilirse ne yapabilirim?
Önce kendi ölçüm kaydınla ihlali göster; ciddi sağlayıcılar bunu telafi süresi, ek destek veya yenilemede indirim ile karşılar. Bu yüzden süreleri baştan yazılı almak ve kendi tarafında kaydetmek gerekir.
Kendi geliştiricim kodda değişiklik yaparsa destek düşer mi?
Genellikle değiştirilen bölümler kapsam dışına çıkar, çünkü sağlayıcı kendi yazmadığı kodu garanti edemez. Doğru yöntem, özelleştirmeleri çekirdek dosyalara dokunmadan ayrı bir katmanda yapmak ve değişiklikleri kayıt altında tutmaktır.
Sorunun sunucumdan kaynaklandığı nasıl anlaşılır?
Aynı kurulumun farklı bir ortamda sorunsuz çalışması, sunucu kaynaklı bir sınır olduğunu gösterir. Bellek limiti, işlem süresi, zamanlanmış görev desteği ve giden bağlantı izinleri ilk bakılacak dört başlıktır.
Bir e-pin scripti satın alırken aslında iki şey satın alırsın: bugünün özellikleri ve yarının destek süresi. İlki demoda görünür, ikincisi ilk krizde. Kapsamı yazılı isteyen, öncelik sınıflarını netleştiren ve kendi ölçümünü tutan satıcı, her iki tarafı da adil bir zemine oturtur. Sistemin gerçekte nasıl çalıştığını görmek ve destek ekibine ilk teknik sorunu sormak için özellikleri ve fiyatlandırmayı incele, ardından canlı demo üzerinde kendi senaryonu dene.