Çok‑Lokasyonlu Salon Web Uygulaması İnşa Etme: Rotasyon ve Analitik

Hedefleri, kullanıcıları ve günlük iş akışlarını netleştirin

Ekran çizmeden veya araç seçmeden önce “daha iyi”nin salonlarınız için ne anlama geldiğini netleştirin. Çok‑lokasyonlu bir uygulama birçok sorunu çözebilir, ama hedefler açık değilse kimsenin güvenmeyeceği özellikler sunarsınız.

İş hedeflerini tanımlayın (ne ölçeceksiniz)

3–5 sonuç seçin ve bunlara sayılar bağlayın. Salonlar için yaygın örnekler:

• Daha az no‑show (ör. hatırlatmalar ve depozitolarla %12'den %7'ye düşürme)
• Daha yüksek sandalye/oda kullanımı (randevular arasındaki boşlukları doldurma)
• Daha hızlı ön masa akışı (kısa check‑in ve checkout süreleri)
• Daha net raporlama (gelir, iptaller ve personel performansı için tek doğru kaynak)

Bu hedefler MVP kabul kriterleriniz olur: uygulama bu metrikleri etkilemiyorsa iş bitmiş sayılmaz.

Kullanıcıları listeleyin ve her birinin ihtiyaçlarını yazın

Çok‑lokasyon operasyonlar genellikle farklı rolleri içerir:

• Owner: yüksek seviyede performans, kâr ve lokasyonlar arası trendler
• Area manager: lokasyonları karşılaştırma, düşük performansı tespit etme, operasyonları standardize etme
• Location manager: personel, programa müdahale, onaylar, günlük mutabakat
• Receptionist/front desk: hızlı rezervasyon değişiklikleri, check‑in, checkout, perakende ekleri
• Stylist/therapist: kişisel takvim, molalar, servis süreleri, komisyon görünümü

Her rol için günlük yaptıklarını ve ne değiştirmemeleri gerektiğini yazın.

Temel iş akışlarını baştan sona haritalayın

Hem “mutlu yol”u hem de karışık gerçekliği belgeleyin:

• Rezervasyon → yeniden planlama → iptal → bekleme listesi yönetimi
• Check‑in → servis notları/eklemeler → checkout → fiş/iade
• Gün sonu kapanışı → ödeme/komisyon ihracı → raporlama

Çok‑lokasyonun neyi değiştirdiğini belirleyin

Çok‑lokasyon sadece “bir lokasyon alanı eklemek” değildir. Erken karar verin:

• Müşteriler paylaşılıyor mu (tek profil, ziyaret geçmişi, tercihler)?
• Personel birden fazla lokasyonda çalışabilir mi, müsaitlik nasıl ele alınır?
• Hizmetler ve fiyatlar standart mı yoksa lokasyona özel mi?

Bu soruları erken cevaplamak, özellikle rezervasyon kuralları ve raporlamada sonra yapılacak acı değişiklikleri önler.

Temel salon verilerini modelleyin (lokasyonlar, personel, müşteriler, hizmetler)

Takvimleri veya panoları tasarlamadan önce salon işletmenizin ortak bir “doğru kaynağı” olmalı: nerede hizmet veriyorsunuz, kim çalışıyor, ne satıyorsunuz ve kimi ağırlıyorsunuz. Güçlü çekirdek veri, çok‑lokasyon rezervasyon, rotasyon ve raporlamayı tutarlı kılar.

Lokasyonlar: her siteyi farklı kılanlar

Her lokasyon pratik operasyonel detayları saklamalıdır:

• Çalışma saatleri ve istisnalar (tatil kapanışları, özel etkinlik saatleri)
• Zaman dilimi (sahipler/yoneticiler veya personel şehirler arasında çalışıyorsa kritik)
• Kaynaklar: odalar, sandalyeler, istasyonlar (ve hangilerinin rezerve edilebildiği)
• Sunulan hizmetler (bazı lokasyonlarda tırnak, kirpik vb. olmayabilir)
• Yerel fiyatlama kuralları (lokasyona özel fiyat, vergi veya ek ücretler)

