Size Savunabileceğiniz Bir Mağaza Platformu Seçin

Özet

Çoğu platform önerisi, özgüvene sarılmış tahminlerden ibarettir. Kişisel favoriniz değil, tüm müşterilerde işe yarayan bir karar sürecine ihtiyacınız var. Bu rehber, mağaza kurulumlarını rayından çıkaran yaygın efsaneleri tek tek ele alıyor — müşterinin platformu seçmesine izin vermekten ödemeyi sonradan akla gelmek olarak görmeye kadar. Platform katmanlarını tanımlamayı, kısa bir keşif süreci yürütmeyi ve ödeme ücretleri ile para yatırma hızını içeren bir maliyet modeli oluşturmayı öğreneceksiniz. Ayrıca bir uyarı da alacaksınız: süreci standartlaştırın, ürünü değil. Amaç, bir sonraki önerinizi savunulabilir kılan tekrarlanabilir bir çerçeve oluşturmak.

Yeni bir mağaza projesi aldınız. Müşteri soruyor: 'Hangi platformu önerirsiniz?' Gerçekte ne diyorsunuz?

Favori platformunuzla yanıtlarsanız, bir iş kararını sadece önseziyle vermiş olursunuz. O sabah bulduğunuz bir karşılaştırma tablosuyla yanıtlarsanız, kararı başka birinin işi için yazılmış bir bloga devretmiş olursunuz. Müşterinin ürünlerine, ödeme gerçekliğine ve nakit akışına uygun bir platforma ihtiyacı var. Önümüzdeki ay kapınızdan girecek herkese ve ondan sonraki aya uyacak bir sürece ihtiyacınız var.

Çoğu e-ticaret platformu tavsiyesi mağaza sahibi için yazılır. Bu rehber ise mağazayı teslim etmesi gereken, mimariyle ilgilenmeyen bir müşteriye seçimi haklı çıkarması gereken ve toplantıda bulunmayan bir geliştiriciye devretmesi gereken kişi için yazılmıştır. Sizin işiniz, kararı tembellik yapmadan tekrarlanabilir kılmak.

Bunu yapmanın en hızlı yolu, çoğu ekibin taşıdığı varsayımlara saldırmaktır. İşte efsaneler ve gerçekler.

Efsane	Gerçek
Tek bir en iyi platform vardır.	En iyisi, ürün karmaşıklığına, ödeme ihtiyaçlarına ve mağazayı kimin yönettiğine bağlıdır.
Platformu müşteri seçer.	Siz keşif yaparsınız ve savunulabilir bir öneride bulunursunuz.
En düşük aylık ücret kazanır.	Toplam maliyet; ödeme ücretlerini, uygulamaları, bakımı ve sizin zamanınızı içerir.
Her ödeme ağ geçidi çalışır.	Ağ geçidi seçimi; nakit akışını, uluslararası satışları ve destek yükünü şekillendirir.
Lansman bitiş çizgisidir.	Lansman, ölçüm ve iyileştirmenin başlangıcıdır.
Tüm müşteriler için tek platform.	Süreci standartlaştırın, ürünü değil.

'En iyi platform vardır' rahatlatıcı bir yalandır

İlke: evrensel olarak en iyi platform yoktur. Uyum kategorileri vardır. Çoğu platform rehberi, seçenekleri popülerliğe göre sıralar ve size en üstte olanı seçmenizi söyler. Bu sıralama ortalama okuyucu için optimize edilmiştir ve siz asla ortalama bir müşteriyle çalışmazsınız.

Bunun yerine şunu yapın. Müşteriyle tanışmadan önce üç mağaza katmanı tanımlayın.

Birinci katman: basit mağazalar. Birkaç düzine ürün, yerel teslimat, abonelik yok, küçük ekip. Bu müşteriler düşük maliyet, hızlı kurulum ve kutudan çıktığı gibi çalışan ödeme işlemeye ihtiyaç duyar. Kategori, Square Online ve Ecwid gibi teknik deneyimi olmayan girişimciler için sıklıkla mükemmel başlangıç noktaları olarak tanımlanan, yeni başlayan dostu barındırılan seçenekleri içerir.

