Bölüm 8 akışı
- 1) Operasyon neden “asıl ürün”?
- 2) Intake: talep alma standardı (brief + evrak + hedef)
- 3) Ticket sistemi: destek ve proje taleplerini ayrıştırma
- 4) SLA: beklentiyi yazılı yönetmek
- 5) Teslim checklist: kaliteyi kişiden bağımsız kılmak
- 6) Rol dağılımı: kim, neyi, ne zaman yapar?
- 7) Raporlama: darboğazları veriden görmek
- 8) Büyüme disiplini: kapasite, paket ve fiyat güncellemeleri
- Ara CTA: anahtar teslim paket
- 9) Bölüm 8 özeti + Final’e hazırlık
1) Operasyon neden “asıl ürün”?
Müşteri dışarıdan baktığında “site, tasarım, reklam” görür. Ancak full servis online ajans modelinde müşterinin satın aldığı şey, teknik çıktıların yanında operasyonel güvendir: işler zamanında ilerleyecek mi, sorun olduğunda kim bakacak, hangi sürede dönüş olacak, teslim kalitesi tutarlı mı?
Bu yüzden operasyonu “arka plan” değil, modelin omurgası olarak konumlandırıyoruz. Operasyon zayıfsa; en iyi tasarım, en iyi altyapı ve en iyi POS bile müşteri memnuniyetini taşıyamaz. Güçlü operasyon ise, ortalama bir işi bile iyi bir deneyime dönüştürür.
2) Intake: talep alma standardı (brief + evrak + hedef)
Operasyonun ilk halkası “intake”tir: doğru bilgi, doğru evrak ve doğru hedefi toplamak. Intake zayıfsa proje boyunca revize artar, teslim uzar, müşteri “yanlış anlaşıldım” hissine girer. Bu nedenle intake’i, form + kontrol listesi + onay adımıyla standardize etmek gerekir.
Woventico intake standardı (örnek)
- Hedef netliği: satış mı, lead mi, marka mı?
- Paket doğrulaması: müşteri ihtiyacı pakete uyuyor mu?
- Temel içerikler: logo, renk, metin, örnek siteler
- Operasyon bilgisi: teslim yöntemi, iade yaklaşımı, destek kanalı
- Yasal/mali not: mali müşavirle ilerlenmesi gereken alanlar ayrıştırılır
3) Ticket sistemi: destek ve proje taleplerini ayrıştırma
Aynı kanaldan (WhatsApp) hem “proje revizesi” hem “acil hata” hem de “soru” geldiğinde, ekipte öncelik karmaşası olur. Bu karmaşa büyüdükçe müşteri “kimse bakmıyor” hissine girer. Ticket sistemi bu yüzden kritik: talepleri sınıflandırır, kayıt altına alır ve yönetilebilir hale getirir.
Talepleri sınıflandırma (öneri)
- Incident (Acil): checkout bozuk, ödeme hatası, site erişilemiyor
- Request (İstek): küçük düzenleme, içerik ekleme, görsel güncelleme
- Change (Değişiklik): kapsam etkileyen modül/entegrasyon talebi
- Question (Soru): kullanım, panel eğitimi, yönlendirme
4) SLA: beklentiyi yazılı yönetmek
SLA (Service Level Agreement), destek kalitesinin “niyet” değil “kural” haline gelmesidir. Müşteri ne zaman dönüş alacağını bilir, ekip hangi süre hedefiyle çalıştığını bilir. SLA yazılı değilse, beklenti yönetimi konuşmalarla yürür ve bu da sürdürülebilir değildir.
Basit SLA örneği (pakete göre değişir)
- Acil (Incident): ilk yanıt 1–2 saat, çözüm hedefi 24 saat
- Normal (Request): ilk yanıt aynı gün, çözüm 2–5 iş günü
- Değişiklik (Change): teklif/plan 2 iş günü, uygulama kapsamına göre
5) Teslim checklist: kaliteyi kişiden bağımsız kılmak
Ajanslarda teslim kalitesi, çoğu zaman işi yapan kişinin titizliğine bağlı olur. Sistemli bir modelde ise kalite “kontrol listesi” ile garantiye alınır. Teslim checklist, proje bitmeden önce zorunlu kontrol edilen maddelerin tamamıdır ve ekip değişse bile standardı korur.
E-ticaret teslim checklist (örnek başlıklar)
- Mobil uyum (ürün sayfası, sepet, checkout)
- Hız testleri (özellikle checkout hariç sayfalar)
- Ödeme akışı testi (başarılı + başarısız senaryo)
- E-posta bildirimleri (sipariş, ödeme, iade)
- KVKK / sözleşme linkleri (doğru sayfalara gidiyor mu?)
- Yedekleme ve güvenlik kontrolleri
6) Rol dağılımı: kim, neyi, ne zaman yapar?
Operasyonu oturtmanın bir diğer şartı, rollerin net olmasıdır. “Herkes her şeyi yapar” yaklaşımı küçük ekiplerde çalışır gibi görünür, ancak büyüdükçe kalite dalgalanır. Biz rol dağılımını “tek kişi”ye bağlamadan ama sorumluluğu netleştirerek kurgulamayı hedefledik.
Basit rol modeli (örnek)
- Proje sahibi: zaman planı, müşteri iletişimi, milestone takibi
- Teknik sorumlu: altyapı, performans, güvenlik, entegrasyon
- İçerik/UI: sayfa yerleşimi, CTA, rehber sayfalar
- Destek: ticket triage, SLA takibi, rapor
7) Raporlama: darboğazları veriden görmek
Operasyon gelişimi, “hissettiğimiz sorunlar” üzerinden değil “ölçtüğümüz veriler” üzerinden yapılmalı. Ticket sayıları, çözüm süreleri, en sık gelen sorun kategorileri, checkout hata oranı… Bu metrikler büyüdükçe daha değerli hale gelir.
Takip edilebilir metrikler (örnek)
- Haftalık ticket sayısı ve kategorileri
- SLA uyum oranı (hedef sürede dönüş)
- En sık 10 sorun ve kök neden
- Checkout hata türleri (ödeme başarısız, form hatası vb.)
- Paket bazlı ortalama teslim süresi
8) Büyüme disiplini: kapasite, paket ve fiyat güncellemeleri
Büyüme, daha fazla müşteri almak değildir; daha fazla müşteriyi aynı kaliteyle yönetebilmektir. Bu nedenle büyüme planında üç kontrol noktası olmalı: kapasite (insan/süre), paket standardı (scope netliği) ve fiyat (kârlılık).
Büyüme kontrol noktaları
- Kapasite: haftalık teslim kapasitesi, destek kapasitesi
- Paket: en çok sorun çıkaran paketlerde kapsam revizyonu
- Fiyat: ticket yoğunluğu artıyorsa fiyat/plan güncellemesi
- Süreç: intake ve checklist’te iyileştirme
Anahtar teslim: Operasyonu da düşünerek kurulum yapalım
Sadece siteyi değil; satın alma deneyimini, destek düzenini ve teslim standardını da kurgulayalım. Woventico E-Ticaret Paketleri ile süreci sizin yerinize planlayıp satışa hazır şekilde teslim edelim.
Not: Vergi ve muhasebe tarafında mali müşavirinizle birlikte ilerlemeniz gerekir. Biz süreç planı ve teknik kurulumu üstleniriz.
9) Bölüm 8 özeti + Final’e hazırlık
Bölüm 8’de operasyonun, full servis online ajans modelinin “asıl ürünü” olduğunu gösterdik. Ticket sistemi, SLA, teslim checklist, rol dağılımı ve raporlama; modelin sürdürülebilirliğini sağlar. Bu yapı olmadan büyüme, kaçınılmaz olarak kalite dalgalanmasına yol açar.
Final bölümde, bu seride anlattığımız adımları tek bir çerçevede toplayacağız: 30 günlük uygulanabilir yol haritası, maliyet kalemleri, risk yönetimi, hızlandıran ipuçları ve “full servis online ajans” modelini başka ekiplerin de uygulayabileceği şekilde net bir kontrol listesi.