İpucu: “Kaynakları” (Sandalye 1, Renk Odası) notlar olarak değil açıkça modelleyin. Bu, çift rezervasyonları önlemenin en basit yoludur.

Personel: yetenekler, müsaitlik ve rotasyona hazır özellikler

Bir personel profili sadece ad ve telefon numarasından daha fazlasını içermelidir. Rotasyon planlamayı ve doğru rezervasyonu desteklemek için:

• Beceriler ve seviyeler (ör. balayage sertifikalı, kıdemli stilist)
• Ana lokasyon (öncelikli olarak atandıkları yer)
• Müsaitlik desenleri (günler, zaman aralıkları, kara tarihler)
• Rotasyon kuralları (uygun lokasyonlar, haftalık maksimum seyahat günleri)
• İstihdam türü (çalışan vs yüklenici) — komisyon ve bordro ihracı etkiler

Tasarım seçeneği: becerileri yapılandırılmış etiketler olarak saklayın (seviyelerle) böylece hizmetler “Beceri: Renk Seviye 2+” gibi gereksinim isteyebilir ve rezervasyon motoru uygun personeli filtreleyebilir.

Müşteriler: tek kişi, birçok ziyaret, birden çok lokasyon

Bir kişi için tüm lokasyonlarda çalışan tek bir müşteri kaydı oluşturun. İçermesi gerekenler:

• İletişim bilgileri ve izin/pazarlama tercihleri (SMS/e‑posta onayı, şartların kabulü)
• Lokasyonlar arası ziyaret geçmişi, tercih edilen personel, alerjiler/notlar ve no‑show bayrakları

Bu, birinin yeni bir şubede rezervasyon yaptırırken çoğaltılmış kayıtları önler ve raporlamayı (tekrar oranı, yaşam boyu değer) doğru tutar.

Hizmetler ve eklentiler: rezervasyon için “ürün kataloğu”

Hizmetleri rezerve edilebilir öğeler olarak tanımlayın:

• Süre ve isteğe bağlı tamponlar (temizlik, hazırlık)
• Kaynak ihtiyaçları (oda gerekli, sandalye tipi)
• Gerekli beceri seviyesi (sistemin uygun personeli filtrelemesi için)
• Eklentiler (toner, derin bakım) — süre ve fiyatı uzatır

Hizmetleri serbest metin yerine katalog olarak ele alırsanız, daha temiz rezervasyonlar, ön masada daha az hata ve güvenilir analizler elde edersiniz.

Rezervasyon ve takvim sistemini tasarlayın

Rezervasyon motoru, lokasyonlar, personel, odalar ve hizmet kuralları genelinde kullanılabilirliğin “doğru kaynağı”dır. Takvim UI’sını o motorun üzerine bir görünüş olarak düşünün; motorun kendisi olarak değil.

Her kanal için tek bir kullanılabilirlik motoru

Çevrimiçi rezervasyon ve ön masa rezervasyonu aynı API ve kuralları kullanmalı. Aksi halde iki takvim uyumsuz olur.

En azından kullanılabilirlik şu faktörleri göz önünde bulundurmalı:

• Lokasyon çalışma saatleri ve özel kapamalar
• Personel çalışma saatleri (rotasyon başka yerde planlanır ama burada uygulanır)
• Hizmet süresi ve yapılandırılabilir tamponlar
• Atanmış oda/sandalye/kaynak (hizmet gerekli ise)

Çift rezervasyonu önleyen kurallar

Çatışma kurallarını net tanımlayın ve tutarlı uygulayın:

• Bir personel aynı anda çakışan zamanlara rezervasyonlanamaz
• Bir oda/kaynak çakışan zamanlara rezervasyonlanamaz
• Bir müşteri çakışan randevulara sahip olamaz (isteğe bağlı ama faydalı)

