Online Randevu Uygulaması Geliştirme: Kapsam, Maliyet ve Doğru MVP

Kısa cevap: Randevu uygulamasının çekirdeği takvim değil kapasite kuralıdır

Online randevu uygulaması geliştirme projesinde ilk görünen ekran çoğunlukla bir takvimdir; fakat ürünün kalitesini belirleyen şey takvimin arkasındaki kapasite motorudur. Bir hizmet yalnızca belirli uzmanlar tarafından verilebilir, belli bir oda veya cihaz gerektirebilir, hazırlık ve temizlik tamponu isteyebilir, şubeye göre farklı süre ve fiyat taşıyabilir. Sistem bunları birlikte değerlendirmeden yalnızca “boş saat” gösterirse çift rezervasyon, personel beklemesi ve müşteri mağduriyeti kaçınılmaz olur.

Doğru MVP; müşterinin kolayca saat seçmesinden fazlasını yapar. İşletmenin gerçekte satabileceği kapasiteyi doğru yayımlar, rezervasyonu güvenli biçimde kesinleştirir, değişiklikleri ilgili kişilere ulaştırır ve çalışanların günlük planını yönetilebilir kılar. No-show, son dakika iptali ve telefonla alınan randevu gibi çevrimdışı gerçekleri de hesaba katar.

Bu rehber klinik, güzellik ve bakım, spor, eğitim, danışmanlık, teknik hizmet ve kaynak rezervasyonu yapan işletmelerin teklif hazırlığı içindir. Özellikle sağlık verisi veya düzenlemeye tabi hizmet söz konusuysa teknik planın yanı sıra hukuk ve sektör uzmanı değerlendirmesi gerekir.

Bir slotun satılabilir olmasını sağlayan denklemi kurun

“Pazartesi 10.00 boş” bilgisi tek başına yeterli değildir. Satılabilir slot, hizmet süresi + hizmeti verebilecek personel + gerekli oda/koltuk/cihaz + şube çalışma saati + molalar + izinler + hazırlık/temizlik tamponu + müşterinin uygunluğu + varsa ulaşım süresi birleşimidir. Bazı işletmeler aynı kaynaktan birden fazla kapasite sunabilir; grup dersi 12 kişilikken birebir danışmanlık tek kişiliktir. Seri randevu, paket hakkı, vardiya ve farklı zaman dilimi gibi kurallar da modele eklenebilir.

Bu nedenle keşif toplantısında ekran listesi yerine gerçek bir haftalık program incelenmelidir. Telefon, WhatsApp veya masaüstü sisteminden gelen randevular; çalışan değişimi; bekleme listesi; geciken müşteri ve hizmet uzaması gibi olaylar ürün gereksinimine dönüşür.

Rol haritası: kim neyi görür, kim neyi değiştirebilir?

Müşteri veya danışan

Müşteri hizmeti, şubeyi ve gerektiğinde uzmanı seçer; uygun saatleri görür; gerekli ön bilgileri verir; politikaları onaylar; ödeme ya da depozito işlemini yapar; randevuyu takvimine ekler; bildirim alır; izin verilen pencere içinde değiştirir veya iptal eder. Tekrar rezervasyonda tercihleri hatırlamak kolaylık sağlar, fakat veri minimizasyonu gözetilmelidir.

Hizmet veren çalışan

Uzman kendi programını, müşteri için gerekli operasyon notlarını ve gün içi değişiklikleri görür. Randevuyu geldi, başladı, tamamlandı veya gelmedi olarak işaretleyebilir; yetkisi varsa blok zaman oluşturabilir. Sağlık, insan kaynakları veya finans gibi ilgisiz alanlara erişmemelidir. Çalışanın tüm müşteri verisini dışa aktarması da varsayılan yetki olmamalıdır.

Resepsiyon ve çağrı merkezi

Resepsiyon birden çok takvimde boşluk arar, müşteri adına randevu açar, taşır, iptal eder, bekleme listesini çağırır ve ödeme durumunu görür. Telefonla gelen taleplerde mükerrer müşteri kaydı oluşmasını engelleyen arama/eşleştirme gerekir. Yoğun işletmelerde sürükle-bırak takvim kadar değişikliğin kimin tarafından, hangi gerekçeyle yapıldığı da önemlidir.

