Her Müşterinin Mağazasını Yeniden Kurmayı Bırakın: Tekrarlanabilir Bir Müşteri Alım Sistemi

Özet

Müşteriniz öğleden sonra 4:53'te tek satırlık bir istek gönderiyor ve siz yine geçen hafta çözdüğünüz aynı sorunu çözmek için mağazasının içindesiniz. Bu makale bu kaosu tekrarlanabilir bir müşteri alım sistemine dönüştürüyor: standartlaştırılmış bir bilgi toplama formu, bir platform karar matrisi, ödeme yığını varsayılanları, uyumluluk kontrolleri, ürün verisi standartları, bir hazırlık test betiği ve bir lansman kapısı. Sistem, mum butikleri ve 300 SKU'lu dropshipper'lar için de aynı şekilde çalışır. Araçları alışkanlıkla seçmeyi bırakacak ve kanıta dayalı seçmeye başlayacaksınız. Herhangi bir adımı atlarsanız, maliyet ilk gerçek siparişte ortaya çıkar. Sistemi bir kez kurun ve gelecekteki her müşteri aynı rayları izler. Müşteri sorun değil — süreciniz sorun.

Müşteriniz Cuma günü öğleden sonra 4:53'te tek satırlık bir istek gönderiyor: 'Instagram'ıma bir satın alma butonu ekleyebilir misin?' Bu hafta mağazasını zaten bir kez yeniden kurdunuz. Durun. Müşteri sorun değil; süreciniz sorun. Bu makale size tekrarlanabilir bir müşteri alım sistemi sunuyor: standartlaştırılmış bir bilgi toplama formu, bir platform karar matrisi, ödeme yığını varsayılanları, uyumluluk kontrolleri, ürün verisi standartları, bir hazırlık test betiği ve bir lansman kapısı. Bir kez kurun ve gelecekteki her mağaza aynı rayları izler. Aynı sorunu yeniden çözmeyi bırakacak ve mağazaları teslim etmeye başlayacaksınız.

1. Bilgi toplamayı bir sohbet değil, bir kapı olarak işletin

Bir müşteri 12 kokulu mum satıyor ve tatil pazarından önce lansman yapması gerekiyor. Bir diğeri üç farklı tedarikçiden 300 SKU dropshipping yapmak istiyor. Mum müşterisi hızla ilgileniyor; dropship müşterisi envanter senkronizasyonu ve sipariş yönlendirmeyle ilgileniyor. İkisine de 'bütçeniz nedir ve hangi platformu istiyorsunuz' diye sorarsanız, iki işe yaramaz cevap alırsınız ve ardından bir ay içinde o mağazalardan birini yeniden kurarsınız.

Herhangi bir araca dokunmadan önce tek sayfalık bir özet form gönderin. Bu soruları zorunlu hale getirin:

• İlk 90 günde kaç SKU satmayı planlıyorsunuz?
• Fiziksel, dijital veya karma mı?
• Siparişleri kim karşılıyor — siz, bir tedarikçi veya üçüncü bir taraf mı?
• Ortalama sipariş değeri nedir?
• Eyalet veya ülke sınırları ötesinde satış yapıyor musunuz? Vergi mükellefiyetiniz nerede?
• Abonelik, ön sipariş veya çoklu ürün paketleri sunacak mısınız?
• Bu mağazanın ilk ayda sahip olması gereken tek özellik nedir?

Müşterinin cevapları bir aramada size söylemek yerine yazmasını sağlayın. Yazılı cevaplar bir kayıt haline gelir. Sözlü cevaplar altıncı haftada 'Ben bunu demedim' haline gelir.

Ardından kısıtların üç satırlık bir özetini yazın: bütçe, hız ve olmazsa olmaz özellik. Bunu proje dosyasının en üstüne koyun. Müşteri daha sonra mimariyi değiştiren bir özellik istediğinde, özet formu gösterin ve deyin: 'Bu platformu değiştirir. Maliyeti şu.'

Bu neden önemli: platform seçimi bu formun bir çıktısıdır. Bunu atlarsanız, geçen sefer kullandığınızı seçersiniz. E-ticaret platformları üzerine yapılan araştırmalar tek bir noktada hemfikir: farklı iş modelleri farklı mimari gerektirir. 12 SKU'lu bir mum dükkanı ile 300 SKU'lu bir dropshipper farklı işletmelerdir, bu yüzden onlara farklı davranın. Daha önce tek bir platformun her müşteriye uymayacağından bahsetmiştik; bu form bunu nasıl işler hale getirdiğinizdir.