Gerçek zamanlı doğruluk için optimistic concurrency (sürüm numaraları) veya kısa süreli tutmalar (ör. checkout sırasında 5–10 dakikalık “beklemede” slot) kullanın. Bu, iki kişinin aynı zamanı hedeflediği yarış durumlarını azaltır.

Tamponlar, molalar, kısıtlar ve paketler

Tamponlar (hazırlık/temizlik), molalar ve öğle araları not değil birinci sınıf program blokları olmalıdır. Hizmet paketleri (ör. kesim + boya) tek bir rezervasyon olarak ele alınmalı, birden fazla zaman segmentine genişleyebilir ve farklı kaynaklar gerektirebilir.

İptal/yeniden planlama politikaları yapılandırılabilir olsun

Politikaları sert kodlamaktan kaçının. Bunları lokasyon başına (ve bazen servis bazında) ayarlar olarak saklayın, örneğin:

• İptal/yeniden planlama için son kesme pencereleri
• Depozito gereksinimleri veya no‑show ücretleri
• Bir rezervasyon taşındığında depozitoların nasıl işlendiği

Politikalar veri‑odaklı olduğunda, kod değişikliği gerektirmeden hızlıca ayar yapabilir ve web, mobil ve ön masa arasında tutarlı davranış sağlayabilirsiniz.

Personel rotasyonu ve vardiya planlamasını planlayın

Rotasyon, çok‑lokasyon operasyonlarını ya adil ve öngörülebilir ya da dağınık ve politik hale getirir. Programlamayı açık kurallar ve istisnaları güvenli şekilde ele alan bir yaklaşım olarak ele alın.

Gerçeğinize uyan rotasyon desenlerini seçin

Çoğu salon birden fazla rotasyon “şablonunu” desteklemekten fayda görür; çünkü bir lokasyon düzenliyken başka bir lokasyon talebe göre çalışabilir.

• Haftalık / iki haftalık rotasyonlar stabil ekipler ve düzenli müşteri kitlesi için uygundur.
• Mevsimsel rotasyonlar yaz, tatil veya okul programı değişiklikleri için yardımcı olur.
• Talebe dayalı rotasyonlar rezervasyonlara, walk‑in'lere veya yerel etkinliklere göre esneklik gerektiğinde kullanışlıdır.

Pratik bir yaklaşım, desenleri yeniden kullanılabilir programlar olarak saklamak (ör. “Downtown Hafta A”) ve her hafta elle oluşturmak yerine tarih aralığı için vardiyalar üretmektir.

Adaleti iş ihtiyaçlarıyla dengeleyin

Adalet “herkese aynı vardiya” değildir; “kurallar görünür ve tutarlı” olmaktır. Nasıl dağıtım yapacağınızı kararlaştırın:

• Prime slotlar (iş çıkışı sonrası saatler, cumartesi)
• Hafta sonları ve geç vardiyalar
• Walk‑in kapsamı (ön masa‑dostu, hızlı hizmetler)

Bunları planlama mantığınıza yumuşak hedefler (tercihler) ve sert kurallar (kısıtlar) olarak ekleyin. Örnek: “Her stilist haftada en az bir prime slot almalı” (hedef) vs “Kıdemli colorist Cumartesileri lojistik olarak bulunmalı” (kural).

Kısıtları baştan yakalayın

Zamanlayıcınız ancak anladığı kısıtlar kadar akıllıdır. Yaygın kısıtlar:

• Beceriler ve hizmetler: kim uzantı, balayage veya ileri cilt bakımı yapabilir
• İş kanunları: maksimum saatler, gerekli molalar, küçük çalışan kısıtları
• İzinler ve tekrar eden müsait olmama durumları
• Lokasyonlar arası seyahat süresi (şehirler arası ardışık vardiyalar olmasın)