İkinci katman: büyüyen satıcılar. Daha büyük kataloglar, gerçek bir pazarlama bütçesi ve tasarım kontrolü ile uygulamalara duyulan istek. Kullanım kolaylığını esneklikle dengeleyen bir platforma ihtiyaçları var. Burası kalabalık orta kısımdır ve müşterilerinizin çoğunun yaşayacağı yerdir.

Üçüncü katman: karmaşık operasyonlar. Büyük kataloglar, abonelikler, B2B fiyatlandırma, uluslararası genişleme veya halihazırda WordPress'e gömülü bir ekip. Bu müşteriler, kurulum daha uzun sürse bile ölçeklenebilirlik ve özelleştirmeye ihtiyaç duyar.

Kuralınız: müşteriyi anlamadan asla bir katman seçmeyin. Birkaç düzine ürünü olan bir mum üreticisinin kurumsal bir katalog sistemine ihtiyacı yoktur. Bir abonelik kutusu şirketinin yerel teslim alım için tasarlanmış bir platforma ihtiyacı yoktur.

Her adayı ücretsiz denemeye alın. Pazarlama videosunu değil, ürün yükleme akışını test edin. Gerçek fotoğraflarla gerçek bir ürün yükleyin. Fiyatı değiştirmeyi deneyin. Bir siparişi iade etmeyi deneyin. Bu denemeye dayanan platform, dikkate değer olan platformdur.

Çalışmış örnek: yerel bir sabun üreticisiyle tanışıyorsunuz. Düzinelerce ürün, abonelik yok, çiftçi pazarlarında sipariş alıyor, çevrimiçi satmak ve müşterilerin siparişleri teslim almasını istiyor. Bu birinci katmandır. Entegre ödemeli basit bir barındırılan platform önerirsiniz. Uygulamaları atlarsınız. Yerel teslim almayı etkinleştirirsiniz. Bir haftada lansman yaparsınız. Onlara bir platform satmadınız; bir uyum sattınız.

'Müşterinin seçmesine izin vermek' size daha sonra pahalıya mal olacak bir kısayoldur

İlke: uzman sizsiniz. Müşteri, bu kararı vermek istemediği için sizi işe alır. Müşterinin seçmesine izin verdiğinizde, onların seçimini motive eden her şeyi devralırsınız — bir arkadaşının tavsiyesi, bir blog yazısı, beğendikleri bir logo. Bunlar iş gereksinimleri değildir.

Bir platform adı vermeden önce keşif yapın. Kısa tutun, ancak zorunlu kılın. Katalog boyutu, ürün türleri, abonelikler, uluslararası gönderim, mevcut sipariş yönetimi, içeriği kimin güncellediği, aylık ücretler için bütçe ve zaman çizelgesi hakkında sorun. Ayrıca nasıl ödeme almayı planladıklarını sorun: tek seferlik satın alımlar, yinelenen ödemeler veya her ikisi.

Cevapları tek sayfalık bir öneriye dönüştürün. Tek sayfa, üç seçenek. İlki sizin seçiminiz. İkincisi yedek. Üçüncüsü bu aşamada kaçınmanızı önerdiğiniz seçenek. Her biri için bir cümle yazın: 'Bu uygun çünkü...' ve 'Bu uygun değil çünkü...'. Sonra müşterinin onayına sunun. Bu, kararın sahipliğini onlara verirken, kararı çukura sürmelerine izin vermez.

Savunabileceğiniz bir platform kararı belirli bir şekle sahiptir. Müşterinin kısıtlarını adlandırır, sizin tercihlerinizi değil. Sadece ürünü değil, katmanı adlandırır. Ve kabul ettiğiniz takası adlandırır — örneğin, daha sonra abonelikleri destekleyemeyecek daha basit bir platform seçmek, böylece müşteri neyi takas ettiğini bilir. Savunulabilir bir öneri oluşturmak için yardıma ihtiyacınız varsa, savunulabilir bir e-ticaret platformu kararı nasıl verilir bölümüne bakın.

'En düşük aylık ücret' en ucuz mağaza değildir

İlke: aylık ücretler faturadaki en az ilginç sayıdır. Toplam maliyet, ödeme işlemeyi, uygulama aboneliklerini, bakımı ve kendi kurulum sürenizi içerir. Aylık ücreti ucuz ama uygulamaları pahalı olan bir platform, taban fiyatı daha yüksek ve uygulama gerektirmeyen bir platformdan daha pahalı olacaktır.

