POS entegrasyonu: kurye şirketi 3. parti POS siparişlerini de teslim etsin.

Bu entegrasyon tam olarak neyi çözüyor?

Türkiye'de paket servis yapan restoranların büyük bölümü zaten bir POS yazılımı kullanıyor. Menüsü orada kurulu, kasası orada kapanıyor, personeli o ekranı biliyor. Bu restoranlardan teslimat için yeni bir yazılıma geçmesini istemek, çözülmesi gereken sorunun kendisinden daha büyük bir değişiklik talep etmek anlamına gelir.

Oysa asıl eksik yazılım değil, kurye. Restoran siparişi zaten alabiliyor; alamadığı şey paketi kapıya götürecek kişidir. Kendi kuryesini tutmak sabit maliyet demektir: maaş, sigorta, motosiklet, yakıt ve sipariş gelmeyen saatlerde boş bekleyen personel. Yoğun saatte ise tam tersi olur, mevcut kurye sayısı yetmez ve sipariş ya gecikir ya reddedilir.

POS entegrasyonu bu iki tarafı birbirine bağlar. Restoran kendi POS'unda kalır; POS yazılımı siparişi Hızlıyo'ya iletir; Hızlıyo o bölgedeki filoya iş emrini düşürür; kurye paketi alır ve teslim eder. Restoran yazılım değiştirmeden teslimat kapasitesine, filo ise yeni bir iş hacmine erişmiş olur.

Yalnızca teslimat yapmak isteyen kurye şirketi için

Kurye şirketlerinin bir bölümü sipariş yönetimi işine hiç girmek istemez. Amaç nettir: paketi restorandan almak, müşteriye zamanında ulaştırmak, teslim kaydını kapatmak. Bu şirketler için restoranın hangi POS'u kullandığı, menüsünü nasıl kurduğu veya kasasını nasıl kapattığı bir konu değildir; tek ihtiyaç, taşınacak işin düzgün bir kayıt hâlinde panele düşmesidir.

Pratikte en zorlanılan yer tam da burasıdır. Anlaşma yapılan restoranın kendi sipariş sistemi olduğunda siparişin filoya nasıl ulaşacağı sorun hâline gelir; bu iş çoğu zaman telefonla veya WhatsApp grubuyla yürür. Adres kulaktan yazılır, hazır olma saati kayar, hangi kuryenin nereye gittiği panelde görünmez, gün sonunda kaç teslimat yapıldığı ancak elle sayılır.

Entegrasyon bu kanalı standartlaştırır. Sipariş filoya yapılandırılmış bir iş emri olarak düşer: teslimat adresi, alıcı bilgisi, paket tutarı, ödeme durumu ve restoranın hazır olma zamanı aynı kayıtta gelir. Kurye atama, konum takibi, teslim kaydı ve raporlama filonun kendi panelinde yürür — telefon trafiği ortadan kalkar.

İkinci kazanç kapsam genişlemesidir. Filo yalnızca Hızlıyo kullanan restoranlarla sınırlı kalmaz; farklı POS firmalarının müşterisi olan, kendi yazılımında kalmak isteyen restoranların siparişleri de taşınabilir hâle gelir. Aynı kurye kapasitesiyle daha fazla iş yapılır ve yeni restoran eklemek tek tek kurulum değil, POS firması üzerinden toplu bir bağlantı işine dönüşür.

Restoran Hızlıyo kullanmadan teslimat nasıl yapılıyor?

Bu sorunun cevabı entegrasyonun kiminle kurulduğunda saklı. Bağlantı restoranla değil, restoranın kullandığı POS yazılımını yapan firmayla kurulur. Yani teknik işi bir kez POS firması yapar; o firmanın müşterisi olan yüzlerce restoran aynı bağlantıdan yararlanır.

Restoran tarafında görünen tek yenilik, POS ekranındaki bir "kurye çağır" adımı ve ardından gelen durum bilgisidir. Menü Hızlıyo'ya taşınmaz, fiyatlar Hızlıyo'da tanımlanmaz, kasa Hızlıyo'da kapatılmaz. Restoranın Hızlıyo'da bir hesabı, bir paneli, öğrenmesi gereken bir ekranı olmaz.

Bu ayrım aynı zamanda ticari bir ayrımdır. Restoran POS firmasının müşterisi olarak kalır; Hızlıyo restoranın yazılım tedarikçisi hâline gelmez, yalnızca teslimat katmanını sağlar. Filo da restoranın yazılımına karışmaz, yalnızca taşıma hizmetini verir.

Teknik akış: sipariş isteği ve durum bildirimi