Bunları serbest not olarak değil, yapılandırılmış veri olarak modelleyin ki sistem çatışmayı yayınlamadan önce uyarı verebilsin.

Geçersiz kılmaları güvenli ve izlenebilir yapın

En iyi planlar bile istisna gerektirir. Araçlar sağlayın:

• Manuel değiş tokuşlar personel arasında
• Onaylar yönetici incelemesi için (özellikle lokasyonlar arası)
• Bir denetim izi kim neyi, ne zaman değiştirdiğini gösteren kayıt

Bu, programı esnek tutar ama hesap verebilirliği kaybetmez — anlaşmazlıklar, bordro soruları veya uyumluluk kontrolleri için kritik.

İzinler, onaylar ve denetim kayıtları kurun

Birden çok lokasyon çalıştırdığınızda “kim ne yapabilir” rezervasyon gibi önemli hale gelir. İzinler müşteri gizliliğini korur, maliyetli hataları azaltır ve rakamlarınıza güveni artırır — özellikle yöneticiler, ön masa personeli ve stilistler aynı sistemi kullandığında.

Lokasyon ve veri türüne göre erişimi tanımlayın

Önce her rolün neleri görüntüleyip düzenleyebileceğini kararlaştırın:

• Müşteri verisi: iletişim detayları, notlar, ziyaret geçmişi, alerjiler
• Gelir ve raporlar: günlük toplamlar, lokasyon karşılaştırmaları, hizmet performansı
• Bordroya ilişkin bilgiler: komisyonlar, bahşişler, düzeltmeler, personel bildirimleri

Sonra lokasyonlar arası kurallar ekleyin. Örneğin, bir resepsiyonist yalnızca kendi lokasyonu için rezervasyon yapabilirken bir area manager tüm lokasyonların takvimlerini görüntüleyebilir fakat bordroyu düzenleyemez.

Özellik başına rol tabanlı izinler oluşturun

Tek bir “admin” izni yerine, özellik bazında bölünmüş izinler oluşturun:

• Rezervasyon: randevu oluştur/düzenle/iptal etme, depozito geçersiz kılma, bekleme listesi yönetimi
• Raporlar: sadece görüntüleme vs dışa aktarma
• Ayarlar: hizmetler/fiyatlandırma, personel profilleri, çalışma saatleri

Bu, günlük işi akıcı tutar ve hassas işlemleri doğru kişilere sınırlar.

Yüksek etkili işlemler için onay akışları ekleyin

Onaylar sessiz marj kaybını ve program kaosunu önlemenin basit yoludur. Yaygın onay tetikleyicileri:

• Eşik üstü indirimler (ör. %15'ten fazla)
• İadeler ve void'ler
• Program geçersiz kılmaları: çalışma saatleri dışında rezervasyon, çift rezervasyon, tamponları atlama
• Personel değiş tokuşları ve son dakika rotasyon değişiklikleri

Onayları hızlı yapın: nedeni, etkiyi (tutar, etkilenen randevu) ve kimin onaylaması gerektiğini gösterin.

Kullanılabilir bir denetim izi tutun

Bir denetim günlüğü şu soruları yanıtlamalı: ne değişti, kim değiştirdi, ne zaman ve nereden. Randevu düzenlemeleri, ödeme/komisyon düzeltmeleri, iadeler ve envanter değişiklikleri gibi işlemleri takip edin. Lokasyon, çalışan ve tarihle filtrelenebilir arama ekleyin ki sahipler mesajlarda gezinmeden anlaşmazlıkları çözebilsin.

Ödeme, kasa ve finansal kayıtları oluşturun

Checkout, rezervasyonun gelire dönüştüğü yerdir; bu nedenle ön masa için hızlı ve raporlama için kesin olmalıdır.

Checkout akışını tasarlayın

Bir randevudan çekilmiş “sunulan hizmetler” özeti ile başlayın: hizmetler, süre, personel ve lokasyon. Sonra resepsiyonistin aynı ekranda son dakika öğeleri eklemesine izin verin: eklentiler, perakende ürünler, indirimler (promosyon kodu veya manuel), bahşişler ve vergiler.

Hesaplamayı öngörülebilir kılmak için işlem sırasını erken belirleyin (örnek: indirimler hizmetlere uygulanır, vergi indirimden sonra uygulanır, bahşişler vergi sonrası). Ne seçerseniz seçin, lokasyonlar arasında tutarlı olsun ki raporlar karşılaştırılabilir kalsın.

Bölünmüş ve kısmi ödemeler (kuralları erken tanımlayın)

Neye izin vereceğinize karar verin:

• Ödemeyi birden fazla yönteme bölme (nakit + kart, iki kart)
• Ödemeyi ödeyenlere göre bölme (müşteri + hediye kartı)
• Önceden alınan depozitoların checkout'ta uygulanması

Ayrıca kısmi ödeme davranışını tanımlayın: bir fatura açık bırakılabilir mi yoksa her randevu aynı gün tamamen kapatılmalı mı? Bakiye bırakmaya izin verirseniz, komisyon ve gelir raporlaması için hizmetin ne zaman “ödenmiş” sayılacağını belirtin.

İadeler, void'ler ve izin kontrolleri

İade ve void işlemleri neden (açılır menü + isteğe bağlı not) ile istenmeli, işlemi yapan ve denetim izi kaydedilmelidir. Net bir ayrım yapın:

• Void: hatalı işlem (idealde aynı gün, mutabakattan önce)
• Refund (İade): tahsilattan sonra para iadesi

Hassas eylemleri rollere göre kısıtlayın (izinler ve denetim günlükleri bölümüne bakın).

Entegrasyonlar ve dışa aktarmalar

Ödeme sağlayıcılarını ve fiş teslimat yöntemlerini (e‑posta/SMS) erken seçin çünkü veri modelinizi etkilerler. Muhasebeyi ilk günden entegre etmeyecek olsanız bile, temiz finansal kayıtlar saklayın: fatura, satır öğeleri, ödeme denemeleri, başarılı ödemeler, bahşişler, vergiler ve iadeler. Bu yapı ileride dışa aktarımları ve güvenilir bir gelir panosu oluşturmayı kolaylaştırır.

Gelir analitiği ve performans panoları oluşturun

Analitiğiniz iki soruyu hızlıca cevaplamalı: “Ne kadar kazandık?” ve “Neden değişti?” Küçük, tutarlı bir gelir metrik setiyle başlayın ki her lokasyon aynı şekilde raporlasın.

Gelir sayılarını tanımlayın (ve tutarlı yapın)

Asgari olarak standartlaştırın:

• Brüt satışlar (hizmet + perakende, indirim öncesi)
• İndirimler (promolar, personel komps, paketler)
• İadeler/void'ler (ve nedenleri)
• Net satış (brüt − indirim − iadeler)
• Bahşişler (satıştan ayrı)
• Vergi (tahsil edilen)

Bölünmüş ödemeler, kısmi iadeler, hediye kartları ve depozitolar gibi kenar durumları nasıl işleyeceğinizi belgeleyin ki panolar tartışma konusu olmasın.

Salon sahiplerinin düşündüğü şekilde performansı dilimleyin

Şu kriterlere göre karşılaştırmayı kolaylaştırın:

• Lokasyon (veya “tüm lokasyonlar” toplamlama)
• Personel üyesi (ve rol: stilist, terapist, resepsiyonist)
• Hizmet kategorisi (saç, tırnak, cilt bakımı) ve bireysel hizmetler
• Zaman periyodu (gün/hafta/ay, ayrıca yıl‑yıla karşılaştırma)

Pratik bir düzen: en üstte özet kutucuklar (net satış, randevular, ortalama bilet), altında lokasyon veya personel seçildiğinde detaylandıran tablolar.

Geliri öngören operasyonel KPI'lar ekleyin

Gelir sonuçtur; operasyonlar kaldıraçtır. Şunları ekleyin:

• Kullanım (rezerve edilen zaman ÷ kullanılabilir zaman)
• Yeniden rezervasyon oranı (X gün içinde tekrar randevu alan müşteriler)
• No‑show / geç iptal oranı
• Bekleme süresi (talep ile randevu arasındaki süre)

Bu KPI'lar fazla analiz gerektirmeden “neden”i açıklamaya yardımcı olur.

Filtreleme ve dışa aktarmayı zahmetsiz yapın

Filtreleri basit ve her zaman görünür tutun: tarih aralığı, lokasyon, personel, hizmet. Gelişmiş ayarların arkasına saklamayın.

Her rapor CSV'ye dışa aktarılabilmeli ve ekranda görülen sütunlarla aynı sütunları içermeli (ek olarak ID'ler ve zaman damgaları). Bu, muhasebecilere, bordroya veya BI aracına paylaşımı kolaylaştırır.

