Kullanıcıların farklı hizmetler arasında takvimler, ödemeler, hatırlatmalar ve yönetici araçlarıyla randevu ayırtmasını sağlayan bir mobil uygulamanın nasıl planlanıp tasarlanıp inşa edileceğini öğrenin.

Bir zamanlama uygulaması, hangi problemi çözdüğünü net gösterdiğinde “basittir”. Bir işletmenin takvimini mi dolduruyorsunuz, yoksa müşterileri farklı hizmet sunucularıyla mı eşleştiriyorsunuz? Bu iki seçim veri modelinizi, kullanıcı akışlarını, fiyatlandırmayı ve hatta “kullanılabilirlik”in ne anlama geldiğini belirler.
Randevu rezervasyonu yüzeyde benzer görünse de kurallar sektöre göre değişir:
Bir tek işletme uygulaması (tek marka, tek personel/konum seti) genellikle daha hızlı geliştirilir ve kontrol etmesi daha kolaydır.
Bir çoklu sağlayıcı pazaryeri ise sağlayıcı işe alımı, listelemeler, arama ve daha karmaşık politikalar ekler—çünkü her sağlayıcının farklı saatleri, hizmetleri ve fiyatları olabilir.
“Çoklu hizmet” birden fazla kategori (saç kesimi vs masaj), konum (şubeler veya evde hizmet) ve süre (30/60/90 dakika) içerebilir. Ayrıca bir kişi, bir oda veya bir ekipman gibi farklı kaynak kısıtlamalarını da kapsayabilir.
Etkisini nasıl ölçeceğinize karar verin:
Bu metrikler, özellikler genişledikçe ürün kararlarını zemine oturtur.
Ekranları tasarlamadan veya özellikleri seçmeden önce uygulamayı kullanacak kişileri ve beklenen “mutlu yol”u haritalayın. Çoğu zamanlama uygulamasında üç rol olur—müşteri, sağlayıcı ve yönetici—ama ayrıntılar saç kesimi, tamir, özel ders veya bir sepette birden çok hizmet olup olmamasına göre çok değişir.
Müşterinin zihinsel modeli basittir: “Bir hizmet bul, bir zaman seç, ve onaylandığını bil.” Net bir ana akış şöyle görünür:
Karar noktalarını açık tutun: hizmet → personel (opsiyonel) → zaman → onay.
Çoklu hizmet rezervasyonunu destekliyorsanız (ör. kesim + boyama), müşterilerin önce bir paket mi oluşturacağını yoksa sağlayıcı seçildikten sonra hizmet ekleyip eklemeyeceklerini belirleyin.
Sağlayıcılar kontrol ve öngörülebilirlik ister. Temel eylemleri genellikle şunlardır:
Bir sağlayıcı randevuya gelemiyorsa ne olacağını tanımlayın: yeni bir zaman önerebilir mi, başka bir personele atayabilir mi yoksa iptal etmek zorunda mı?
Yöneticiler pazaryerinin tutarlılığını korur:
Misafir rezervasyonu, özellikle ilk kez gelen kullanıcılar için dönüşümü artırabilir. Dezavantajı ise daha zayıf kimlik doğrulama: iade süreçleri zorlaşır, cihazlar arası hatırlatmalar zayıf olur ve dolandırıcılık riski artar.
Yaygın bir uzlaşma “rezervasyon sonrası hesap oluşturma” modelidir: onay ekranında kullanıcılar yeniden planlama, fişler ve gelecekte hızlı rezervasyon için bilgilerini kaydetmeye teşvik edilir.
Ekranları inşa etmeden veya kod yazmadan önce tam olarak nelerin rezerve edilebileceğine ve hangi koşullarda rezerve edilebileceğine karar verin. Net kurallar çift rezervasyonları önler, destek taleplerini azaltır ve fiyatlandırma ile personel yönetimini kolaylaştırır.
Dağınık bir liste yerine yapılandırılmış bir katalogla başlayın. Her hizmetin uygulamanın süre ve fiyat hesaplayabilmesi için öngörülebilir bir “şekli” olmalıdır.
Pratik ipucu: süre için tek bir “gerçek kaynağı” seçin. Hem sağlayıcıların hem hizmetlerin süreyi serbestçe tanımlamasına izin verirseniz, müşteriler tutarsız slot uzunlukları görür.
Sağlayıcı profilleri sadece fotoğraf ve biyografiden daha fazlasına ihtiyaç duyar. Kullanılabilirlik ve eşleştirmeyi etkileyen ayrıntıları yakalayın:
Çok konumlu rezervasyon planlıyorsanız, sağlayıcının saatlerinin global mi yoksa konum başına mı olduğunu belirleyin.
Gerçek dünyadaki zamanlama çoğunlukla kenar durumlarla ilgilidir:
Bu kurallar otomatik olarak rezerve edilebilir slotları ayarlamalıdır—müşterilerin neyin mümkün olduğunu tahmin etmesine gerek olmamalı.
Politikaları serbest metin notlar yerine seçilebilir ayarlar olarak tanımlayın:
Sade dili rezervasyon akışında gösterin ve hangi politika sürümünün her randevuya uygulandığını kaydedin—ilerideki anlaşmazlıklar için.
Veri modeliniz, daha fazla hizmet, personel ve konum ekledikçe zamanlamayı basit tutup tutamayacağınızı belirler. İyi bir model "Taylor 15:30'te müsait mi?" veya "Bu rezervasyonda ne değişti ve kim değiştirdi?" sorularını kolayca yanıtlamalıdır.
Bir Randevu sadece “başlangıç zamanı + bitiş zamanı” olmamalı. Onu durumların zaman çizgisi ve net meta verilerle ele alın:
Ayrıca temel alanları saklayın: customer_id, service_id, location_id, atanmış kaynaklar, fiyat/depozito alanları (ödeme başka yerde işleniyor olsa bile) ve serbest metin notlar.
Çoğu zamanlama hatası "ne rezerve edildi" ile "bunu kim/neyapacak" karıştığında oluşur. Aşağıdaki türleri temsil edebilen bir Kaynak modeli kullanın:
Randevular bir veya daha fazla gerekli kaynağa referans vermeli. Böylece bir masaj therapist + bir oda gerektirirken, grup dersi sadece "kapasite" tüketir.
Eğer sağlayıcılar birden çok konumda çalışıyorsa konum takvimleri ekleyin ve kaynakları izin verilen konumlarla ilişkilendirin.
Mobil/evde hizmetler için isteğe bağlı seyahat tamponları ekleyin: mesafeye göre veya sabit kurala dayalı önce/sonra dakikalar. Seyahat süresini sağlayıcı kaynağı üzerinde engellenmiş zaman olarak modelleyin ki arka arkaya rezervasyonları engellesin.
Zamanlama sıkça “Bunu kim değiştirdi?” anlarıyla doludur. Bir append-only denetim izi tablosu ekleyin: kim (kullanıcı/ yönetici/sistem), ne değişti (alan farkları), ne zaman ve neden (sebep kodu). Bu destek süreçlerini hızlandırır, anlaşmazlıkları önler ve köşe durumlarını debug etmeyi kolaylaştırır.
Zamanlama motorunuz, neyin rezerve edilebilir olduğunun tek gerçek kaynağı olmalı. Güvenilir şekilde cevap vermesi gereken basit soru şudur: bu zaman gerçekten müsait mi? Altında ise hız (hızlı slot listeleri) ile doğruluk (çift rezervasyon yok) arasında denge kurarsınız.
Çoğu uygulama bir seçenek ızgarası gösterir (“9:00, 9:30, 10:00…”). Bu listeyi iki ana yoldan oluşturabilirsiniz:
Ön üretim, UI'yi anlık hissettirir ama arka plan işler ve dikkatli güncellemeler gerektirir. Gerçek zamanlı ise bakımını kolaylaştırır ama ölçeklendikçe yavaşlayabilir.
Birçok ekip hibrit kullanır: ilk birkaç günü önbelleğe alıp daha uzun aralıkları talep üzerine hesaplamak.
Çift rezervasyon genellikle iki kişinin birkaç saniye içinde “Rezervasyon Yap”a basmasıyla olur. Bunu iki adımlı bir yaklaşımla önleyin:
Yaygın desenler arasında benzersiz bir “slot id” modelleyebiliyorsanız veritabanı işlemleri ile unique constraint'ler (en iyi); sağlayıcının programında row-level kilitler veya kullanıcı ödeme/onaylamazsa süresi dolan kısa ömürlü bir “tutma” bulunur.
Zaman damgalarını UTC olarak saklayın, ancak randevulara her zaman bir saat dilimi (çoğunlukla sağlayıcının konumu) iliştirin. Görüntüleme için görüntüleyene göre (müşteri vs sağlayıcı) dönüşüm yapın ve “10:00 AM (London time)” gibi net etiketler gösterin.
Yaz saati (DST) değişiklikleri kaybolan veya tekrar eden saatler gibi karmaşık günler yaratır. Motorunuz şunları yapmalıdır:
Eğer izin verecekseniz, açık kurallar tanımlayın:
Önemli olan tutarlılıktır: UI dostça olabilir ama motor sıkı olmalıdır.
Bir zamanlama uygulamasının altında güçlü bir motor olsa da kullanıcılar onu ne kadar çabuk bir hizmet bulup zaman seçip hata yapmayacaklarından emin olduklarına göre yargılar. UX kararları azaltmalı, geçersiz seçimleri önlemeli ve maliyeti ödeme öncesi açıkça göstermelidir.
Hem “ne” hem de “ne zaman” destekleyen arama ile başlayın. Kullanıcılar çoğunlukla kombinasyonlarla düşünür: “yarın saç kesimi”, “yanımdaki dişçi” veya “100$ altı masaj”.
Filtreleri kolay taranır ve sıfırlanabilir yapın: hizmet tipi, tarih/zaman aralığı, fiyat aralığı, puan ve mesafe. Sonuç sayfasını sabit tutun—her dokunuşta yeniden sıralama yapmayın ki insanlar yerlerini kaybetmesin.
İki adımlı bir seçici kullanın: önce tarihi seçin, sonra o tarih için yalnızca geçerli slotları gösterin. Mevcut olmayan zamanları tamamen gizlemek yerine devre dışı bırakın (insanlar hangi zamanların bloke olduğunu gördükçe daha hızlı öğrenir).
Eğer çoklu hizmet rezervasyonu destekliyorsanız, kullanıcı taahhüt etmeden önce toplam süreyi ve bitiş saatini gösterin (“90 dk, 15:30'da biter”).
Erken aşamada basit bir döküm gösterin: temel fiyat, eklentiler, vergiler, ücretler ve depozito. Fiyat personel ya da zamana göre değişebiliyorsa açıkça belirtin (“Akşam ücreti”). Son ekranda toplamı ve şimdi mi sonra mı ödenecek tekrar gösterin.
Yüksek kontrastlı metin, ölçeklenebilir yazı tipleri ve büyük dokunma hedefleri kullanın (özellikle zaman slotları için). Her kontrol—filtreler, takvim günleri, slot düğmeleri—durumu açıklayan ekran okuyucu etiketlerine sahip olmalı (“14:00, kullanılamıyor”). Erişilebilir UX aynı zamanda herkes için rezervasyon hatalarını azaltır.
Bildirimler bir zamanlama uygulamasını ya zahmetsiz hissettirir ya da kullanıcıyı rahatsız eder. Amaç basittir: mümkün olan en az mesajla, herkesin tercih ettiği kanalda bilgi vermek.
Push, SMS ve e-postayı destekleyin ama hepsini zorlamayın.
Müşteriler genellikle hatırlatmalar için push, son dakika değişiklikleri için SMS tercih eder. Sağlayıcılar genellikle e-posta özetleri artı gerçek zamanlı güncellemeler için push ister.
Ayarlar içinde sunun:
Her rezervasyon, her iki tarafa da aynı temel detaylarla anında bir onay tetiklemeli: hizmet, sağlayıcı, konum, başlangıç zamanı, süre, fiyat ve politika.
Yeniden planlama ve iptal akışları bildirimden veya rezervasyon ekranından “tek dokunuşla” yapılabiliyorsa en iyi çalışır. Bir değişiklikten sonra, hangi alanın değiştiğini ve ücret uygulanıp uygulanmadığını açıkça belirten tek bir güncelleme gönderin.
Müşteriler için pratik bir hatırlatma takvimi:
Sağlayıcılar için günlük program özeti ve yeni rezervasyon/iptaller için anlık uyarılar ekleyin.
Gelinmemeler genellikle unutma, trafik veya bağlılık eksikliğinden olur. Yaygın araçlar:
Bekleme listesi varsa, açılan slotları otomatik olarak bir sonraki kişiye teklif edin ve sağlayıcıyı yalnızca slot yeniden rezerve edildiğinde bilgilendirin.
Randevu sonrası mesajlar, spam yapmadan tutmayı artırabilir:
Fiş gönderin, bir inceleme isteyin ve aynı hizmet/sağlayıcı için “Tekrar rezerve et” kısayolu sunun. Uygun ise bakımla ilgili talimatlar veya sağlayıcının özet notu ekleyin ve bunları rezervasyon geçmişinde erişilebilir tutun.
Ödemeler basit bir rezervasyon akışını destek sorununa dönüştürebilir. Bu bölümü hem ürün tasarımı hem de müşteri hizmetleri politikası olarak ele alın: uygulama müşterinin ne kadar borcu olduğunu, ne zaman borçlu olduğunu ve plan değişirse ne olacağını açıkça göstermeli.
Çoğu zamanlama uygulaması üç modu iyi destekler:
Hangi modu sunarsanız sunun, fiyat dökümünü onaydan önce gösterin: hizmet fiyatı, vergiler/ücretler, depozito ve daha sonra ödenecek tutar.
İade mantığını sade dilde tanımlayın ve UI'da gösterin:
Kararı mümkün olduğunca otomatikleştirin ki destek manuel istisna hesaplaması yapmak zorunda kalmasın.
Opsiyonel ama değerli:
Kart bilgilerini tokenize eden ve PCI uyumluluğunu kendi tarafında tutan bir ödeme sağlayıcısı kullanın (örn. hosted payment fields). Uygulama sadece minimum bilgileri saklamalı: ödeme durumu, tutarlar ve sağlayıcı işlem ID'leri—ham kart verileri saklanmamalı.
Takvim senkronizasyonu güven oluşturmanın en hızlı yollarından biridir: sağlayıcılar zaten kullandıkları takvimi kullanmaya devam edebilir, uygulamanız da doğru kalır.
Tek yönlü senkronizasyon uygulamanızdan dış takvime (Google, Apple, Outlook) randevuları itmek demektir. Daha basit, daha güvenli ve MVP için sıkça yeterlidir.
Çift yönlü senkronizasyon ayrıca dış takvimden meşgul zamanları okur (ve bazen olayları) ve bu da uygulamanızda kullanılabilirliği engeller. Bu daha kullanışlıdır ama özel olaylar, tekrar eden toplantılar ve dışarıda yapılan düzenlemeler gibi köşe durumları ile uğraşmanıza neden olur.
Çoğalmalar genellikle her güncellemede yeni bir etkinlik oluşturduğunuzda olur. Kararlı bir tanımlayıcı kullanın:
Dış düzenlemeler için kaynak olarak neyi kabul edeceğinize karar verin. Kullanıcı dostu yaygın bir kural:
Derin entegrasyonlar olmasa bile onay e-postalarında ICS davetleri gönderin ki müşteriler Apple/Google takvimine tek dokunuşla ekleyebilsin.
Yerel Google/Apple takvim bağlantıları sunuyorsanız, kullanıcılar şunları bekler:
Sağlayıcılar paylaşılan içerik üzerinde kontrol sahibi olmalıdır:
Daha sonra bir yönetici paneli eklerseniz, bu ayarları /settings altında toplayın ki destek elle senkronizasyonla uğraşmak zorunda kalmasın.
Bir zamanlama uygulaması müşterinin rezervasyon yaptığı andan sonra yaşananlara bağlıdır. Sağlayıcılar kullanılabilirliği hızlıca güncelleyecek araçlara ihtiyaç duyar, yöneticiler ise dağınıklığın destek biletlerine dönüşmesini önleyecek denetime ihtiyaç duyar.
En azından, her sağlayıcı kendi çalışma gerçekliğini destekleyecek şekilde aşağıyı yapabilmelidir:
Hafif günlük operasyon özellikleri ekleyin:
Yönetici panosu rezervasyon edilebilirliği ve parayı etkileyen her şeyi merkezileştirmeli:
Raporlama zamanlamayı karara dönüştürür:
Destek araçları sürtüşmeyi azaltır:
Eğer farklı katmanlar sunuyorsanız, gelişmiş raporlama ve geçersiz kılmaları yönetici-only bir alanda (/pricing) tutun.
Bir zamanlama uygulaması sonsuza kadar genişleyebilir, bu yüzden ilk sürüm tek bir şeye odaklanmalı: müşterinin doğru sağlayıcıyla güvenilir şekilde zaman ayırtabilmesi.
Çok hizmetli bir rezervasyon MVP'si için sıkı bir ekran seti hedefleyin: hizmet kataloğu (süre/fiyat ile), sağlayıcı seçimi (veya “en uygun”), kullanılabilir zamanların takvim görünümü, rezervasyon detayları + onay ve “Rezervasyonlarım” ile yeniden planlama/iptal.
Backend'de ilk API yüzeyini küçük tutun: hizmetleri/sağlayıcıları listele, kullanılabilirliği getir, rezervasyon oluştur, güncelle/iptal et ve bildirim gönder. Sağlayıcı saatleri ve izinlerini yönetmek için temel yönetici araçları ekleyin—bunlar yoksa destek talebi hızla artar.
Native (Swift/Kotlin) iyi performans için harikadır, ama bir MVP için paylaşılan UI'ye daha hızlı ulaşmak adına React Native veya Flutter genelde daha hızlıdır.
Backend için takımınızın teslim edip sürdürebileceği bir şey seçin: Node.js, Django veya Rails hepsi uygundur. Rezervasyonlar ve kullanılabilirlik kuralları için Postgres kullanın, ödeme/kısa süreli tutmalar sırasında çift rezervasyonu önlemek için Redis kullanın.
Rezervasyon akışlarını aylarca custom mühendisliğe başlamadan önce hızlıca doğrulamak istiyorsanız, sohbet tabanlı bir spec ile çekirdek ürünü prototiplemenize yardımcı olabilecek bir vibe-coding platformu olan Koder.ai işinizi kolaylaştırabilir.
Koder.ai React web uygulaması, Go backend ile PostgreSQL ve bir Flutter mobil uygulaması üretebilir; planlama modu, kaynak kodu dışa alma ve snapshot/rollback destekler—zaman dilimleri, tamponlar ve yeniden planlama mantığında iterasyon yaparken geriye dönük hataları önlemek için faydalıdır.
Test edin:
Küçük bir beta grubu ile başlayın (5–20 sağlayıcı) ve basit bir geri bildirim döngüsü kurun: uygulama içi “Bir sorun bildir” ve haftalık başarısız rezervasyon/iptal incelemesi.
API'nizi baştan versiyonlayın ki eski uygulama sürümlerini kırmadan iterasyon yapabilesiniz ve dahili operasyonlar ile destek için net bir değişiklik günlüğü yayınlayın.
Zamanlama uygulaması kişisel bilgiler, takvimler ve ödemelerle ilgilenir—küçük güvenlik hataları hızla güven kaybına dönüşür. Bu kontrol listesini MVP'nizi aşırı inşa etmeden güvenli ve güvenilir tutmak için kullanın.
Sadece gerçekten gerekli olanı toplayarak başlayın: isim, iletişim yöntemi, zaman ve hizmet. Hassas notları varsayılan olarak saklamaktan kaçının.
Rol tabanlı erişim kullanın:
API'de en az ayrıcalık ilkesini zorlayın, sadece UI ile yetinmeyin.
Parolaları modern hashing ile saklayın (örn. bcrypt/Argon2), sağlayıcılar/yöneticiler için isteğe bağlı 2FA etkinleştirin ve oturumları kısa ömürlü tokenlarla güvenceye alın.
Rezervasyonu kritik bir işlem olarak ele alın. “Slot zaten alınmış”, ödeme hataları ve takvim senkronizasyon sorunları gibi hataları takip edin.
İzleme için correlation ID'leri kullanın (her rezervasyon denemesi için bir ID) ki olayları servisler arasında izleyebilin. Loglarda hassas veri bulundurmayın (ham kart verisi yok, PII minimum).
Veritabanını düzenli yedekleyin ve geri yüklemeleri periyodik olarak test edin. RPO/RTO hedeflerinizi tanımlayın (ne kadar veri kaybedebilirsiniz ve ne kadar hızla kurtarmanız gerekir).
Basit bir olay müdahale kitabı belgeleyin: kim aranır, rezervasyonu geçici olarak nasıl durdurursunuz ve durum iletişimi nasıl yapılır (örn. /status).
Saklama kurallarını yayımlayın (iptal edilen rezervasyonlar ve kullanıcısı inaktif hesaplar ne zaman silinir). İhracat/silme istekleri sunun.
Düzenlenmiş kategorilere hizmet veriyorsanız gereksinimler değişir:
Hassas alanlar için aktarımda (TLS) ve saklamada şifreleme kullanın ve üçüncü taraf SDK'ları yayına almadan önce gözden geçirin.