Şube yöneticisi ve merkez operasyon

Şube yöneticisi vardiya, izin, hizmet-personel eşleşmesi, kaynak kapasitesi ve yerel fiyatları yönetir. Merkez; tüm şubelerde hizmet standardı, kampanya, rol, rapor, marka içeriği ve gerektiğinde merkezi çağrı operasyonunu kontrol eder. Franchise modelinde veri görünürlüğü ile merkezi yönetim sınırı ayrıca tasarlanır.

Sistem yöneticisi ve finans

Sistem yöneticisi kullanıcı/rol, entegrasyon ve yapılandırmayı yönetirken finans rolü ödeme, iade, depozito ve mutabakata erişir. Bu iki rolün ayrılması, tek hesabın gereğinden fazla güç kazanmasını önler. Denetim kaydı kritik program ve finans değişikliklerinde önceki değer, yeni değer, yapan kişi ve zamanı tutmalıdır.

Müşteri yolculuğu kadar istisna yolculuğunu da tasarlayın

Mutlu yol şöyledir: hizmet seçimi → uygunluk sorgusu → slot seçimi → kısa süreli rezervasyon → müşteri bilgisi/politika onayı → ödeme veya teyit → kesin randevu → hatırlatma → check-in → hizmet → takip/yeniden randevu. Fakat ticari değer istisnalarda ortaya çıkar.

Ödeme başladı ama tamamlanmadıysa slot ne kadar tutulacak? Uzman hastalandığında yüz randevu nasıl yeniden atanacak? Müşteri geç kalırsa sonraki saatlerin kapasitesi değişecek mi? İşletme randevuyu iptal ettiğinde depozito otomatik iade edilecek mi? Aynı kişi uygulamadan ve çağrı merkezinden eşzamanlı rezervasyon denerse hangisi kazanacak? Her senaryo durum geçişi, bildirim, finans hareketi ve yetki açısından yazılmalıdır.

MVP mi, ileri faz mı? İşletme modeline göre karar tablosu

Her işletme için aynı MVP doğru değildir. Bağımsız bir danışmanda Google Takvim senkronu çekirdeğe yakın olabilir; çok şubeli klinikte oda ve cihaz kapasitesi daha kritiktir; spor stüdyosunda grup kontenjanı ve üyelik hakkı ilk sürümde gerekir. Kapsam, “rakipte var” listesiyle değil kapasite kaybı ve müşteri sürtünmesiyle önceliklendirilmelidir.

Çakışmasız rezervasyon için teknik yaklaşım

Mobil uygulama uygun saatleri backend'den sorgular; fakat kullanıcının gördüğü slot birkaç saniye sonra alınmış olabilir. Kesinleştirme anında backend uygunluğu yeniden kontrol etmeli ve ilgili kaynaklar üzerinde atomik işlem, benzersiz kısıt veya süreli tutma mekanizması uygulamalıdır. Yalnızca uygulama ekranında butonu pasifleştirmek çift rezervasyonu engellemez. Ödeme akışı varsa tutulan slot için sona erme ve güvenli temizleme görevi gerekir.

Temel veri modeli hizmet, süre, tampon, çalışan yetkinliği, kaynak, şube, çalışma penceresi, istisna, randevu, katılımcı, durum geçmişi ve ödeme hareketlerini ayrı tutar. Program kuralını aylarca tek tek slot satırları oluşturarak saklamak yerine tekrar eden çalışma kuralları ve gerçekleşen rezervasyonlar dengeli biçimde modellenir. Saat dilimi ve yaz saati uygulaması, özellikle uluslararası hizmette test edilir.

Bildirimler randevunun kendisi değildir. Push ulaşmasa bile randevu veritabanında kesin olmalı; istemci açıldığında güncel durum sunucudan alınmalıdır. Firebase Cloud Messaging bildirim altyapısı için resmi bir kaynaktır, fakat teslimat ve izin davranışları nedeniyle kritik değişikliklerde e-posta/SMS veya uygulama içi gelen kutusu gibi kanallar iş kuralına göre değerlendirilir.

Takvim, CRM, ödeme ve görüntülü görüşme entegrasyonları