2. Platform matrisini alışkanlıkla değil, müşteri profiline göre oluşturun

İşte sürekli bozulan desen: her yeni mağaza için aynı barındırılan sürükle-bırak oluşturucuyu açıyorsunuz çünkü hızlı. Sonra fiziksel mağazası olan bir müşteri envanterin yazar kasa ile senkronize olmasına ihtiyaç duyuyor. Favori oluşturucunuz üç ücretli uygulama olmadan bunu yapamıyor. Üçüncü haftada platform değiştiriyorsunuz ve herkes zaman kaybediyor.

Bir karar matrisi bunu çözer. Müşteri kısıtlarını marka adlarına değil, platform kategorilerine eşler. Bunu paylaşılan bir belgede tutun ve üç ayda bir güncelleyin. Bu çalışan sürümle başlayın:

Müşteri profili	Platform kategorisi	Ne zaman kazanır?
Düşük SKU sayısı, hızlı lansman, teknik olmayan sahip	Barındırılan sürükle-bırak oluşturucu	Hız, uygulama ekosistemi, yerleşik barındırma
Mevcut içerik sitesi, tasarım kontrolü önemli	Mevcut CMS için açık kaynaklı mağaza eklentisi	Siteyi koru, ticareti ekle
Yüksek SKU sayısı, karmaşık katalog, büyüme planları	Güçlü API ile ölçeklenebilir barındırılan platform	Özel entegrasyonlar, çok kanallı
Fiziksel mağaza artı çevrimiçi mağaza	POS entegre oluşturucu	Kanallar arası envanter senkronizasyonu
Dar bütçe, az ürün	Hafif gömülü mağaza vitrini	Düşük aylık maliyet, basit ödeme

Bu bir kategori haritasıdır, bir sıralama değil. Çok para birimi ve abonelik gerektiren bir müşteri, o satırı beğenin ya da beğenmeyin, ölçeklenebilir satıra aittir. Beş ürünü olan bir müşteri kurumsal altyapı satın almamalıdır.

Ücretsiz denemeleri bilinçli kullanın. Araştırmalar tutarlı: birçok platform ücretsiz deneme sunuyor. Çoğu insan bu denemeleri şablonlara tıklayarak harcıyor. Bunun yerine, müşteri formundan bir test yapın. 300 gerçek SKU içe aktarın. İçe aktarma başarısız olursa, o platformun üzerini çizin. Gerçek bir test siparişiyle ödemeyi test edin. Vergi ayarlarının müşterinin eyaletini kapsayıp kapsamadığını kontrol edin. Gerçek kısıtlarınızı simüle eden bir deneme bir karardır; simüle etmeyen eğlencedir.

Müşteri bu platformu neden seçtiğinizi sorduğunda, matrisi ve formu gösterin. Savunabileceğiniz bir platform kararı almanın yolu budur; müşterinin patronuna, müşterinin muhasebecisine veya kendi ekibinize karşı.

3. Ödeme yığınını alışkanlığa göre değil, nakit akışına göre belirleyin

İki müşteri, iki nakit akışı gerçeği. Biri 40 dolarlık mum satıyor ve bir hafta boyunca para yatmasını bekleyebilir. Diğeri 800 dolarlık mobilya satıyor ve bir sonraki sipariş için malzeme almak üzere paranın günler içinde hesabına geçmesi gerekiyor. Onları aynı ödeme kapısıyla kurarsanız, birini başarısızlığa hazırlamış olursunuz. Ödeme işleme kılavuzları tutarlı bir şekilde üç operasyonel kola işaret eder: para yatırma hızı, fiyatlandırma şeffaflığı ve destek kalitesi. Bunlarla öne çıkın.

Bu sırayı izleyin:

1. Müşterinin nakit döngüsünün ne olduğunu sorun. Haftalık veya günlük para yatırma? Bazı işlemciler daha hızlı öder ve bazıları belirli işletme türleri için fonları daha uzun süre tutar.
2. Seçtiğiniz platform kategorisiyle ödeme kapısının entegrasyonunu kontrol edin. Form gerektiriyorsa abonelikleri destekliyor mu? Formunuzdaki ülkeleri destekliyor mu?
3. Oluşturmadan önce müşterinin ürün kategorisini işlemcinin kısıtlanmış listesiyle kontrol edin. Yüksek riskli kategoriler hesap dondurulması alır, uyarı e-postası değil.
4. Müşterinin zaten müşterilerinin güvendiği bir ödeme yöntemi varsa — örneğin yaygın olarak tanınan bir cüzdan — ücret eklese bile dahil edin. Güven, ücret farkından daha iyi dönüştürür.
5. Müşterinin onayladığı ödeme kapısını, hesabı ve ödeme programını belgeleyin. Bunu tarihiyle birlikte proje dosyasına koyun.

