Yerel bir tirnak salonu için web uygulaması planlayın ve oluşturun: rezervasyon ve takvim, ödemeler ve makbuzlar, müşteri geçmişi—yoğun personel ve tekrar gelen müşteriler için tasarlandı.
Araçları seçmeden veya ekranları tasarlamadan önce salonun çözmek istediği soruyu netleştirin. Çoğu tirnak salonunun ilk günde “her şeye” ihtiyacı yok—günlük sürtüşmeleri ortadan kaldıran bir sisteme ihtiyacı var.
Ekip tarafından sıkça dile getirilen sorunları yazın ve bunları hedeflere dönüştürün. Yaygın olanlar:
Spesifik olun: “Çift rezervasyonları durdur” gibi bir hedef, “Planlamayı geliştir”den daha iyidir.
Bir tirnak salonu web uygulaması tipik olarak dört gruba hizmet eder:
Tasarımı en yoğun ana göre yapın: bir walk-in, iki telefon görüşmesi ve aynı anda ödeme işlemi olan an.
İlk sürüm için öncelik verilecekler:
Sonradan eklenebilecekler: üyelikler, envanter, çoklu lokasyon, gelişmiş pazarlama otomasyonu.
Aşağıdaki gibi ölçülebilir çıktı örnekleri seçin:
Bu metrikler geliştirmeyi odaklı tutar ve bir sonraki adımda neyi iyileştireceğinize karar vermenize yardımcı olur.
Tek bir satır kod yazmadan önce, tirnak salonu web uygulamanızın ilk günde desteklemesi gereken özellikleri ve bekleyebileceklerin listesini çıkarın. Bu, rezervasyon sisteminizi basit tutar, eğitim süresini kısaltır ve özellik şişmesini önleyerek lansmanı geciktirmez.
Müşteriler ve resepsiyon için işe yarayan bir akışla başlayın:
Rezervasyonların çift rezervasyonları engellediğinden ve hizmet süresi ile arasındaki buffer zamanını hesaba kattığından emin olun (ör. müşteriler arasında temizlik için 10 dakika).
Ödemeler karmaşık olmak zorunda değil, ama tutarlı olmalılar:
Bir ödeme sağlayıcısıyla daha sonra entegre olsanız bile, her randevunun “ödenmiş”, “kısmen ödenmiş” veya “ödenmemiş” olarak işaretlenebildiği bir akış tasarlayın.
Hafif bir müşteri geçmişi CRM’si hızlıca şunları göstermeli:
Çekirdeğe hizmet menüsü ve fiyat düzenleyicisi, temel personel planlaması ve iç notlar ekleyin. Envanter notları faydalı olabilir, ama tam stok yönetimi inşa etmiyorsanız bunları hafif tutun.
Bir tirnak salonu uygulamasının hayatı, bilgiyi ne kadar düzenli sakladığına bağlıdır. Veri modelini basit ve tutarlı tutarsanız, rezervasyon, ödemeler ve müşteri geçmişi inşa etmesi ve güvenmesi kolay olur.
Önce temel olanlarla başlayın, sonra gerçek ihtiyaç doğduğunda ekleyin:
Birkaç alan operasyonel değerin çoğunu taşır:
name, price, duration_minutes ve buffer time (ör. temizlik için 10 dakika). Buffer takviminizi gerçekçi tutar.start_time, end_time (veya hizmet süresi + buffer’dan hesaplanır), status (booked/checked-in/completed/no-show/canceled), customer_id, staff_id, location_id.amount, type (deposit/final/tip/refund), method (card/cash), vergiler, indirimler ve randevuya bağlantı.Bir randevunun birden fazla ödemesi olması normal olsun. Örnek: çevrimiçi $20 depozito, sonra mağazada $45, sonra $10 bahşiş—ve gerektiğinde iade. Bu yüzden Payments tablosu appointment_id başına birden fazla satır almalı; randevuda tek bir “payment status” alanına güvenmeyin.
Küçük bir salonda bile neyin değiştiğini bilmek istersiniz.
En azından Appointments üzerinde updated_at ve updated_by saklayın. Daha güçlü bir denetim izi istiyorsanız bir AppointmentChanges kaydı ekleyin: appointment_id, changed_by, changed_at, ve kısa bir change_summary (örn. “Saat 14:00 → 14:30 olarak değiştirildi”). Bu, depozito, no-show ve son dakikadaki düzenlemelerle ilgili anlaşmazlıkları çözmeye yardımcı olur.
Rezervasyon akışınız, “manikür yaptırmak istiyorum” diyen kişiyi takvimde onaylanmış bir yere dönüştüren kalptir. Amaç: arka arkaya mesajlaşma olmadan bir yer onaylamak.
Ekranları tasarlamadan önce takvimin uyması gereken kuralları tanımlayın:
Çakışma önleme iki yerde olmalı:
Basit ve öngörülebilir tutun:
Hizmet seç → zaman seç → teknisyen seç (opsiyonel) → onay.
Müşteri teknisyeni umursamıyorsa varsayılan olarak “Herhangi bir uygun teknisyen” seçin, böylece daha fazla zaman seçeneği gösterilir.
Personel için hız önemlidir. Gün/hafta takvimi sunun, burada şunları yapabilsinler:
İyi bir sonraki adım daha sonra entegrasyonlar eklemektir (bkz. entegrasyonlar: takvim, mesajlaşma, ödemeler), ama önce temel akışı sağlamlaştırın.
Ödemeler, bir salon uygulamasını takvimden gerçek bir iş aracına dönüştürür. Hedef: no-showları azaltmak, ödeme sürecini hızlandırmak ve kayıtları temiz tutmak.
Depozitonun ne zaman gerektiğine karar verin ve müşteriler için öngörülebilir yapın:
Ayrıca bir iptal penceresi ayarı ekleyin (örn. 24 saat). Depozito kaybedildiyse bunu açıkça kaydedin (bir “iade” olarak değil).
Ödemede rezervasyonda ne seçildiyse ön-doldurulmuş olsun, ama hızlı düzenlemelere izin verin:
E-posta/SMS ile makbuz sunun ve resepsiyon için yazdırılabilir görünüm sağlayın. İçermesi gerekenler: randevu tarih/saat, kalem bazında hizmetler, bahşiş, indirim, vergi, uygulanan depozito ve kalan bakiye.
Ödemeleri asla üzerine yazmayın. Orijinal ödemeye bağlı bir düzeltme kaydı oluşturun (iade, kısmi iade, void, ücret düzeltmesi) ile zaman damgası, personel ve gerekçe ekleyin. Bu, toplamları doğru tutar ve anlaşmazlıkları çözmeyi kolaylaştırır.
Müşteri profilleri, uygulamanızın sadece bir rezervasyon aracı olmaktan çıkıp kişisel hissettirmeye başladığı yerdir. İyi bir profil ekip için tutarlı hizmet sunmayı, sık no-showları tespit etmeyi ve misafirlerin hatırlanmasını sağlar—yapışkan notlara veya bir kişinin hafızasına bağlı kalmadan.
Hafif ama kullanışlı tutun:
Opsiyonel alanları gerçekten opsiyonel tutun. En hızlı profil, ilk rezervasyondan sonra otomatik oluşturulan profildir.
Geçmiş görünümü “En son ne yaptık?” ve “Bu müşteri genelde ne kadar harcar?” sorularına cevap vermeli. İçerikler:
Küçük bir “kısaca” başlık (toplam harcama, ziyaret sayısı, son ziyaret) personelin zamanını kurtarır.
Serbest metin notlar dağınık olabilir. Hızlı şablonlar sunun:
Şablonlar giriş hızını artırır ve notların ekip genelinde okunaklı kalmasını sağlar.
Her personelin her şeyi görmesine gerek yok. Rol bazlı kontroller ekleyin:
Fotoğraf saklıyorsanız kimin görüntüleyebileceğini açıkça etiketleyin ve istek üzerine basit bir silme seçeneği sağlayın.
Doğru kişilerin işlerini yapabilmesi için farklı erişim seviyeleri gerekir—herkesin gelirleri, iadeleri veya hassas müşteri notlarını görmesine gerek yok. Net roller ayrıca eğitimi kolaylaştırır çünkü uygulama her kişi için tutarlı davranır.
Pratik başlangıç seti:
İzinleri gerçek görevlerle ilişkilendirin:
Ortak tablet kullanılıyorsa PIN veya dokunarak personel değiştirici ekleyin. Herkesin ayrı hesabı olsun; PIN sadece giriş hızlandırır. Etkinlik olmadığı zaman otomatik kilit, kazara erişimi önler.
Hassas işlemleri kim/neyi/ne zaman/hangi cihazdan yaptığını kaydedin—özellikle iadeler, voidler, fiyat aşımı, kayıt silme ve tamamlanmış fiş düzenlemeleri. Kayıt, sahipler için okunabilir ve müşteri, tarih veya personele göre aranabilir olmalı.
Yönetici panosu, sahipler ve yöneticiler için ana ekrandır: bugünün ne durumda olduğunu, neyin dikkati gerektiğini ve işletmenin yolunda olup olmadığını hızlıca gösterir. Basit tutun—tablet üzerinde hızlı yüklenen, okunaklı ve eyleme odaklı.
“Şimdi ne yapmamız gerekiyor?” sorusuna cevap veren günlük bir görünümle başlayın:
Bu ekranda tek tıkla yapılacaklar: geldi olarak işaretle, yeniden planla, iade/void yap veya hatırlatma gönder.
Aşırı grafiklerden kaçının. Güvenilir, az sayıda rapor verin ve tarih aralığı seçicisini her yerde tutarlı yapın.
Olmazsa olmaz raporlar:
Anlaşılır bir müşteri içgörü paneli ekleyin:
Muhasebe ve gün sonu işlemleri için dosya ve kağıt gerek:
Düzen için ilham gerekiyorsa, pano gezinimini uygulamanın geri kalanıyla tutarlı tutun (örn. yönetici raporları ve yönetici takvimi).
En iyi teknoloji yığını, salonunuzun çalıştırabileceği ve ekibinizin bakımını yapabileceği yığındır. Güvenilirlik, kolay güncelleme ve düşük aylık maliyetleri şık mimarilerden önce tutun.
Rezervasyonların çoğu Instagram/Google linki üzerinden geliyorsa mobil-öncelikli gidin: hızlı sayfalar, büyük düğmeler ve küçük ekranlarda çalışan rezervasyon akışı.
Salon çoğunlukla tezgâhta randevu alıyorsa personel için tablet-öncelikli düşünün: daha büyük takvim görünümleri, hızlı müşteri arama ve daha az dokunuş.
Çoğu salon her ikisini de yapar: müşteriler için mobil uyumlu site + personel için optimize edilmiş yönetici ekranı.
Küçük işletme için basit bir monolit (aynı kod tabanı sayfaları sunar ve veritabanını işler) genelde daha kolay ve daha ucuzdur. Hızlı inşa edilir, dağıtımı ve hata ayıklaması daha basittir.
Eğer ileride mobil uygulama, çoklu lokasyon veya üçüncü taraf ortaklar gerekeceğini biliyorsanız API + ayrı ön yüz yararlı olabilir. Aksi halde erken aşamada fazladan karmaşıklık getirir.
Bir ilişkisel veritabanı (PostgreSQL veya MySQL gibi) kullanın. Randevular, personel programları, depozitolar, bahşişler, iadeler ve makbuzlar bağlantılı veridir. İlişkisel DB kuralları (çakışma engelleme) ve doğru raporlama sağlar.
İki ortam kurun: staging (test değişiklikleri) ve production (canlı). Günlük yedekleri otomatikleştirin ve geri yükleme pratiği yapın.
Hata izleme ekleyin ki müşterilerden önce hatalardan haberdar olun (örn. ödeme veya takvim senkronizasyonu hataları). Basit bir kurulum uptime kontrolleri, loglar ve geri alma yolu içermelidir.
İş akışını hızlıca doğrulamak (rezervasyon kuralları, depozitolar, fişler, personel roller) amaçsa, bir sohbet tabanlı platform olan Koder.ai gibi bir vibe-coding platformu hızlı bir başlangıç sunar.
Koder.ai, ön yüzde React ve arka uçta Go + PostgreSQL kullanan sohbet tabanlı yapılarla web uygulamaları oluşturmanızı sağlar. Kaynak kodu dışa aktarma, barındırma, özel alan adları ve geri alma anlık görüntüleri gibi özellikleri destekler—rezervasyon ve ödeme akışında hızla yineleme yaparken faydalıdır. Daha sonra büyüdüğünüzde ilk sürümün kodunu alıp kendi ekibinizle geliştirmeye devam edebilirsiniz.
Entegrasyonlar, rezervasyonların insanların zaten baktığı yere düşmesi, mesajların otomatik gitmesi ve ödemelerin temizce uzlaştırılması gibi deneyimleri sağlar.
Basit yaklaşım tek yönlü dışa aktarmadır (uygulamanız ➝ personel takvimi) ki randevular teknisyenin Google Takvimi’nde görünsün.
Daha az çift rezervasyon ve daha iyi görünürlük istiyorsanız iki yönlü senkronizasyon ekleyin ki her iki taraftaki değişiklikler eşitlenebilsin.
İki yönlü senkronizasyon için net kurallar gerekir:
Gizlilik nedeniyle birçok salon harici takvimlere sadece “meşgul” bloklar göndermeyi tercih eder ve müşteri detaylarını uygulamanın içinde tutar.
Mesaj entegrasyonları (SMS/e-posta) no-showları azaltır ve resepsiyon iş yükünü düşürür. Asgari set:
Şablonlar kısa ve tutarlı olmalı, SMS için çıkış işlemi bulundurulmalı.
Bir ödeme sağlayıcısı entegre ederken karşılaştırın:
Ayrıca makbuzların nereden geldiğine karar verin: sağlayıcı mı, uygulama mı yoksa tek kaynak—çift makbuz kafa karıştırır.
Planlıyorsanız bu bağlantıların ne desteklendiğini entegrasyonlar sayfasında ve ek maliyetleri fiyatlandırma sayfasında (iç dokümantasyonda) açıkça belirtin.
Güvenlik karmaşık olmak zorunda değil ama kasıtlı olmalı. Bir tirnak salonu uygulaması ad, telefon, randevu detayları ve bazen fotoğraf veya notlar gibi hassas veriler saklayabilir—bu yüzden dikkatle ele alınmalı.
Her yerde HTTPS kullanın ki rezervasyonlar, girişler ve ödeme yönlendirmeleri şifreli olsun.
Hesaplar için parolaları düz metin saklamayın—yalnızca tuzlanmış, hashlenmiş parolalar saklayın (çoğu framework bunu halleder).
Erişimleri en az ayrıcalık ilkesine göre tutun: personel sadece işlerini yapmak için gerekeni görsün. Örneğin resepsiyon randevuları yönetip depozito alabilirken sadece owner/admin gelir raporlarını ve müşteri verilerini dışa aktarabilir.
Kart numaralarını, CVV’leri veya kart-on-file detaylarını veritabanınızda saklamayın. Bunun yerine Stripe, Square veya benzeri bir ödeme sağlayıcısı kullanın ve sağlayıcının döndürdüğü token/ID’leri kullanın.
Uygulamanızda saklananlar:
Bu yaklaşım salon ödeme takibi, makbuzlar ve iadeler için yeterli kayıt sağlar, kart saklama riskini almaz.
Müşteri notları (alerjiler, tercihler) ve tasarım fotoğrafları beklenenden daha hassas olabilir. Kimlerin erişebileceğini sınırlayın, admin’de erişim günlüklerini tutun ve gereksiz kişisel bilgileri saklamaktan kaçının.
Yüklemelere izin verirseniz dosya türlerini ve boyutlarını sınırlayın.
Giriş ve rezervasyon uç noktalarına hız sınırlamaları ekleyin, tekrar eden başarısız girişlerde hesap kilitlenmesi sağlayın ve olağandışı etkinlikler (çoklu kilitlenme, başarısız ödeme artışı, ani rezervasyon denemeleri) için admin uyarıları tetikleyin. Bu küçük kontroller saldırılara karşı korur ve destek yükünü azaltır.
Başarılı bir lansman her şeyi göndermekten çok ekibin güvenle rezervasyon yapabilmesi, ödeme alabilmesi ve hataları kendi başına düzeltebilmesiyle ilgilidir.
Tüm sandalyelere ve personele yaymadan önce bir lokasyon veya tek bir ekip ile pilot yapın. Trafiğin tipik olduğu bir hafta seçin (tatil yoğunluğu olmayan).
Pilot sırasında üç şeyi takip edin: rezervasyon hataları, ödeme sorunları ve müşteri başına harcanan süre.
İhtiyaç duyarsanız hafif bir sorun listesi oluşturun ve öğeleri “bug”, “eğitim” veya “özellik isteği” olarak etiketleyin.
45–60 dakikalık senaryo tabanlı bir oturum yapın (walk-in, geç gelenler, depozitolar, yeniden planlama). Herkesin temel işleri yapabildiğinden emin olun:
Salon zaten bir müşteri listesi veya başka bir sistem kullanıyorsa, veri içe aktarma için plan yapın ve sadece müşterileri ve gelecekteki randevuları taşıyın.
Önce küçük bir parti doğrulayın (örn. 50 müşteri, gelecek haftanın randevuları), sonra kalanları içe aktarın. Eski sistemi 30 gün boyunca salt okunur bırakmak geri dönüş için güvenli bir yoldur.
İlk ay boyunca her hafta geri bildirimleri gözden geçirin ve düzeltmeleri/özellikleri şu önceliğe göre sıralayın:
Kısa sürüm notlarını personel kanalında yayınlayın ve “Ne değişti?” sayfası ekleyin ki eğitim her gün yeniden başlamasın.
Yapım sürecinizi—gereksinimler, ekran görüntüleri, lansman dersleri—paylaşıyorsanız bunu kamuya açmayı düşünebilirsiniz. Koder.ai gibi platformlar içerik oluşturma karşılığında kredi veren programlar yürütür ve sizi başkalarına yönlendirdiğinizde avantaj sağlayabilir. Bu, ilk araç maliyetlerini azaltırken yinelemenize yardımcı olabilir.
Başlıca günlük sorunları (çift rezervasyonlar, kaçırılan depozitolar, kaybolan müşteri notları vb.) listeleyin ve her birini ölçülebilir hedefe dönüştürün.
Pratik bir “v1” kapsamı genellikle şunları içerir:
Gerçek kullanıcılar ve en yoğun anları etrafında tasarlayın:
Rol netliği eğitim süresini kısaltır ve hassas araçlara kazara erişimi engeller (ör. iadeler).
Çift rezervasyonları iki katmanla engelleyin:
İki kişi aynı slotu tıklasa bile sunucu ikinci rezervasyonu reddedip kullanıcıyı başka bir zaman seçmeye yönlendirmelidir.
Buffer zamanı takvimi gerçekçi kılar (temizlik, hazırlık, gecikmeler). Bunu bir rutin alışkanlık olarak değil, programlama kurallarının parçası olarak saklayın.
Yaygın yaklaşımlar:
buffer_minutes ekleyinend_time = start_time + duration + buffer hesaplayınVeri modelini küçük ve tutarlı tutun. Tipik çekirdek set:
Ana modelleme kuralı: bir randevu için birden çok ödemeye izin verin (depozito, son ödeme, bahşiş, iade). Gerçek davranış kısmi ödemeler ve düzeltmeler içerdiğinden tek bir “paid/unpaid” alanına güvenmeyin.
Depozito kurallarını öngörülebilir ve yapılandırılabilir yapın:
Ayrıca iptal penceresini (ör. 24 saat) takip edin ve kaybedilen depozitoları açıkça kaydedin ki raporlama doğru olsun.
Tutarlı bir ödeme akışı kullanın ve düzenlemeleri hızlı tutun:
Makbuzlar e-posta/SMS ile veya resepsiyon için yazdırılabilir görünümde sunulmalı; hizmetler, vergi, indirim, bahşiş, uygulanan depozito ve bakiye ayrı satırlar halinde gösterilmelidir.
Net rollerle başlayın ve yüksek riskli işlemleri kısıtlayın:
Hassas işlemler için kim/neyi/ne zaman/nereden yapıldığını gösteren bir etkinlik kaydı tutun. Bu, depozito ve no-show anlaşmazlıklarını çözmede yardımcı olur.
Çekirdek rezervasyon + ödeme akışları kararlı olduktan sonra entegrasyonları ekleyin.
Yaygın ilk entegrasyonlar:
Makbuzların nereden geldiğini (uygulama mı sağlayıcı mı) baştan netleştirin, çift makbuz kafa karıştırır.
Riskleri düşük tutmak için pilot ve temiz bir göç planı kullanın:
Başarı metrikleri: no-show oranı, ortalama ödeme süresi, yeniden rezervasyon oranı gibi metrikleri izleyin.