Takvim entegrasyonunda en önemli karar “ana kayıt sistemi”dir. Uygulama mı takvime olay yazar, yoksa dış takvimdeki her olay uygulama kapasitesini mi bloke eder? Çift yönlü senkron kolay görünür fakat silinen/değişen olay, tekrar eden etkinlik, erişim izni kaybı ve webhook gecikmesi gibi çatışmalar üretir. Google Calendar API genel bakışı olay, takvim ve erişim kontrolü kavramlarını açıklar; üretim tasarımı seçilen sağlayıcının güncel yetkilendirme koşullarıyla doğrulanmalıdır.

CRM entegrasyonu müşteri kaydını ve kampanya iznini taşırken mükerrer kayıt ile veri sahipliği çözülür. Ödeme kuruluşunda depozito, tam ödeme, iade ve başarısız işlem webhook'ları test edilir. Video görüşme bağlantısı oluşturuluyorsa bağlantının tahmin edilemez, doğru katılımcıyla sınırlı ve gerektiğinde süresi dolan yapıda olması beklenir. Sağlık bilgi sistemi, turnike veya fiziksel erişim gibi entegrasyonlar ayrı güvenlik ve kabul kapsamı ister.

KVKK, özel nitelikli veri ve güvenlik

Bir randevunun hizmet adı bile bağlama göre sağlık veya başka hassas bilgi açığa çıkarabilir. “Formda belki lazım olur” yaklaşımıyla belirti, teşhis, fotoğraf veya not toplamak risk yaratır. Toplanan her alan için amaç, hukuki sebep, erişen rol, saklama süresi, aktarım ve silme yöntemi belirlenmelidir. Sağlık verisi gibi özel nitelikli kişisel verilerin şartları ve daha sıkı korunması hakkında KVKK'nın resmi özel nitelikli veri sayfası incelenmelidir. Teknik ekip hukuki karar vermez; kararı uygulanabilir kontrole dönüştürür.

Aydınlatma metni ile pazarlama izni aynı onay kutusuna sıkıştırılmamalı; gerekli ve isteğe bağlı işlemler ayrılmalıdır. Müşteri hesabı silme talebi, finansal veya sektörel saklama yükümlülükleriyle birlikte ele alınır. Rol bazlı erişim, yönetici MFA'sı, güvenli oturum, hassas alan maskeleme, aktarım ve depolama şifrelemesi, yedekleme, logların kişisel veri sızdırmaması, dışa aktarım kontrolü ve düzenli yetki gözden geçirmesi kabul kriterlerine girmelidir.

Mobil uygulama kamera, konum, takvim veya bildirim iznini yalnızca ilgili özellik kullanılırken ve anlaşılır gerekçeyle istemelidir. Mağaza gizlilik beyanları kullanılan analitik ve hata izleme SDK'ları dahil gerçek veri akışıyla uyumlu tutulmalıdır.

Sabit fiyat yerine maliyet ve süre etkenleri

Online randevu yazılımının maliyeti ekran sayısından çok kural kombinasyonlarıyla değişir. Tek çalışan/tek hizmet ile çok şube, yüzlerce çalışan, oda-cihaz ortak kullanımı aynı iş değildir. Müşteri uygulamasına ek olarak çalışan uygulaması, resepsiyon web paneli ve merkez yönetim paneli tasarım-geliştirme-test yükünü artırır. Ödeme, takvim, CRM, video, SMS, turnike ve sağlık sistemi entegrasyonlarının dokümantasyon ve test kalitesi süreyi etkiler.

Diğer önemli kalemler veri aktarımı, çoklu dil/saat dilimi, erişilebilirlik, özel UI, raporlama, analitik, güvenlik testi, mağaza yayını ve bakım hedefidir. Tahmin öncesi kural atölyesi ve tıklanabilir prototip belirsizliği azaltır. Takvimde keşif, tasarım, geliştirme, entegrasyon onayları, test verisi hazırlığı, kullanıcı kabulü ve pilot ayrı gösterilmelidir. “X haftada kesin” vaadi yerine varsayımlar, dış bağımlılıklar ve değişiklik yöntemi görünür olmalıdır.

Beklenen teslimatlar ve kalite kapısı