Somut örnek: mobilya müşterisinin hızlı para yatırma ve büyük sipariş değerleri için desteğe ihtiyacı var. Mum müşterisinin basit bir ödeme ve düşük genel giderlere ihtiyacı var. İlki için API öncelikli bir işlemci, ikincisi için yeni başlayan dostu bir işlemci kullanabilirsiniz. Matris karar verir. Alışkanlığınız değil.

Bunu atlarsanız, sorun lansmandan iki hafta sonra, müşteri parasının takıldığını söylemek için aradığında ortaya çıkar. Ödeme yeniden çalışması ödemeyi, makbuzları, vergi raporlarını ve müşterinin güvenini etkiler. Yeniden inşa edebileceğiniz en pahalı şeydir.

4. Tasarımdan önce uyumluluk kontrolleri yapın

Her yerde yasal olan bir besin takviyesi satan bir müşteri alıyorsunuz. Temiz bir mağaza kuruyorsunuz, bir ödeme işlemcisine bağlanıyorsunuz, yayına geçiyorsunuz. Altı hafta sonra işlemci, ürün kategorisi bir lisans ve uyumluluk incelemesi gerektirdiği için hesaba bloke koyar. Tasarımınız hiçbir zaman sorun değildi. Eksik evraktı.

Uyumluluk bir lansman kapısıdır, idari iş değil. Herhangi bir tasarım çalışmasından önce şunları doğrulayın:

• İşletme kaydı, müşterinin gerçek kuruluşuyla eşleşiyor.
• Müşterinin vergi bağlantısı olan her eyalet için satış vergisi kayıtları var.
• Ürün kategorisi, bağlanacağınız ödeme işlemcisi tarafından izin veriliyor.
• Müşteri, ürün türünün gerektirdiği lisanslara veya izinlere sahip.
• Hizmet şartları, gizlilik politikası, iade politikası ve gönderim politikası yazılmış ve mağazanın gerçekte yaptıklarıyla eşleşiyor.

Bunu bir konuşma olarak değil, onay kutulu bir kontrol listesi olarak yürütün. Müşteri 'avukatım halleder' dediğinde bir son tarih belirleyin. Son tarih geçerse lansman tarihi ertelenir. Bu sizin zorluk çıkarmanız değil; lansmanı korumanızdır.

Çevrimiçi mağazalar için yaygın tavsiye 'küçük başlayın ve yineleyin' şeklindedir. Bu, ürün seçimi ve pazarlama için işe yarar. Uyumluluk için işe yaramaz. İşlemci hesabı dondurduğu için mağazayı yeniden kurmak yineleme değildir; israftır. Baştan yasal kurulum işi üzerinden hızlıca geçmek, donmuş bir ödemeden daha az maliyetlidir. Bu adımı atlarsanız, en iyi ihtimalle belgeler için koşturursunuz. En kötü ihtimalle işlerini batırdığınızı düşünen bir müşteridir.

5. Ürün verisi sözleşmesini standartlaştırın

Bir müşteri 300 ürünlü bir elektronik tablo gönderir. Her satırda bir ad ve bir fiyat vardır. Hiçbir satırda ağırlık, boyutlar, menşe ülkesi veya tedarikçi kodu yoktur. Eksik alanları istersiniz. Müşteri neden önemli olduğunu görmez. Proje bir hafta durur. Ardından gönderim ücretini hesaplayamadığınız için 'ücretsiz' olarak ayarlı şekilde lansman yaparsınız ve müşteri hatanın bedelini öder.

Ürün verilerini hangi biçimde gelirse gelsin kabul etmeyi bırakın. Bir ürün verisi sözleşmesi tanımlayın. Her ürün en az şunları içermelidir:

• Dahili SKU ve barkod
• Ürün adı ve sitede yayınlanacak açıklama
• Fiyat ve karşılaştırma fiyatı
• Gönderim için ağırlık ve boyutlar
• Menşe ülkesi ve uluslararasıysa uyumlaştırılmış sistem kodu
• Tedarikçi ve teslim süresi
• Gönderim profili (taşıyıcı sınıfı ve bölgeler)
• Ürün fotoğrafı dosya adı ve alternatif metin
• Vergi kategorisi

