Rezervasyon uygulamanızda nasıl başlar?
Kendi uygulamanıza restoran rezervasyonu eklemek için önce hangi restoranlara erişebileceğinizi ve kullanıcıya hangi rezervasyon adımlarını sunacağınızı belirleyin. Ardından müsaitlik sorgusu, geçici hold, confirm, gerekiyorsa ödeme/finalize ve rezervasyon güncellemelerini izleme akışını tasarlayın. Örneğin cuma akşamı iki kişilik masa arayan kullanıcı restoran seçtiğinde tarih ve kişi sayısını aynı uygulamada tamamlamak isteyebilir; bu deneyimin çalışması teknik bağlantı kadar doğru durum yönetimine de bağlıdır.
Banka, mobilite veya lifestyle uygulamasında bu deneyimi oluşturmak, yalnızca bir API bağlantısı kurmakla bitmez. Restoran erişimini, müsaitliğin nasıl gösterileceğini, durum değişikliklerinin kullanıcıya nasıl ulaşacağını ve hangi sonucu ölçeceğinizi birlikte tasarlarsınız. Dört soru, teknik ekip çalışmaya başlamadan önce bu çerçeveyi netleştirir.
Restoran erişimini ve vaadinizi netleştirin
Kullanıcınıza göstereceğiniz restoranlar, rezervasyon deneyiminizin temelini oluşturur. Rezervem Guest Network; banka, mobilite, lifestyle, otel, concierge, medya ve içerik üreticisi kanallarından gelen talepleri seçkin restoranlara ulaştıran ağdır. Hangi restoranların ve kullanım senaryolarının kapsama gireceği, partner modeline ve anlaşma kapsamına göre belirlenir.
Guest Network ağın kendisidir; Partner API ise kurumsal uygulamanızın bu ağa ve Rezervem'e bağlandığı teknik kapıdır. Restoran erişimini tek tek bağlantılarla kurmak yerine talep ve müsaitlik akışını tanımlı bir entegrasyon üzerinden yönetirsiniz. Kullanıcı kitlenizin şehirlerini, restoran beklentisini ve uygulamadaki rezervasyon yüzeyini baştan tarif edin.
Kullanıcı bir restorana uygulamanızdan ulaştığında, karşısına hangi restoranların çıkacağını ve bu restoranlar için ne vaat edeceğinizi net biçimde göstermelisiniz. Seçki, uygulamanızın konumlandırmasını; rezervasyon yüzeyi ise deneyimin nerede başlayıp nerede tamamlanacağını belirler.
Müsaitliği canlı akışın parçası hâline getirin
Kullanıcı cumartesi 20.00 için masa aradığında uygulamadaki bilgi, restoranın o andaki takvimiyle uyumlu olmalıdır. Yetkili Guest Network ortağı önce erişebildiği restoranların rezervasyon kurallarını alır; tarih, saat ve kişi sayısına göre müsaitlik sorgular. Uygun seçenek bulunması tek başına kesin rezervasyon değildir: Geçici hold ve confirm adımları, ödeme gerekiyorsa ilgili finansal adımlar da tasarlanmalıdır.
Teknik kapsamı erken konuşun: Hangi restoranlar listelenecek, hangi veriler dönecek, hangi işlemler yapılabilecek ve istek limitleri nasıl tanımlanacak? Bu ayrıntılar partner bazında belirlenir. Limitler plan, hacim ve sözleşme kapsamına göre değişebilir. Yoğun akşam saatlerini, aynı anda gelen sorguları ve kullanıcının sonuç alamadığı senaryoları test planınıza ekleyin.
Rezervasyon ekranında boş masa göstermek kadar, sonuç gelmediğinde doğru yönlendirme yapmak da akışın parçasıdır. Uygulamanızda alternatif saat, başka restoran veya yeniden arama seçenekleri bulunabilir; hangisinin kullanılacağı ürün kararınızdır. Rezervasyon API'sinde müsaitlikten talebe uzanan adımları akış rehberinde inceleyebilirsiniz.
Durum değişikliklerini kullanıcıya geri taşıyın
Uygulama, misafire rezervasyonun hangi aşamada olduğunu açıkça göstermelidir. Ödeme gerekmeyen akışta confirm sonucuyla kayıt oluşabilir; anında ödeme veya provizyon gereken durumda ödeme sonrası Finalize çağrısı gerekebilir. Misafir ödeme ekranından uygulamaya dönemediğinde başarılı tahsilatı kesin rezervasyonla karıştırmayın; önce güncel işlem durumunu doğrulayın.
Rezervasyon oluştuktan sonra tarih, saat veya durum değişebilir. Webhook ilgili olayı sisteme haber verir, ancak güncel rezervasyonun bütün alanlarını taşımaz. İmzası doğrulanan bildirimin ardından rezervasyon detayı yetkili API üzerinden yeniden okunmalı, tekrar gelen olaylar ve sıralama değişiklikleri hesaba katılmalıdır. Kullanıcıya hangi kanaldan ve hangi hukuki izinle bildirim gönderileceği de önceden belirlenmelidir.
Partner API'de rezervasyon oluşturma yetkisi, gerekli partner izinlerine ve canlıya geçiş koşullarına bağlıdır. Test planına başarısız ödeme dönüşünü, süresi dolan hold'u, tekrar teslim edilen webhook'u ve izinsiz restoran isteğini de ekleyin. İşlem adımlarını rezervasyon API rehberinde inceleyebilirsiniz.
Ölçüm, rezervasyon sayısının ötesini gösterir
Bir partnerin değerini yalnızca kaç rezervasyon gönderdiğiyle değerlendirmek eksik kalır. Guest Network, yönlendirmenin hangi partnerden geldiğini ve katkının nasıl sonuçlandığını görünür kılmayı hedefler. Uygulamanızda kanal, kampanya, restoran, rezervasyon durumu ve mümkünse ağırlanan misafir gibi alanların nasıl raporlanacağını baştan tanımlayın.
Hangi raporların gerçekten sunulacağını ve hangi verileri görebileceğinizi sözleşme ve entegrasyon kapsamına yazın. Partner ekranı veya raporlama altyapısındaki tüm alanların her kuruma otomatik açıldığını varsaymayın. Yönlendirme, rezervasyon ve restoranda ağırlanma kayıtlarını birbirinden ayrı yorumlayın.
İlk entegrasyonu küçük ve net tutun
İlk sürümde tek şehir veya sınırlı restoran seçkisiyle başlamak, geliştirme ekibinin hataları daha net görmesini sağlayabilir. Arama ve müsaitlikten sonra hold, confirm, gerektiğinde ödeme/finalize, webhook ve rezervasyon detayını yeniden okuma adımlarını birlikte test edin. Erişimi büyütme kararını bu ölçümlere göre verin.
Kullanım senaryonuzu, erişim ihtiyacınızı ve beklediğiniz ölçüm sonuçlarını Partner API sayfasında paylaşarak teknik görüşmeyle başlayabilirsiniz.