Teslim listesi; kapsam dokümanı, rol/yetki matrisi, kapasite kuralları, durum diyagramı, bilgi mimarisi ve prototip, UI tasarım sistemi, mobil uygulama ve panellerin kaynak kodu, backend/API, veri şeması, entegrasyon dokümanı, ortam/dağıtım tanımı, test ve güvenlik sonuçları, analitik olay planı, mağaza materyalleri, izleme-yedekleme planı ve operasyon eğitimini içermelidir.

Kullanıcı kabul testi gerçek takvim örnekleriyle yapılır. İki müşteri son slotu aynı anda seçtiğinde tek rezervasyon oluşmalı; ödeme zaman aşımında kapasite geri açılmalı; izinli çalışan uygun görünmemeli; hizmet için yetkisiz uzman seçilememeli; dış takvim yetkisi kesildiğinde ekip uyarılmalı; toplu iptal doğru kişilere gitmeli; iade finans kaydıyla eşleşmelidir. Erişilebilirlikte ekran okuyucu etiketleri, dokunma alanları, kontrast ve dinamik metin de kontrol edilir.

KPI: doluluk tek başına başarı değildir

Randevu hunisi hizmet görüntüleme → uygun slot görüntüleme → slot seçme → teyit/ödeme → gerçekleşen hizmet → yeniden rezervasyon olarak ölçülebilir. Slot bulunamama oranı kapasite veya arama sorunu gösterir. Rezervasyon tamamlama oranı, kanala göre edinim, randevu başına destek ihtiyacı, değişiklik/iptal oranı, no-show, bekleme süresi ve hatırlatma etkisi izlenir.

İşletme tarafında çalışan ve kaynak doluluğu, boşlukların dağılımı, fazla mesai, hizmetin planlanan-gerçekleşen süresi ve şube karşılaştırmaları değerlidir. Gelir ölçümünde tahsilat, iade, depozito kaybı, paket kullanım yükümlülüğü ve yeniden satın alma birlikte okunur. Agresif doluluk hedefi tamponları yok sayıp gecikmeyi büyütüyorsa müşteri deneyimini bozabilir; metrikler birbirini dengeleyecek biçimde tasarlanmalıdır.

Risk günlüğüne ilk günden yazılacak konular

1. Çift rezervasyon: Ekran düzeyinde kontrol yerine sunucu tarafı eşzamanlılık ve veri kısıtları uygulanır.
2. Takvim senkron döngüsü: Kaynak olay kimliği, sürüm ve yazma yönü tutulur; aynı değişiklik iki sistem arasında çoğaltılmaz.
3. Bildirim bağımlılığı: Push tek kesinlik kanalı sayılmaz; uygulama açılışında güncel veri ve kritik olaylar için alternatif kanal planlanır.
4. Çalışan benimsememesi: Personel prototip testlerine katılır; program değişikliği masaüstü ve mobil iş akışına uygun tasarlanır.
5. Aşırı veri toplama: Form alanları amaç ve saklama kararı olmadan eklenmez; hassas serbest metin sınırlandırılır.
6. Politika belirsizliği: Geç kalma, iptal, depozito ve iade kuralları arayüzde işlem öncesi gösterilir ve sürümlenir.
7. Manuel kanalların dışarıda kalması: Telefon ve gişeden gelen randevular aynı kapasite kaynağına yazılır.

Teklif brief'i: ajansa ne vermelisiniz?

• İşletme tipi, şube sayısı, hizmet bölgeleri ve hedef müşteri profili.
• Hizmet listesi; süre, tampon, fiyat, ön koşul, eşzamanlı kapasite ve gerekli kaynaklar.
• Personel yetkinlikleri, vardiya/izin kuralları, oda-cihaz-koltuk gibi paylaşılan kaynaklar.
• Müşteri, çalışan, resepsiyon, şube yöneticisi, merkez ve finans rollerinin yetkileri.
• Rezervasyon, değişiklik, iptal, geç kalma, no-show, bekleme ve acil blok senaryoları.
• Ödeme/depozito, iade, paket, üyelik, fatura ve kampanya kuralları.
• Kullanılan takvim, CRM, muhasebe, SMS, video veya sektör sistemleri ve API erişimleri.
• İşlenecek kişisel veri kategorileri, özel nitelikli veri ihtiyacı ve saklama beklentisi.
• Mevcut müşteri/randevu verisinin formatı ve taşıma kalite sorunları.
• Pilot şube/ekip, başarı KPI'ları, içerik ve karar sorumluları.