Aynı iki müşteriyi ele alalım. Mum müşterisi size 12 SKU verir. Alanları bir saatte kurarsınız. Dropshipper 300 SKU verir. Her tedarikçiden bir CSV dışa aktarımı istersiniz ve bu sütunları sözleşmeyle eşlersiniz. Bir tedarikçi bir alan sağlamazsa, bu müşterinin çözmesi gereken bir tedarik sorunudur, sizin tahmin yürütebileceğiniz bir veri sorunu değil.

Standartlaştırılmış ürün verisi, platform geçişini ucuzlatan tek şeydir. Katalog doğru yapılandırılırsa, müşteriyi farklı bir platforma taşımak bir içe aktarma işlemidir, yeniden inşa değil. Değilse, 300 satırı yeniden yazarsınız ve yanlış yaparsınız. Ayrıca, kopya ve alternatif metin zaten sözleşmede olduğu için, satış yapan ürün listeleri oluşturmak için bu yapılandırılmış veriyi kullanabilirsiniz.

6. Her mağazada aynı hazırlık test betiğini çalıştırın

Müşteriniz sabah 9'da bir ekran görüntüsü gönderiyor: 'Benden iki kez gönderim ücreti aldı.' Giriş yapıyorsunuz ve yanlış ülkeden bir vergi oranı ve gönderim mantığıyla çakışan bir indirim kodu buluyorsunuz. Düzeltmek yirmi dakika sürüyor. Ama müşteri az önce güvenini kaybetti ve güven tüm iştir.

Bir test betiğine ihtiyacınız var. Aynı sipariş, aynı adımlar, her müşteri:

1. Test ödeme yöntemiyle gerçek bir test siparişi verin.
2. Onay e-postasının müşteriye ulaştığını doğrulayın.
3. Bir iade işlemi yapın ve müşterinin bunu gördüğünü doğrulayın.
4. Bir indirim kodu uygulayın ve matematiği kontrol edin.
5. Misafir ödeme ve giriş yapılmış ödemeyi ayrı ayrı kontrol edin.
6. Yalnızca masaüstü önizlemesini değil, bir mobil telefondan ürünü sepete ekleyin.
7. Müşteri uluslararası gönderim yapıyorsa, uluslararası bir gönderim adresi test edin.
8. Müşterinin ana eyaleti ve başka bir eyalet için vergi hesaplamasını kontrol edin.
9. Reddedilen bir ödemeyi tetikleyin ve hata mesajını doğrulayın.
10. Satış yapıldığında envanterin azaldığını doğrulayın.

Hazırlık veya taslak modunda düşük fiyatlı bir test ürünü kullanın. Birçok platform ücretsiz deneme modu sunar; bunları şablonlara bakmak için değil, bunun için kullanın. Testi mağaza başına yarım saatle sınırlandırın. Tekrarlanabilir bir test betiği, 'her şey muhtemelen iyi' yaklaşımından daha hızlıdır çünkü neyi unuttuğunuzu asla merak etmezsiniz.

Bunu atlarsanız, bilerek bozuk bir mağaza yayınlamazsınız. Test edilmemiş tek bir yolu olan bir mağaza yayınlarsınız ve ilk gerçek müşteri onu bulur.

7. Platformun ilk karar olmasına izin vermeyi bırakın

Bir müşteri bir müşteri alım görüşmesine katılır ve 'Popüler barındırılan oluşturucuyu istiyoruz çünkü pazarlamadaki biri bir kez kullandı' der. Gereksinimlerini bu araca haritalamak için iki gün harcarsınız ve formun gerektirdiği çok para birimli ödemeyi yapamadığını keşfedersiniz. Şimdi iki seçeneğiniz var: haberi verip müşteriyi rahatsız etmek veya yanlış şeyi inşa etmek.

Platform bir çıktıdır, girdi değil. Form işi tanımlar. Karar matrisi kategoriyi seçer. Ancak o zaman belirli bir araç seçersiniz. Bu disiplin ters gibi geliyor çünkü platform pazarlaması önce aracı seçmenizi istiyor. Direnin.

İşte çoğu makalenin atladığı gerçek ödünleşim: bazen müşterinin kısıtı meşrudur. Müşterinin belirli bir platformu bilen bir geliştiricisi veya yalnızca belirli bir ekosistemle entegre olan bir depo sistemi varsa, bu kısıt matrise aittir. Forma 'mevcut X ile entegre olmalı' olarak yazın. Ardından onu barındıran kategoriyi seçin. Kısıt yalnızca marka tercihiyse, müşteriye o platformdan hangi işi beklediklerini sorun. Gerçekte istedikleri genellikle bir özelliktir ve mimariyi değiştirmeden bu özelliği sunabilirsiniz.

