PrimeBox seçiminde özel tasarım ve kurumsal iş akışları, işletmenin hangi işi nasıl yaptığı açıklanarak planlanmalıdır. Markaya uygun bir arayüz, bayi fiyatları veya sipariş onayı gibi ihtiyaçlar farklı çalışma alanlarıdır. Ajansbox projenizde her talebin kullanıcıya etkisini, veri kaynağını ve tamamlanma koşulunu belirleyin.
Bu rehberde tasarım kapsamını, bayi yapısını ve kabul denemelerini inceleyebilirsiniz. Konya’da e-ticaret sitesi kuran bir üretici, toptancı veya mobilya işletmesi için kurumsal çözüm kararı, gerçek sipariş örnekleriyle hazırlanmış gereksinim dosyasına dayanmalıdır.
Özel çözüm gerektiren işi açıkça tarif edin
Önce mevcut akışta yaşanan sorunu yazın. Bayiler fiyat sormak için sürekli telefon mu ediyor, siparişler yönetici onayını mı bekliyor, yoksa ürün seçenekleri standart sunuma mı sığmıyor? Her sorunun hangi kullanıcıyı etkilediğini ve bugün nasıl çözüldüğünü açıklayın.
Talebi yalnızca ekran adıyla anlatmak eksik kalabilir. Özel sipariş ekranı yerine, bayinin ürün seçtiği, teklifin satış ekibine ulaştığı ve onaylanan tutarın siparişe dönüştüğü süreci tarif edin. Böylece arayüz, iş kuralı ve bağlantı gereksinimleri ayrı değerlendirilebilir.
Başlangıç dosyasında zorunlu ihtiyaçlarla sonraki aşamada düşünülen geliştirmeleri ayırın. İlk yayında hangi satış modelinin çalışacağı belli olsun. Çok sayıda isteği tek teslim başlığında toplamak, hangi işin tamamlandığını değerlendirmeyi zorlaştırabilir.
Gereksinim dosyasına işin sınırlarını da yazın. Örneğin bayi siparişi alınacak ancak tahsilat ayrı sistemde yapılacaksa bu durum baştan açıklanmalıdır. Ekranda ödeme düğmesi bulunması gerekmeyebilir; buna karşılık siparişin ilgili sisteme aktarılması zorunlu olabilir. Sürecin nerede başlayıp nerede tamamlandığını belirtmek, gereksiz ekranlarla eksik bağlantıların aynı projeye karışmasını önler.
Özel tasarımın sayfa ve durum kapsamını belirleyin
Özel tasarım talebini logo ve renk seçimiyle sınırlandırmayın. Ana sayfa, kategori, ürün, sepet, ödeme ve hesap alanlarından hangilerinin çalışılacağını yazın. Masaüstü görünümle birlikte mobil kullanım ve farklı ekran genişlikleri değerlendirilmelidir.
Bir sayfanın normal görünümü kadar boş, yükleniyor, hata ve stokta bulunmuyor durumlarını da planlayın. Ürün varyantı seçilmediğinde ne görünecek, arama sonuçsuz kaldığında müşteri nasıl ilerleyecek? Bu durumların tasarım kapsamına dahil olması, geliştirme sırasında eksik kararları görünür kılar.
Marka kılavuzu, logo dosyaları, kullanılacak görseller ve örnek ürün verilerini hazırlayın. Başka sitelerden alınan örnekleri hangi davranışı beğendiğinizi açıklamak için kullanabilirsiniz. Referanstaki bütün işlevlerin aynı biçimde projeye dahil edildiğini varsaymadan ihtiyaçları ayrı yazın.
Tasarım görüşmesinde gerçek uzunlukta ürün adları ve açıklamalar kullanın. Çok kısa örnek metinle dengeli görünen kart, uzun model adı veya farklı seçenek sayısında değişebilir. Bir kategori sayfasını az ürün, çok ürün ve sonuç bulunmayan durumlarla inceleyin. Böylece tasarımın yalnızca seçilmiş ekran görüntülerinde iyi görünmesi yerine farklı katalog durumlarında kullanılabilmesi değerlendirilir.
Bayi ve son tüketici deneyimini ayrı tanımlayın
Bayi başvurusu, hesap onayı, fiyat görünürlüğü ve sipariş yetkisi farklı kurallardır. Bayinin hangi bilgilerle başvuracağını, kimin değerlendireceğini ve onaylanana kadar hangi alanları görebileceğini belirleyin. Gereksiz kişisel veya ticari veriler toplamadan gerekli doğrulamayı yapabilecek bir düzen hazırlayın.
Bayi grubuna göre fiyat, indirim, minimum miktar veya ödeme koşulu düşünülüyorsa her kuralı örnekleyin. Son tüketicinin aynı ürünü görmesiyle bayinin özel koşulları görmesi farklı senaryolardır. Fiyatın hangi kaynaktan geldiğini ve ne zaman yenilendiğini de açıklayın.
Bir işletmede birden fazla kullanıcı sipariş verecekse kullanıcıların hangi şirket hesabına bağlanacağını yazın. Yeni kullanıcı ekleme veya yetki kaldırma sorumlusu belli olsun. Başvuru onayıyla sipariş onayını tek durum olarak değerlendirmeyin; her birinin amacı ve sonucu farklıdır.
Bayi fiyatını sınarken farklı müşteri gruplarını temsil eden hesaplar hazırlayın. Bir gruba ait özel koşulun diğer hesaba taşınmaması gerekir. Hesap onayı kaldırıldığında hangi alanların değişeceğini ve geçmiş siparişlerin nasıl korunacağını da konuşun. Bu örnekler, fiyat tablosunun hazırlanmasıyla erişim kuralının uygulanmasının birlikte değerlendirilmesini sağlar.
Onay adımlarını karar koşullarıyla birlikte hazırlayın
Bir onay adımı, kim karar verir ve karar neyi değiştirir sorularını cevaplamalıdır. Tutar sınırı, ürün grubu veya müşteri hesabı gibi koşullara göre onay gerekiyorsa bunları açık örneklerle tanımlayın. Onay bekleyen siparişin stoğu ve teslimat sözü nasıl etkileyeceği belirlenmelidir.
Onaylanan, reddedilen ve değişiklik istenen durumlarda kullanıcıya hangi bilgi verileceğini yazın. Red gerekçesinin kimler tarafından görüleceğini belirleyin. Onaydan sonra fiyat veya ürün seçeneği değişirse yeniden onay gerekip gerekmediği de proje kararları arasında bulunmalıdır.
| Senaryo | Karar sorumlusu | Beklenen sonuç |
|---|---|---|
| Bayi başvurusu | Yetkili satış kullanıcısı | Hesap grubunun doğru atanması |
| Özel fiyat talebi | Tanımlı ticari yetkili | Onaylanan koşulun kayda bağlanması |
| Üretim siparişi | İlgili operasyon sorumlusu | Seçenek ve hazırlık planının kesinleşmesi |
| Değişiklik talebi | Belirlenmiş proje rolü | Etkilenen kaydın yeniden değerlendirilmesi |
Tablodaki roller örnektir; kendi işletmenizdeki sorumlularla tamamlayın. Yetkili kişinin bulunmadığı durumda sürecin nasıl ilerleyeceğini de konuşun. Onay kuyruğunun takip edilebilmesi, yalnızca onay düğmesinin bulunmasından daha kapsamlı bir ihtiyaçtır.
Varsayımsal bir üretim siparişinde müşteri önce kumaş seçer, satış ekibi fiyatı onaylar, ardından üretim sorumlusu hazırlık planını kesinleştirir. Kumaş değiştiğinde eski fiyat onayının geçerli kalıp kalmayacağı belirlenmelidir. Her aşamanın kaydında seçilen ürün, onaylanan koşul ve karar zamanı bulunabilir. Bu örneği işletmenizin gerçek karar sırasına uyarlayın.
Özel ekranların hangi kayıtlarla çalışacağını gösterin
Özel bir ekranın göstereceği alanları, düzenlenebilir bilgileri ve veri kaynağını yazın. Müşteri, ürün, stok, fiyat ve sipariş kimlikleri arasındaki ilişki açık olmalıdır. Aynı bilginin birden fazla ekranda farklı şekilde tutulması sonraki düzeltmeleri zorlaştırabilir.
Yedek parça e-ticaret sitesinde araç uyumu, mobilya mağazasında ölçü ve kumaş seçimi, petshop e-ticaret sitesinde paket yapısı farklı veri ihtiyaçları doğurur. Bu alanları gerçek ürün dosyalarıyla örnekleyin. Standart ürün kartına sığmayan bilgiyi yalnızca serbest açıklamaya bırakmak seçim ve filtreleme ihtiyacını karşılamayabilir.
Geçmiş kayıtların korunmasını da tanımlayın. Ürün adı veya fiyat değiştiğinde önceki teklifin hangi koşullarla verildiği anlaşılmalıdır. İşletmenin kullandığı başka sistemlerle ortak kimlik oluşturulacaksa eşleştirme yöntemi başlangıçta kararlaştırılmalıdır.
Özel entegrasyonu alışveriş senaryosuyla değerlendirin
ERP, muhasebe, depo veya harici hizmet bağlantısı gerekiyorsa sistem adını ve sürümünü hazırlayın. Hangi verinin hangi yönde taşınacağını, neyin işlemi başlatacağını ve başarılı sonucun nasıl anlaşılacağını yazın. Özel API ihtiyacı, yalnızca bağlantı adresinin paylaşılmasıyla tamamlanmaz.
Bağlantı geçici olarak çalışmadığında kullanıcıya ne gösterileceğini belirleyin. Teklifin veya siparişin yeniden gönderilmesi ikinci bir kayıt üretmemesi gereken durumları örnekleyin. Hataları kim inceleyecek, hangi kayıttan başlayacak ve işlem nasıl tekrar denenecek sorularını proje kapsamına ekleyin.
Üçüncü taraf yazılım lisansı ve erişim koşulları ayrıca değerlendirilmelidir. Harici sağlayıcının desteği veya test ortamı gerekiyorsa takvime ekleyin. PrimeBox adının her bağlantı ve özel geliştirmeyi standart bedelle kapsadığı sonucuna varmadan güncel kapsamı yazılı olarak netleştirin.
Harici hizmete bağımlı bir işlemin kullanıcı tarafındaki sonucunu ayrıca düşünün. Örneğin fiyat servisi yanıt vermediğinde eski fiyat gösterilecekse bunun hangi koşulda kabul edileceği belli olmalıdır. İşlem bekletilecekse kullanıcı nasıl devam edeceğini anlamalıdır. Bu kararları geliştirmenin sonuna bırakmadan proje sorumlularıyla birlikte netleştirin; genel bir hata mesajı her iş sürecini açıklamayabilir.
Kullanıcı rollerini görevleriyle eşleştirin
Satış, operasyon, muhasebe ve yönetim rollerinin hangi işlemleri yapacağını ayrı yazın. Bir kullanıcının siparişi görmesi, fiyat değiştirmesi veya geri ödeme işlemi başlatması farklı yetkilerdir. Her göreve yalnızca işini yürütmek için gerekli erişimin verilmesini hedefleyin.
Demo veya kabul sırasında yetkili kullanıcının başarılı işlemini denemekle yetinmeyin. Yetkisi bulunmayan kullanıcının aynı bilgiye erişemediği durumları da değerlendirin. Çalışanın görev değiştirmesi veya işletmeden ayrılması halinde erişimin nasıl güncelleneceği belli olmalıdır.
Tasarımı gerçek alışveriş kararlarına göre inceleyin
Özel tasarımda ürünün seçilebilirliği, fiyatın anlaşılması ve teslimat koşullarının görünürlüğü korunmalıdır. Büyük görseller veya hareketli alanlar müşterinin seçenek seçmesini zorlaştırmamalıdır. Mobilde ürün karşılaştırma, form doldurma ve ödeme adımlarını gerçek içerikle deneyin.
Başlık sırasını, okunabilir renk farklarını ve form alanlarının anlaşılır etiketlerini değerlendirin. Görsellerin alternatif metinleri görünür ürünü açıklamalıdır. Tasarımın başarılı olması yalnızca açılış ekranının beğenilmesine bağlı değildir; müşterinin işlemi tamamlayabilmesiyle birlikte değerlendirilir.
Mevcut e-ticaret sitesi yenileniyorsa ürün ve kategori adreslerini envantere alın. Adres değişiklikleri için uygun yönlendirme planı, içerik kontrolü ve yayın sonrası izleme hazırlanmalıdır. Tasarım değişikliğiyle ürün kimliği, bağlantılar ve geçmiş kayıtlar arasındaki ilişkiyi koruyun.
Tamamlanma koşullarını geliştirmeden önce belirleyin
Her gereksinim için başlangıç durumu, kullanıcının yapacağı işlem ve beklenen sonucu yazın. Örneğin onaylı bayi hesabı belirli ürün grubuna ait fiyatı görürken onaysız hesap aynı koşula erişememelidir. Hangi sonuçta işin tamamlandığının kabul edileceği iki tarafça anlaşılmalıdır.
Kabul grubunda başarılı işlem, eksik bilgi, yetki sınırı ve bağlantı kesintisi gibi farklı örnekler bulunsun. Test verisinin gerçek müşteri verisi içermesi zorunlu değildir. Gerekli özellikleri taşıyan örnek kayıtlar hazırlayıp görülen sorunları ilgili gereksinimle eşleştirin.
Düzeltme sonrasında aynı senaryoyu yeniden deneyin. Bir ekrandaki değişiklik fiyat, stok veya sipariş akışını etkiliyorsa ilgili adımları da kontrol edin. Sadece ekran görüntüsünün tamamlanmış olması iş kuralının doğru çalıştığını göstermeyebilir.
Kabul dosyasında her bulguya ilgili ekranı ve gereksinimi bağlayın. Görsel hizalama sorunu ile yanlış bayi fiyatı aynı etkiye sahip değildir. Öncelik belirlerken satışın veya yetkilendirmenin etkilenip etkilenmediğini değerlendirin. Düzeltmenin tamamlandığına karar veren kişi, başlangıçta yazılan beklenen sonucu kontrol etmelidir. Böylece teslim görüşmesi kişisel beklentiler yerine ortak tanıma dayanır.
Özel tasarımın içerik sorumluluğunu teslim planına ekleyin. Ürün fotoğrafları, kategori metinleri ve işletme bilgileri kim tarafından hazırlanacak? Hazır örnekler gerçek içerikle değiştiğinde düzenin korunacağını kontrol edin. Tasarım onayıyla içerik onayının aynı işlem olmadığını ekip içinde açıklayın.
Birden fazla dil veya farklı müşteri grubu düşünülüyorsa hangi içeriklerin ayrı hazırlanacağını belirtin. Çeviri, görsel uyarlama ve ek ekran durumlarının çalışma kapsamı önceden değerlendirilmelidir. Eksik içerik için sorumlu belirleyin. Yayın öncesinde eksik alanları içerik sorumlusuyla birlikte doğrulayın.
Proje takvimini karar ve teslim adımlarına bölün
Gereksinim onayı, tasarım değerlendirmesi, geliştirme, bağlantı denemesi, kullanıcı kabulü ve yayın hazırlığını ayrı aşamalar olarak planlayın. Her aşamada işletmenin sağlayacağı bilgi belli olsun. Ürün dosyası veya harici sistem erişimi bekleniyorsa bu bağımlılığı takvimde görünür tutun.
Yeni taleplerin kapsam, süre ve bedel etkisi değerlendirilmelidir. İlk listede bulunmayan bir onay adımı başka ekranları da değiştirebilir. Değişiklik kaydında talebin amacı, etkilenen süreçler ve kabul ölçütü bulunsun; yalnızca kısa mesajla tarif edilen işlere dayanmayın.
Yayın sonrasındaki yönetim sorumlularını belirleyin
Ürün ve bayi verisini kim yönetecek, özel ekranlarla ilgili sorunlar nereye bildirilecek ve güncellemeler nasıl değerlendirilecek? Eğitim, bakım, yedekleme ve veri dışa aktarma ihtiyaçlarını görüşün. Özel geliştirme teslimiyle devam hizmetlerinin kapsamını ayrı ve anlaşılır şekilde kayda alın.
Konya’daki üretim veya satış ekibinin kullandığı iç dosyaları da çalışma planına ekleyin. Çalışanların aynı sipariş için farklı fiyat veya seçenek listesi kullanması engellenmelidir. Yayına geçişten sonra gelen sorular, hangi açıklamanın veya iş kuralının iyileştirileceğini gösterebilir.
Yayın sonrası geliştirmeler için sorumlu ve talep kanalı belirleyin. Bir kullanıcının karşılaştığı sorun kayıt kimliği, yaptığı işlem ve gördüğü sonuçla iletilirse inceleme kolaylaşır. Yeni özellik talebi ise hangi işi değiştireceğiyle açıklanmalıdır. Bu iki kayıt türünü ayırmak, mevcut akışın düzeltilmesiyle projeye yeni kapsam eklenmesini daha anlaşılır hale getirir.
PrimeBox kararını somut proje dosyasıyla verin
MiniBox, SmartBox, ProBox ve PrimeBox seçeneklerini değerlendirirken standart gereksinimleri ve özel işleri açıkça listeleyin. Hazır kapsamla karşılanan ihtiyaçlar ve ayrıca geliştirilecek talepler teklif üzerinde anlaşılır olmalıdır. Her iş için sorumluluk, teslim beklentisi ve devam koşulları belirlenmelidir.
Ajansbox görüşmesine bayi senaryolarını ve kabul örneklerini götürün. Konya’da e-ticaret projenizin ilk yayın kapsamını bu dosyayla netleştirebilirsiniz. PrimeBox seçiminin dayanağı, işletmenin gerçek sürecini açıklayan ve denemeyle doğrulanabilen gereksinimler olmalıdır.
Sık sorulan sorular
Özel tasarım bütün sayfaların yeniden yapılmasını kapsar mı?
Sayfalar, mobil durumlar ve gerekli etkileşimler proje kapsamına göre belirlenir. Hangi ekranların çalışılacağı ve revizyon koşulları teklifte açıklanmalıdır.
Bayi satışı yalnızca farklı fiyat göstermekten mi oluşur?
Başvuru, hesap onayı, kullanıcı yetkisi, sipariş koşulları ve veri bağlantıları da gerekebilir. İşletmenin ihtiyacı gerçek bayi işlemleri üzerinden hazırlanmalıdır.
PrimeBox her özel entegrasyonu otomatik kapsar mı?
Özel bağlantıların kapsamı, teknik uygunluğu, lisans gereksinimi ve çalışma bedeli ayrı değerlendirilmelidir. Beklenen işlemler teklif ve kabul planıyla netleştirilmelidir.