Uygulanabilir proje akışı

Keşifte ekip bir “kapasite sözlüğü” çıkarır ve son haftalardaki gerçek istisnaları inceler. Prototip, yalnız müşteri rezervasyonunu değil resepsiyonun yoğun takvim düzenlemesini ve çalışanın gün ekranını da kapsar. Kullanılabilirlik testinde hedef kitleden kişiler hizmet bulma, ilk uygun saat, uzman tercihi, iptal ve yeniden rezervasyon görevlerini tamamlar.

Teknik ispat aşamasında en riskli konu seçilir: eşzamanlı rezervasyon, dış takvim veya ödeme-depozito gibi. Ardından uçtan uca dilimler geliştirilir ve otomatik testler kapasite kurallarını korur. Pilot, tüm şubeler yerine kontrollü bir hizmet/ekiple başlayabilir. Yayın sonrasında slot bulunamama, no-show ve personel geri bildirimi backlog'u yönlendirir; destek ve bakım sorumluluğu ölçülebilir hizmet seviyeleriyle yürütülür.

Sık sorulan sorular

Müşteri mobil uygulaması olmadan başlanabilir mi?

Evet. Talep sıklığı düşükse mobil uyumlu web rezervasyonu ve yönetim paneli ilk doğrulama için yeterli olabilir. Tekrar kullanım, sadakat, cihaz özelliği veya anlık bildirim belirgin değer üretiyorsa mobil uygulama yatırımı güçlenir. Karar dağıtım tercihi değil müşteri davranışı üzerinden verilmelidir.

Uygulama no-show oranını sıfırlar mı?

Hayır. Hatırlatma, kolay değişiklik, depozito, bekleme listesi ve politika görünürlüğü oranı etkileyebilir; ancak müşteri segmenti ve hizmet türüne göre deney yapılmalıdır. Sistem kanala ve kurala göre sonucu ölçebilmeli, herkese aynı agresif bildirimi göndermemelidir.

Çalışanlar kişisel takvimlerini bağlamak zorunda mı?

Zorunluluk iş modeline bağlıdır ve gizlilik açısından dikkatle ele alınmalıdır. Dış takvim bağlanıyorsa özel etkinliğin başlığını kopyalamak yerine yalnız “meşgul” bilgisini almak çoğu durumda daha ölçülüdür. Kurumsal vardiya takvimi ana kaynak olarak da seçilebilir.

Randevu süreleri müşteriye göre değişiyorsa ne yapılır?

Hizmet varyantı, ek seçenek veya yönetici onaylı süre uzatma kuralı tanımlanabilir. Serbestçe değişen süre kapasite hesaplarını belirsizleştirir; izin verilen aralıklar, kimin değiştireceği ve sonraki randevulara etkisi açık olmalıdır.

Bakım sözleşmesinde hangi maddeler olmalı?

Kritik rezervasyon veya ödeme arızası için müdahale hedefi, izleme, işletim sistemi/SDK güncellemeleri, üçüncü taraf API değişiklikleri, güvenlik yamaları, yedekleme testi, destek kanalı, dahil efor ve yeni özellik ayrımı açıkça yazılmalıdır.

Sonuç: satılabilir zamanı güvenilir bir ürüne çevirin

Randevu uygulaması yatırımı, müşteri bir saat seçtiğinde değil; o saatin doğru personel ve kaynakla gerçekten sunulabildiği, değişikliklerin operasyonu dağıtmadığı ve işletmenin kapasite verisinden karar alabildiği zaman karşılık bulur. Başlamadan önce bir haftalık gerçek takvimi, üç zor istisnayı ve iptal politikanızı masaya koymanız kapsamı dramatik biçimde netleştirir.

MobiCraft'a hizmet-kaynak listenizi ve mevcut randevu akışınızı ileterek keşif görüşmesi başlatabilirsiniz. Müşteri deneyimi, çalışan aracı ve operasyon panelini aynı kapasite modelinde planlayıp MVP ile sonraki büyüme fazlarını ayırabiliriz. Randevu uygulamanız için teklif görüşmesi başlatın.