Uyarı gerçek: göremediğiniz gelecekteki ihtiyaçlar için aşırı mühendislik yapmayın. Mum müşterisinin çoklu tedarikçi entegrasyonuna ihtiyacı yok. Dropshipper'ın var. Hayali bir geleceğe değil, forma göre eşleştirin. Müşteri '18 ay içinde uluslararası genişlemeyi planlıyoruz' derse, bunu not edin ve bunu engellemeyecek bir kategori seçin. 'Sadece bunu test etmek istiyoruz' derse, en hızlı seçeneği seçin ve daha sonra yeniden platform oluşturmayı planlayın. Form için inşa edin.

8. Lansmanı minimum uygulanabilir kataloğa bağlayın

Bir müşteri siteyi çok seviyor. Sadece ürün fotoğrafları yok. 'Gelecek hafta' diyorlar. Üç hafta sonra mağaza hala 'Yakında' yer tutucusunun arkasında duruyor. Ekibiniz zamanı doldurmak için ekstra özellikler eklemeye başlıyor çünkü kimse müşteriye projenin kendi taraflarında engellendiğini söylemek istemiyor. Ardından kapsam büyür ve saatleri harcarsınız.

Bir lansman kapısı belirleyin. Proje başlamadan önce minimum uygulanabilir bir katalog tanımlayın. Mağazanın niş içinde gerçek hissettirmesi için yeterli ürün içermelidir — bir butik için bir düzine sağlam ürün genellikle yeterlidir, oysa bir dropshipper 300'ün tümü yerine en iyi performans gösterenlerin seçilmiş bir setine ihtiyaç duyabilir. Bu setteki her ürünün bir fotoğrafı, fiyatı, açıklaması, ağırlığı ve boyutları ve onaylanmış bir tedarikçisi olmalıdır. 'Yakında' ürün sayfaları olmamalı. Yer tutucu metin olmamalı.

Lansmanı şu koşullara bağlayın, hepsi ikili:

• Bilgi toplama formu dolduruldu ve onaylandı.
• Ürün verisi sözleşme dosyası, lansmandaki her ürün için eksiksiz.
• Ödeme yığını onaylandı ve test siparişi geçti.
• Uyumluluk kontrol listesi tamamlandı.
• Hazırlık test betiği geçti.

Müşteri 'Hazır olan ürünlerle lansman yapabilir miyiz?' diye sorduğunda, bu ürünler tam sözleşmeyi karşıladığı sürece cevap evettir. Bu mükemmeliyetçilik değil; tekrarlanabilirliktir. Kapı, görünmeyen bir bağımlılığa sahip bir mağazayı asla yayınlamamanız için vardır.

Kapıyı atlarsanız, müşterinin eksik işini üstlenirsiniz. Bulanık fotoğrafları düzenlersiniz, gönderim ağırlıkları icat edersiniz ve vergi kategorilerini tahmin edersiniz. Bu tahminler iadelere, ters ibrazlara ve olumsuz yorumlara dönüşür. Lansman kapısı, sizin işiniz ile müşterinin işi arasındaki sınırdır.

Sonuç: Süreciniz üründür

Web sitesi satmıyorsunuz. 'Bir mağaza istiyorum' ile 'mağaza canlı ve siparişleri işliyor' arasında öngörülebilir bir yol satıyorsunuz. Bu yolun doğaçlama değil, varsayılanlara ihtiyacı var.

Bir sonraki sefer bir müşteri Cuma günü öğleden sonra 4:53'te yazdığında, hiçbir şeyi yeniden çözmek zorunda değilsiniz. Formu çalıştırırsınız, matrisi kontrol edersiniz, ödeme yığınını gözden geçirirsiniz, uyumluluk listesini çalıştırırsınız, ürün verilerini doğrularsınız ve test betiğini yürütürsünüz. Ardından e-postayı bir tahmin yerine bir planla yanıtlarsınız.

Sisteme küçük başlayın. Bu hafta bir müşteriyi bilgi toplama formuna ekleyin. Matrisi paylaşılan bir belgede oluşturun. Test betiğini bir kez yazın ve yeniden kullanın. Şimdi standartlaştırdığınız her adım, sonraki beş müşteri için tekrarlamayacağınız bir hatadır.