Ödeme işleme gizli değişkendir. Ödeme ağ geçitleri üzerine yapılan araştırmalar tutarlı bir şekilde dört faktöre işaret ediyor: işlem ücretleri, para yatırma hızı, uluslararası destek ve destek kalitesi. Para yatırma hızı çoğu insanın düşündüğünden daha önemlidir. Tedarikçilere haftalık ödeme yapan bir müşteri hızlı ödemelere ihtiyaç duyar; günler içinde mutabakat sağlayan bir ağ geçidi, biraz daha yüksek bir ücretten daha fazla acıya neden olur. Bir müşteri her satışın günlerce belirsizlikte beklediğini gördüğünde sizi arar. Ödemeler hızlı geldiğinde aramaz.

Ücret sayfasını bir sözleşme gibi okuyun. İadelerde ne olacağını sorun. Geri ibrazları sorun. Müşterinin diğer ülkelerden müşteri kabul edip edemeyeceğini ve para birimi dönüşümünün nasıl göründüğünü sorun. Yurt içi satışlar için ucuz olan bir ağ geçidi, uluslararası satışlar için yıkıcı olabilir.

Tekrarlanabilir sürecinizin karşılığını aldığı nokta burasıdır. Her platform katmanı için bir maliyet şablonu oluşturun. Temel planı, tipik uygulama maliyetlerini, ortalama işlem ücretini ve beklenen kurulum süresini yazın. Şablonu her üç ayda bir güncelleyin. Böylece bir sonraki tahmininiz tahmin değil hesaplama olur. Bu tür bir standardizasyon, bir ajans müşteri kabul sistemini tekrarlanabilir kılan şeyin ta kendisidir — aynı disiplini maliyet modelinize de uygulayın.

'Ödeme sonradan akla gelir' mağazayı boğar

İlke: ödeme ağ geçidi teknik bir ayrıntı değil, ticari bir karardır. Müşterinin ne zaman ödeme alacağını, hangi müşterileri kabul edebileceğini ve her satıştan ne kadarını elinde tutacağını belirler.

Kararı platforma ve müşterinin gerçekliğine bağlı tutun. Ağ geçidini işletmeyle eşleştirin:

• Müşteri hem fiziksel hem çevrimiçi satış yapıyorsa, envanteri ve ödemeleri tek bir yerde tutan entegre bir sistem arayın. Araştırmalar, Square'in e-ticaret özelliklerini ödeme işlemeyle birleştiren, yeni başlayan dostu bir seçenek olduğunu vurguluyor.
• Müşteri uluslararası büyümeyi veya abonelik başlatmayı planlıyorsa, güçlü API'ye sahip geliştirici dostu bir işlemci daha uygundur. Stripe, küresel ödemeler ve abonelik desteğiyle yaygın olarak tanınır.
• Müşterinin kartların daha az yaygın olduğu yerlerde alıcıları varsa, güven ve erişim için PayPal gibi yaygın olarak tanınan bir cüzdan ekleyin.

Bu kararı geliştiricinin kişisel tercihine bırakmayın. Bir geliştirici en iyi API'ye sahip işlemciyi tercih edebilir; müşterinin en hızlı para yatırma hızına sahip olana ihtiyacı olabilir. Her iki seçeneği de masaya koyun ve takası açıkça belirtin.

Pahalı hata, ağ geçidini en sonda seçmektir. Ödeme sayfasını tasarlarsınız, her şeyi test edersiniz ve ardından ağ geçidinin müşterinin hedef ülkesini desteklemediğini keşfedersiniz. Yeniden çalışma pahalıdır. Ağ geçidini son dakika entegrasyonu değil, platform keşfinin bir parçası yapın.

'Lansman bitiş çizgisidir' mağazaların ölme şeklidir

İlke: ölçüm planı olmadan lansman yapmak, mağazayı karanlığa atmakla aynıdır. Mağazanın işi lansmandan sonra başlar.

