Web siteleri

Online mağaza: geliştirmeye başlamadan önce neye karar verilmeli

Katalog, ürün özellikleri, teslimat, ödeme, stok ve entegrasyonlar — arayüz çalışmasından önce verilen kararlar. Sonradan değiştirmek belirgin şekilde daha pahalıdır.

Online mağazada tasarım en zor kısım değildir. Zorluk, ürünlerin tutarlı şekilde tanımlanması, stokların gerçekle eşleşmesi, ödeme ve teslimatın şirketin zaten çalıştığı yöntemle uyumlu hâle getirilmesi gereken yerde başlar. Bu kararlar geliştirmeden önce verilir, çünkü sonradan değiştirilmeleri neredeyse tüm projeyi etkiler.

Katalog: yapı ve ürün özellikleri

Katalog temeldir. Geri kalan her şey — filtreler, arama, dışa aktarımlar, öneriler — onun üzerine kurulur.

Önce kategori yapısını belirlemek gerekir. Burada çoğu zaman düşünülmeden geçilen iki yol ayrımı vardır:

  • Bir ürün aynı anda birden fazla kategoride bulunabilir mi? Evetse bunu baştan planlayın — canlı bir katalogda değişiklik yapmak hoş değildir.
  • Ne ürün, ne ürün varyantı sayılır? Üç renkli ve dört bedenli bir tişört on iki ürün mü, yoksa on iki varyantlı tek bir ürün mü? Ürün sayfası, stok, sepet ve tüm satış analitiği bu yanıta bağlıdır.

Sonra özellikler gelir. Her kategori kendi özellik setine ihtiyaç duyar: ayakkabının bedeni ve malzemesi, elektronik ürünün gücü ve boyutları. Hangi özelliklerin filtrelerde, hangilerinin yalnızca açıklamada kullanılacağına ve hangilerinin doldurulmasının zorunlu olduğuna karar vermek gerekir.

Birimler ve formatlar üzerinde de burada anlaşmak gerekir. Bir üründe ağırlık gram, diğerinde kilogram, üçüncüsünde "yarım kilo civarı" diye yazıyorsa ağırlık filtresi kurulamaz. Kural basittir: filtrelenmesi gereken her şey, açıklamanın parçası değil, katı formatlı ayrı bir alan olmalıdır.

Katalog "sonra tamamlanamaz". Farklı kurallarla girilmiş ürünler elle taşınmak zorunda kalır ve sayıları arttıkça maliyet de artar.

Teslimat ve ödeme

Teslimat seçenekleri sepet ve sipariş sürecinin mantığını belirler. Geliştirmeden önce yanıtlanması gereken sorular:

  1. Hangi teslimat yöntemleri olacak? Mağazadan teslim alma, kurye, kargo firmaları, teslim noktaları — her birinin kendi adres ve süre mantığı vardır.
  2. Ücret nasıl hesaplanıyor? Sabit, bölgeye göre, ağırlık ve boyuta göre, taşıyıcının servisi üzerinden tarifesine göre. Üçüncü taraf servis üzerinden hesaplama, kendi süreleri ve kısıtları olan bir entegrasyondur.
  3. Ücretsiz teslimat var mı, hangi tutardan itibaren? Bu sepeti etkiler: alıcıya ne kadar daha eklemesi gerektiğini göstermek gerekir.
  4. Büyük hacimli ürünler ne olacak? Ürün yelpazesinin bir kısmı normal yolla gönderilemiyorsa kural yöneticinin kafasında değil sistemde olmalıdır.

Ödemede de durum benzerdir. Kartla online ödeme, kapıda ödeme, şirketler için fatura, taksit — set kitleye bağlıdır. İadeler ayrıca kararlaştırılır: kim işleme alır, para alıcıya nasıl döner, sisteme otomatik yansır mı.

Mağaza hem bireysel hem kurumsal müşterilere satıyorsa, bu aslında farklı alanları ve farklı belgeleri olan iki sipariş senaryosudur. Bunu hemen planlamak gerekir — hazır sipariş sürecine ikinci bir senaryo eklemek, baştan tasarlamaktan pahalıdır.

Stok: gerçek nerede yaşıyor

Çalışan bir mağazada sorunların en yaygın kaynağı stok uyuşmazlığıdır. Alıcı sipariş verdi, para çekildi, ürün yok. Ardından iade, özür ve bozulmuş bir izlenim gelir.

Üç şeye karar vermek gerekir.

Ana sistem hangisi. Stok muhasebe yazılımında mı, depo programında mı, CRM'de mi yoksa sitenin kendisinde mi tutuluyor? Gerçeğin kaynağı tek olmalıdır. Bir ürün hem depoda hem sitede düşülebiliyorsa senkron bozulması garantidir.

Veriler ne sıklıkla senkronize ediliyor. Günde bir kez, birkaç dakikada bir veya bir olayla gerçek zamanlı. Ürün devri ne kadar hızlıysa gecikme o kadar kritiktir. Tek ve nadir ürünlerde fark özellikle belirgindir.

Sıfırda ne yapılacak. Ürünü gizlemek, "stokta yok" etiketiyle göstermek, ön sipariş almak. Her seçeneğin sonuçları vardır: gizlenen ürün biriktirdiği arama sıralamalarını kaybeder, etiketli sayfa ise korur.