Entegrasyon iki yönlü bir hattan oluşur. Birinci yön sizden bize doğrudur: POS yazılımı teslimat gerektiren bir sipariş oluştuğunda Hızlıyo'ya bir sipariş isteği gönderir. Bu istekte teslimat adresi, alıcının iletişim bilgisi, paketin içeriği ve tutarı, ödeme durumu ve siparişin hazır olacağı zaman yer alır.

İkinci yön bizden size doğrudur: teslimatın her aşamasında başvuruda bildirdiğiniz adrese bir durum bildirimi gönderilir. Kurye atandığında, kurye restorana ulaştığında, paket teslim alındığında ve müşteriye bırakıldığında ayrı bildirimler düşer. Böylece POS ekranındaki sipariş kaydı, kurye hareket ettikçe kendiliğinden güncellenir.

Bu iki yön dışında sistemler arasında veri paylaşımı yoktur. Menü, stok, personel, ciro ve müşteri kayıtları POS tarafında kalır; Hızlıyo yalnızca teslimatı yürütmek için gereken bilgiyi alır. Entegrasyonun dar tutulması hem geliştirme süresini kısaltır hem de veri sorumluluğunu net bırakır.

Bildirim adresi (webhook) neden zorunlu?

Başvuru formunda istenen bildirim adresi, teslimat durumlarının POS tarafına ulaştığı kanaldır. Bu adres olmadan entegrasyon tek yönlü kalır: sipariş Hızlıyo'ya gider ama sonucu geri dönmez, restoran da kuryenin nerede olduğunu göremez.

Adres için iki kural var. Birincisi, adresin https ile başlaması gerekir; teslimat bilgisi şifrelenmemiş bir kanaldan iletilmez. İkincisi, adresin internetten erişilebilir olması gerekir — yerel ağ adresleri, localhost ve iç ağa ait alan adları kabul edilmez, çünkü bu adreslere dışarıdan bildirim gönderilemez.

Bildirim adresi sonradan değiştirilebilir. Test ortamında farklı, canlıda farklı bir adres kullanmak yaygın bir tercihtir; her iki adres de aynı kurallara tabidir.

Kapsama alanı, hacim ve limitler

Teslimatın yapılabilmesi için restoranın bulunduğu bölgede hizmet veren bir filonun olması gerekir. Başvuruda hizmet verdiğiniz şehirlerin sorulmasının nedeni budur: kapsama alanı, entegrasyonun teknik tarafından önce netleşmesi gereken konudur.

Tahmini restoran sayısı ve günlük sipariş adedi ise istek limitlerinin belirlenmesinde kullanılır. Yüz restoranla başlayan bir entegrasyonla, bin restoranı olan bir POS firmasının yükü aynı değildir; limitler beyan edilen hacme göre ayarlanır. Bu bir taahhüt değildir, tahmin yeterlidir ve hacim büyüdükçe güncellenir.

Sipariş yoğunluğunun saatlere göre dalgalanması beklenen bir durumdur. Akşam yoğunluğunda gelen sipariş yığını, filo tarafında kurye havuzuyla karşılanır; kapasite dolduğunda sipariş sırası ve tahmini teslim süresi buna göre hesaplanır.

Başvuruda hangi bilgiler isteniyor?

Form üç adımdan oluşur. İlk adımda firmanın ticari ünvanı, vergi numarası, yetkili kişi bilgileri ve POS ürününüzün adı istenir. Bu bilgiler sözleşme tarafının ve entegre edilecek ürünün netleşmesi için gereklidir.

İkinci adım tekniktir: bildirim adresi ile teknik yetkilinin adı ve e-postası alınır. Teknik yetkili, bildirim adresinde bir sorun oluştuğunda iletişime geçilecek kişidir ve ticari yetkiliden farklı olabilir.

Üçüncü adımda hacim beyanı yer alır: tahmini restoran sayısı, tahmini günlük sipariş adedi ve hizmet verilen şehirler. Başvuru gönderildikten sonra değerlendirme sonucu ve test ortamı bilgileri e-posta ile iletilir.

Kimler için uygun, kimler için değil?

Model, kendi POS veya sipariş yazılımını geliştiren firmalar için tasarlandı. Restoran POS'u, adisyon programı, kurumsal yemek sipariş sistemi, market ve pastane otomasyonu gibi ürünlerin hepsi aynı akışı kullanabilir; taşınan şeyin paket olması yeterlidir.

Tek bir restoran işletiyorsanız ve kendi yazılımınız yoksa bu sayfa aradığınız yer değildir. Bu durumda doğrudan restoran başvurusu yapılabilir; teslimat, sipariş yönetimi ve kasa tek pakette gelir.

Kurye şirketiyseniz ve iş hacmini büyütmek için farklı POS firmalarının restoranlarına ulaşmak istiyorsanız, filo başvurusu üzerinden ilerlemek daha doğrudur. Bu sayfadaki entegrasyon, siparişin filoya ulaşmasını sağlayan teknik katmandır.