Lansmandan önce temelleri yerine getirin. Platformla çalışan analitiği kurun. Mobil görünümün kullanılabilir olduğundan emin olun. Alıcının sorduğu soruyu yanıtlayan ürün açıklamaları yazın — rehberlik için ürün listeleme ipuçları, anahtarları teslim etmeden önce incelemeye değer.

Lansmandan sonra ilk doksan günü döngüler halinde çalışın. Birinci hafta: ödeme adımı sürtünmesini düzeltin. İnsanların nerede vazgeçtiğini izleyin. Her erken müşteriye onları neyin şaşırttığını sorun. İkinci hafta: trafiğin nereden geldiğini belirleyin. Trafiğiniz yoksa sorun ürün sayfası değil, budur. Üçüncü hafta: hangi ürünlerin satıldığını gözden geçirin. Bunu kataloğa geri besleyin.

Çevrimiçi iş kurma araştırması aynı tavsiyeye geri dönmeye devam ediyor: küçük başlayın, test edin, ölçün ve iyileştirin. İlk ayda devasa yeniden tasarlanmış bir mağaza planlamayın. Haftada bir küçük iyileştirme planlayın. Bu tempo, mağazanın hayatta kalmak için ihtiyaç duyduğu geri bildirim döngüsünü oluşturur.

'Her şeyi standartlaştırmak' tuzaktır

İlke: standardizasyon platformla değil, süreçle ilgilidir. Her müşteriyi tek bir platforma zorlarsanız, iş akışınızı rahat ettirmek için kötü uyumları kabul edersiniz. Ardından platformu müşterinin ihtiyaç duyduğu şeyi yapmak için fazladan zaman harcarsınız ve müşteri sizin katılığınızın bedelini öder.

Gerçeklik bir yelpazedir. Kontrol ettiğiniz katmanları standartlaştırın: keşif anketi, platform öneri şablonu, kurulum kontrol listesi, QA kontrol listesi ve lansman sonrası inceleme takvimi. İki veya üç platform katmanı tutun ve bir müşteri gerçekten bunların dışında bir şeye ihtiyaç duyduğunda belgelenmiş bir istisna yolu oluşturun. İstisna yolu kısa bir paragraftır: bu müşteri neden farklı, ekstra maliyet ne ve kim onaylıyor.

Bu, karşıt görüşlü kısımdır. Birçok ajans ekibi 'verimli ol' uyarısını duyar ve tek bir iş akışı oluşturarak yanıt verir. Kendilerini tek bir platformun her katalog boyutunu, her ödeme modelini ve her ekibin beceri düzeyini yönetebileceğine inandırırlar. Bu inanç, bir müşteri aksini kanıtlayana kadar uygundur. Dar bir süreci tekrarlanabilir bir süreçle karıştırmayın. Dallanan kurallara sahip esnek bir oyun kitabı, ilk istisnada başarısız olan bir komut dosyasından daha tekrarlanabilir.

Tek bir platform her müşteriye uymaz. Bunu kabul eden — ve tek tip bir kural yerine katmanlı bir süreç kuran — ekip, gerçeklikle savaşmayı bıraktığı için tekrarlanabilirlikte kazanır.

Çerçevenizi bu hafta oluşturun

Artık her efsanenin düzeltmesine sahipsiniz. Bunu eyleme dönüştürün.

Keşif anketinizi yazın. Yazdırın. Bir sonraki müşteri görüşmenizde kullanın.

Platform katmanlarınızı tanımlayın. Her katman için bir paragraf yazın, hangi tür müşteriye uyduğunu ve hangi takası kabul ettiğini belirtin.

Tek sayfalık öneri şablonunuzu oluşturun. Bir sonraki platform teklifinde kullanın.

Ödeme ağ geçitleri için bir kural belirleyin. Ağ geçidini API tercihinize değil, müşterinin ödeme gerçekliğine göre eşleştirin.

Lansman sonrası bir takvim seçin. Doksan gün boyunca haftada bir iyileştirme yapmayı taahhüt edin.

Ardından süreci üç yeni müşteride çalıştırın. Her birinden sonra ayarlayın. Çerçeve nihai bir cevap değildir — geliştirdiğiniz şeydir. İyi tahmin eden bir ekip ile her teslimatta daha iyi hale gelen bir ekip arasındaki fark budur.