Ayrı bir soru rezervasyondur. Ürün sepete eklendiğinde mi, sipariş verildiğinde mi, ödemeden sonra mı kilitlenir? Ve ne kadar süreyle? Açık bir kural olmadan iki alıcı son ürünü birlikte satın alır.

Muhasebe sistemleri ve CRM ile entegrasyonlar

Entegrasyon "modül bağlamak" değildir. Hangi verinin hangi yöne aktığı ve her veri türü için hangi sistemin ana sistem olduğu konusunda bir anlaşmadır.

Tipik yönler:

  • Muhasebe sisteminden siteye: ürün listesi, fiyatlar, stoklar, bazen açıklamalar ve görseller.
  • Siteden muhasebe sistemine: siparişler, müşteri verileri, seçilen teslimat ve ödeme.
  • Siteden CRM'e: başvurular, terk edilen sepetler, satın alma geçmişi.
  • Siteye geri: sipariş durumları, takip numaraları.

Önceden kapatılması gereken sorular: iki sistemde ürünler hangi alanla eşleştirilir (stok kodu, barkod, iç kod), veri çakışmasında ne olur, sipariş anında muhasebe sistemi erişilemezse ne yapılır. Sonuncusu özellikle önemlidir: muhasebe sistemi bakımda diye sipariş kaybolmamalıdır — kabul edilir ve aktarım için kuyruğa alınır.

Konuşulması gereken bir şey daha: her şeyi muhasebe sisteminden çekmek gerekmez. Oradaki adlar ve açıklamalar çoğu zaman alıcı için değil depo için yazılmıştır. Bazen pazarlama içeriğini site tarafında tutmak ve muhasebeden yalnızca fiyat ve stok almak daha doğrudur.

Ürün sayfalarını kim, nasıl dolduracak

Projenin en çok hafife alınan kısmı. Mağaza hazır olabilir ama sayfalar boş olduğu için satış olmaz.

Yanıtlanması gerekenler:

  • Metinler ve fotoğraflar nereden gelecek? Kendi içeriğiniz, tedarikçiden, ayrıca satın alınmış. Tedarikçi açıklamaları çoğu zaman onlarca mağazada tekrarlanır ve arama motoru bunu görür.
  • Ürünleri fiilen kim girecek? Kendi çalışanınız, bir yüklenici, fiyat listesinden otomatik içe aktarım.
  • Bir ürün sayfası ne kadar sürüyor? Ürün sayısıyla çarpın — genellikle geliştirme süresinden uzun olan gerçek lansman süresini elde edersiniz.
  • Kalite nasıl korunacak? Bir standart gerekir: hangi alanlar zorunlu, fotoğraf gereksinimleri neler, adlar nasıl yazılır.
  • Yeni ürünler nasıl eklenecek? Elle giriş ölçeklenmez. Ürün yelpazesi sık güncelleniyorsa dosyadan veya tedarikçi sisteminden içe aktarım ilk günden gerekir.

Pratik bir öneri: arayüz çalışmasına başlamadan önce birkaç gerçek ürün sayfası oluşturun. Hangi alanların eksik olduğu, açıklamaların nerede fazla uzun olduğu ve fotoğrafların nerede formata uymadığı hemen görülür.

Sonradan değiştirmek neden daha pahalı

Çünkü bu kararlar üstte değil, temelde durur.

"Ürün — varyant" modelini değiştirmek ürün sayfasını, sepeti, siparişi, dışa aktarımları ve analitiği yeniden yazdırır. İkinci bir depo eklemek stok mantığını ve teslimat hesabını değiştirir. Lansmandan sonra kurumsal müşterilerin ortaya çıkması yeni alanlar, yeni belgeler ve sipariş sürecinde yeni bir dal demektir. Stok için gerçeğin kaynağını değiştirmek tüm entegrasyonun yeniden yapılmasıdır.

Ayrı bir gider kalemi zaten birikmiş verilerdir. On ürün varken yapı yeniden kurulabilir. Binlerce ürün varken ve siparişler gelirken her yeniden yapım, sonuçlarının doğrulanması gereken bir göçe dönüşür.

Başlamadan önce yapılacaklar

Geliştirmeye başlamadan önce yazılı olarak kapatılmaya değer kısa bir liste:

  1. Kategori yapısı ve varyantlı ürünler hakkındaki karar.
  2. Her kategori için özellik seti, filtrelerde kullanılanların işaretlenmesiyle.
  3. Teslimat yöntemleri ve ücret hesaplama kuralları.
  4. Ödeme yöntemleri, kurumsal müşteri senaryosu, iade prosedürü.
  5. Stok için ana sistem, senkronizasyon sıklığı, sıfırdaki davranış, rezervasyon kuralları.
  6. Değişim yönü ve ürün eşleştirme anahtarıyla entegrasyon listesi.
  7. İçerikten sorumlu kişi, içerik kaynağı ve tüm ürün yelpazesi için süre tahmini.
  8. Örnek olarak on gerçek ürün sayfası.

Bu maddeler kapandığında online mağaza geliştirmesi öngörülebilir ilerler. Kapanmadığında süreler koddan değil, zaten verilmesi gereken — yalnızca daha geç ve daha pahalıya — kararlardan dolayı kayar. Herhangi bir maddede yanıt yoksa, bu işe başlamadan önce konuşmak için gayet normal bir nedendir.