E-ticaret danışmanlığında çalışma modeli, ne kadar sık toplantı yapılacağından önce hangi kararın ve hangi uygulamanın üstlenileceğini belirler. Bir kerelik analiz, belirli bir kurulum projesi ve devam eden operasyon desteği farklı ihtiyaçlara cevap verir. Bu yazının 2025 kökenli adresi ve ilk yayın tarihi korunurken içerik 9 Ekim 2026 tarihinde çalışma kapsamı odağıyla yeniden hazırlanmıştır.
Tek seferlik analizde karar dosyasını teslim olarak tanımlayın
Sorun veya yatırım kararı belirliyse sınırlı bir analiz çalışması tercih edilebilir. Örneğin yeni platforma geçmeden katalog, URL ve entegrasyon ihtiyaçlarını incelemek. Çıktı mevcut durum, seçenekler, belirsizlikler ve karar koşullarıdır. Analizin sonunda uygulama yapılmadıysa mağazanın iyileştiği söylenmemelidir.
Tek seferlik işte veri kesim tarihini kaydedin. Sonraki fiyat, stok veya kampanya değişimi analizin geçerliliğini etkileyebilir. İşletmenin yeni veri geldikçe neyi yeniden kontrol edeceği teslim dosyasında bulunmalıdır.
Analiz ile uygulamanın sınırını görünür kılın
Danışmanlık çalışma modeli, hangi faaliyetin kimin sorumluluğunda olduğunu açıklamalıdır. Bir analiz dosyası sorunları, seçenekleri ve önerileri gösterebilir; kod yayımlama, kampanya açma veya fiyat değiştirme yetkisini kendiliğinden içermez. Teklifin “optimizasyon” gibi geniş bir kelime kullanması bu sınırı ortadan kaldırmaz. İşletme, analiz sonucunda hangi kararı vereceğini ve sonraki uygulama işini kimin üstleneceğini bilmelidir.
Tek seferlik teslimde varsayım ve veri kesim tarihi önemlidir. Katalogdaki maliyet değişmiş veya kampanya sona ermişse eski rapor aynı kararı desteklemeyebilir. Dosyaya yeniden değerlendirmeyi gerektiren koşulları yazın: yeni tedarikçi, farklı kargo bedeli, platform değişimi veya ölçüm kapsamı gibi. Böylece rapor sürekli geçerli bir garanti belgesi gibi kullanılmaz.
Proje modelinde teslim kapılarını ve bağımlılıkları ayırın
Kurulum veya geçiş projesinde keşif, hazırlık, uygulama ve kabul birbirinden ayrılabilir. Her kapı için zorunlu veri ve açık bağımlılık yazılır. Ürün dosyası hazır değilken “tema tamamlandı” demek mağazayı satışa hazır yapmaz. Ödeme sağlayıcısı onayı gibi dış bağımlılıkların takvimde nasıl ele alınacağı belirlenmelidir.
- Keşif: ihtiyaç ve mevcut sistem envanteri.
- Hazırlık: ürün, erişim, hukuki metin ve hizmet hesabı girdileri.
- Uygulama: kapsam dahilindeki teknik ve içerik işleri.
- Kabul: müşteri görevleri, hata durumları ve açık maddeler.
Bu liste bütün projeler için aynı süreyi veya bedeli belirlemez. Geniş katalog ve özel entegrasyon, yalnız hazır tema kurulumundan farklı emek gerektirir. Değişiklik talebinin kapsam ve takvime etkisini sonradan tartışmak yerine başlangıçta tanımlayın.
Her kapının tamamlanma kanıtı farklıdır. Keşif görüşmesinin yapılması, gereksinimlerin onaylandığını göstermez; tasarım görüntüsünün paylaşılması da sipariş yolunun çalıştığını kanıtlamaz. Bir sonraki aşamaya geçmek için zorunlu girdiyi ve kabul eden kişiyi tanımlayın. Dış sağlayıcı onayı bekleniyorsa proje ekibinin kontrolü dışında kalan bu durum teslim kaydında görünmelidir.
Diğer sütunları görmek için yatay kaydırın.
| Kapı | Girdi | Kabul kaydı |
|---|---|---|
| Keşif | İş modeli ve mevcut sistem | Gereksinim ve kapsam dışı işler |
| Hazırlık | Ürün dosyası ve yetkili hesaplar | Eksik veri ve bağımlılık sahipleri |
| Uygulama | Onaylı tasarım ve iş listesi | Gerçek yapılan değişiklik kaydı |
| Kabul | Test ortamı ve senaryolar | Başarılı, başarısız ve açık testler |
Düzenli desteği karar ritmine bağlayın
Devam eden destek, her ay aynı grafiklerin gönderilmesine dönüşmemelidir. Görüşmenin çıktısı hangi kararın alındığı, kimin uygulayacağı ve ne zaman yeniden değerlendirileceğidir. Tekrarlayan ürün, reklam ve operasyon kararları varsa bu model yararlı olabilir; uygulama kapasitesi yoksa bekleyen iş birikir.
Ölçüm için ortak sözlük kullanın: brüt satış, iade sonrası satış, katkı ve tahsilat ayrı tanımlanmalıdır. GA4 raporlarına ilişkin resmî açıklama analitik araçları tanımak için başvurudur. İşletme giderleri ve operasyon kapasitesi ise ayrı kaynaklardan değerlendirilir.
Haftalık veya aylık görüşme sıklığı tek başına düzenli hizmetin kapsamını belirlemez. Görüşmenin hangi karar türlerini ele alacağı ve verinin ne zaman hazırlanacağı yazılmalıdır. Bir mağazada günlük stok istisnaları operasyon ekibinde kalırken danışman aylık ürün ekonomisini değerlendirebilir. Başka bir işletmede yeni kanal projesi için daha sık koordinasyon gerekebilir. Aynı toplantı takvimini her işletmeye uygulamak yerine karar sıklığını esas alın.
Raporlama teslimi hangi durumda yetersiz kalır?
Grafikte düşüş gösterilip önerilen işin sahibi yazılmadıysa uygulama bekleyebilir. Danışmanla işletme bu görevin kapsam içinde olup olmadığını değerlendirmelidir. Düzenli destek dosyası açık işleri, veri bekleyen kararları ve kapsam değişikliklerini de taşısın. Aynı problemin her ay yeni bir grafikle tekrar edilmesi, problemin yeniden analiz edildiği anlamına gelmez.
Değişiklik talebini ayrı bir kapsam kararı olarak kaydedin
Toplantı öncesinde gündem ve ihtiyaç duyulan veri paylaşılmalıdır. Sonrasında yalnız konuşulanların özeti değil, alınan karar, dayanağı, sorumlu ve takip tarihi yazılmalıdır. “Satış düştü, reklam artırılacak” kararı yerine stok, ölçüm ve talep kontrolünün ne gösterdiği açıklanmalıdır.
Belirsiz deney sonucu da geçerli bir çıktıdır. Rapor bunu başarısızlığı gizlemek için kesin başarıya çevirmemelidir. Başka değişkenler etkiliyorsa yeniden test veya daha dar bir analiz önerilebilir. İşletme, hangi kararın hâlâ veri beklediğini görebilmelidir.
Temsili durum: tema işine entegrasyon eklenmesi
Onaylanmış tema düzenlemesi sürerken işletme ikinci depo entegrasyonu istiyor olsun. Bu talep aynı proje görüşmesinde gelmiş olsa da tema kapsamına otomatik dahil değildir. Gerekli API erişimi, stok kaynağı, hata durumu ve kabul senaryosu farklıdır. Talebin takvim, bütçe ve mevcut teslimlere etkisi açıklanıp yetkili kişi tarafından yeni kapsam olarak değerlendirilmelidir.
Yeni iş kabul edilmeden mevcut görevi sessizce ertelemek iki tarafta da yanlış beklenti oluşturur. Kayıtta eski teslimin durumu ve hangi bağımlılığın değiştiği görünsün. Bu senaryo gerçek müşteri çalışması veya platformun belirli paketi için özellik vaadi değildir; kapsam değişikliği yönetimini anlatır.
İşlerin onay ve kabul koşulları sözleşmeye göre farklı olabilir. Bu yazı hukuki hüküm önermez. Ama teknik ve operasyonel dosyanın “istendi”, “onaylandı”, “uygulandı” ve “kontrol edildi” durumlarını ayırması, sözlü beklentilerin gerçek iş kaydına dönüştürülmesine yardımcı olur.
Devir dosyasını çalışma başında tasarlayın
Arıza desteği ile değişiklik talebini ayırın
Çalışan ödeme yolunun durması, yeni bir kategori şablonu istemekle aynı iş türü değildir. Düzenli destek veya proje dosyası, hizmetin bu durumlara nasıl yaklaşacağını açıklamalıdır. Arıza bildiriminin alınması, belirli sürede kesin çözüm garantisi vermez; sağlayıcı hesabı, hata kaydı ve yetkili uygulayıcı gerekebilir. Hangi kanala bildirim yapılacağı ve işletmenin hangi bilgiyi sağlayacağı önceden bilinirse teşhis için gerekli kayıt daha hızlı hazırlanabilir.
İşletme hata kaydına ekran, zaman, etkilenen görev ve tekrar adımını ekleyebilir. Kişisel müşteri verisi veya ödeme kartı bilgisi genel destek notuna konmamalıdır. Hatanın bütün müşterileri mi yoksa belirli ürün veya adres koşulunu mu etkilediği ayrılmalıdır. Bu kayıt, kapsamı açıklanmamış “acil destek” ifadesini gerçek bir iş akışına dönüştürür; hukuki hizmet seviyesi yükümlülüğünü kendiliğinden belirlemez.
Düzenli görüşmeye yeni iş eklenirse ne değişir?
Bir aylık değerlendirme listesine yeni pazaryeri projesi eklemek mevcut destek kapsamını büyütebilir. Yeni işin veri ihtiyacı ve teslim kabulü açıklanmadan toplantı gündemine alınması, bütçe ve kapasite beklentisini belirsizleştirir. Taraflar yeni işi ayrı proje olarak ele alabilir, mevcut kapsamdan başka görevi çıkarabilir veya uygun tarihe erteleyebilir. Seçilen yöntem ve etkilenmiş işler karar kaydında görünmelidir.
Devir sırasında bu kapsam kayıtları da aktarılır. Sonradan katılan bir yetkili kişi hangi işin neden dahil olduğunu ve hangi görevin hâlâ beklediğini anlayabilmelidir. Yalnız raporların son sürümünü saklamak, geçmiş kararların bağlamını kaybettirebilir. Dosya sürümü, karar tarihi ve kaynak açıklaması birlikte tutulduğunda tek seferlik analiz, proje ve düzenli destek farklı ama birbirini tamamlayan çalışma kayıtları haline gelir.
Hesap erişimleri, çalışma dosyaları, özel kod ve açık görevler işletmeye anlaşılır biçimde teslim edilmelidir. Geçici erişimler kaldırılmalı; sürekli hizmet gerektiren bağımlılıklar yazılmalıdır. Platform lisansı veya reklam hesabı danışmana kişisel olarak bağlı kalmamalıdır.
Hazırlık rehberi ilk girdileri, danışman seçimi yazısı teklif karşılaştırmasını tamamlar. Startonal hizmet görüşmesinde ihtiyacınızı bu üç modelden biriyle ilişkilendirip kapsam, teslim ve takip koşullarını netleştirebilirsiniz.
Devir yalnız son toplantıda dosya bağlantısı göndermek değildir. İşletmenin kullanacağı hesap sahibi, çalışma dosyalarının yeri, özel kodun kullanım koşulu ve dış hizmet bağımlılığı baştan bilinmelidir. Gizli değerler rapor içine yazılmamalı; gerekli bilgiler uygun yetki yöntemiyle devredilmelidir. Erişim kaldırılırken çalışan otomasyon veya entegrasyonun kişisel hesaba bağlı olup olmadığı kontrol edilir.
- Üç çalışma modeli arasında teslim farkı açıklanmış.
- Analiz, uygulama ve onay sorumluları ayrılmış.
- Değişiklik taleplerinin etkisini kabul eden kişi belli.
- Veri kesim tarihi ve yeniden inceleme koşulu kayıtlı.
- Açık görevler ve dış bağımlılıklar devir dosyasında görünür.
2025 kökenli slug ve özgün yayın tarihi korunur. Rehber, bugünkü kapsamlandırma kararını ele alır; geçmiş yılın ücret veya paket bilgilerini güncel gibi sunmaz. Doğru çalışma modeli en çok toplantı yapılan model değil, işletmenin kararını ve uygulama sorumluluğunu açık bıraktırmayan modeldir.