Komisyon, bordro girdileri ve personel dökümleriyle ilgilenin

Komisyonlar güvenin kazanılıp kaybedildiği yerdir. Personel numaraların adil olduğunu bilmek ister, yöneticiler hızlı onay ister ve sahipler bordroya hazır toplamlar ister.

Komisyon modelini seçin (ve açık yapın)

En yaygın kuralları destekleyin ve hizmet ayarında görünür kılın:

• Hizmet gelirinin yüzdesi (ör. kesimin %35'i)
• Aşamalı oranlar (ör. aylık 3.000$'a kadar %30, sonrası %35)
• Perakende vs hizmete ayrı kurallar (ör. perakende %10, hizmetler %40)

Çok‑lokasyon ekipler için komisyon planları lokasyon, rol veya birey bazında atanabilmeli. Bir stilist başka bir şubeyi kapattığında kendi ana planından mı yoksa şube planından mı ödeneceği gibi politika desteklenmelidir.

Bordro dönemleri ve lokasyona özgü kurallar

Bordro girdilerini basit ama esnek tutun:

• Dönem türleri: haftalık, iki haftalık, ayda iki, aylık
• Kilitleme: yönetici onayından sonra bir dönemi otomatik olarak “kapatma”
• İsteğe bağlı lokasyon geçersiz kılmaları: farklı ödeme takvimleri, farklı komisyon planları, bahşiş yönetimi farklılıkları

Bu aşama ayrıca komisyonun brüt (indirim öncesi) mi yoksa net (indirim sonrası) mı hesaplandığını ve iadelerin nasıl ele alınacağını tanımlamak için uygundur.

Düzeltmeler açık sorumlulukla

Gerçek hayat kenar durumları yaratır: yeniden yapılan işler, chargeback'ler, iyi niyet indirimleri ve manuel bonuslar. Bir Düzeltme girişi türü ekleyin; bu şuları gerektirsin:

• Tutar (+/-)
• Sebep (bonus, düzeltme, iade, chargeback)
• Notlar
• Oluşturan ve onaylayan kişi

Bu denetim izi anlaşmazlıkları azaltır ve toplamların açıklanmasını kolaylaştırır.

Personel bildirimleri okunması kolay olsun

Personelin çalışmayı nasıl düşündüğüne karşılık gelen bir bildirim oluşturun:

• Yapılan toplam hizmet sayısı, hizmet satışları, perakende satışları
• Kazanılan komisyon (türlere göre ayrılmış)
• Bahşişler (izleniyorsa)
• Düzeltmeler ve notlar
• Dönem için net ödeme toplamı

Yöneticiler lokasyon başına özet görünümü almalı ve bordro araçlarına besleyecek dışa aktarımlar yapabilmelidir. POS entegrasyonu planlıyorsanız, bildirim kategorilerini kasa kurulumunuzla hizalayın ki mutabakat kolay olsun.