Teslimatları, sürücüleri ve rotaları takip etmek için bir lojistik web uygulaması planlayın ve inşa edin. Temel özellikler, veri akışı, haritalar, bildirimler, güvenlik ve yayına alma adımlarını öğrenin.
Ekran taslağı çizmeye veya teknoloji yığını seçmeye başlamadan önce, lojistik web uygulamanız için başarının neye benzediğine karar verin. “Takip” birçok şeyi ifade edebilir ve belirsiz hedefler genellikle kimsenin sevmediği, dağınık bir ürüne yol açar.
Bir birincil iş hedefi ve birkaç destekleyici hedef seçin. Örnekler:
İyi bir hedef, kararları yönlendirecek kadar spesifik olmalıdır. Örneğin, “geç teslimatları azaltmak” sizi sadece daha güzel bir haritaya değil, doğru ETA'lara ve istisna yönetimine yönlendirir.
Çoğu teslimat takip yazılımının birden fazla hedef kitlesi vardır. Erken tanımlayın ki her rol için her şeyi inşa etmeyesiniz.
MVP'nizin odaklı kalması için üçte tutun. Yaygın metrikler:
Sistemin hangi sinyalleri yakalayacağını yazın:
Bu tanım, ürün kararları ve ekip beklentileri için paylaşılan bir sözleşme olur.
Ekranları tasarlamadan veya araçları seçmeden önce, bir teslimatın operasyonunuzda nasıl ilerlediği konusunda tek bir “gerçek” üzerinde anlaşın. Net bir iş akışı, “Bu durak hâlâ açık mı?” veya “Neden bu işi yeniden atayamıyorum?” gibi kafa karışıklıklarını önler ve raporlamayı güvenilir kılar.
Çoğu lojistik ekibi basit bir omurgada uzlaşabilir:
Create jobs → assign driver → navigate → deliver → close out.
İşinizin özel durumları (iade, çoklu duraklı rotalar, kapıda ödeme) olsa bile omurgayı tutarlı tutun ve varyasyonları her müşteri için yeni bir akış icat etmek yerine istisna olarak ekleyin.
Durumları sade bir dille tanımlayın ve karşılıklı dışlayıcı olsun. Pratik bir set:
Hangi olayların her bir durum değişikliğine neden olduğunu kararlaştırın. Örneğin, “En route” sürücünün “Navigasyonu başlat”a dokunmasıyla otomatik olabilir; “Delivered” ise her zaman açık bir onay olmalıdır.
Sürücü tarafında desteklenmesi gereken işlemler:
Dispatcher tarafında desteklenmesi gereken işlemler:
Sonradan anlaşmazlıkları azaltmak için her değişikliği kim, ne zaman ve neden ile kaydedin (özellikle Failed ve yeniden atamalar için).
Net bir veri modeli, bir “noktalı harita”yı güvenilir teslimat takip yazılımına dönüştürür. Temel nesneleri iyi tanımlarsanız dispatch panosu daha kolay kurulur, raporlar doğru olur ve operasyonlar geçici çözümlere ihtiyaç duymaz.
Her teslimatı bir iş olarak modelleyin; durumlar arasında ilerler (planned, assigned, en route, delivered, failed vb.). Sadece adres değil, gerçek dispatch kararlarını destekleyecek alanlar ekleyin:
İpucu: alış ve bırakmayı “durak” olarak ele alın ki bir iş daha sonra çoklu duraklı hale gelse yeniden tasarlamak zorunda kalmayın.
Sürücüler sadece bir isim değil; operasyonel kısıtlamaları yakalayın ki rota optimizasyonu ve dispatch gerçekçi kalsın:
Bir rota, sıralı durak listesini ve sistemin beklediği ile gerçekleşen arasındaki farkı saklamalıdır:
Kim neyi ne zaman değiştirdiğini gösteren değiştirilemez bir olay kaydı ekleyin (durum güncellemeleri, düzenlemeler, yeniden atamalar). Bu, müşteri anlaşmazlıkları, uyumluluk ve “neden geç kaldı?” analizleri için önemlidir—özellikle teslimat kanıtı ve istisnalarla eşleştirildiğinde.
İyi lojistik takip yazılımı büyük ölçüde bir UX sorunudur: doğru bilgi, doğru anda, en az tıklama ile. Özellikleri inşa etmeden önce temel ekranları taslaklayın ve her kullanıcının 10 saniye içinde ne yapabilmesi gerektiğine karar verin.
İşlerin atandığı ve problemlerin yönetildiği yer burasıdır. Görsel olarak hızlı okunur ve aksiyon odaklı olmalı:
Liste görünümünü hızlı, aranabilir ve klavye kullanımına uygun tutun.
Dispatcher’lar sadece noktaları değil, günün öyküsünü anlatan bir haritaya ihtiyaç duyarlar.
Canlı sürücü konumlarını, durak pinlerini ve renk kodlu durumları (Planned, En route, Arrived, Delivered, Failed) gösterin. Basit geçişler ekleyin: “sadece geç riskindekileri göster”, “sadece atanmamışları göster”, “sürücüyü takip et”. Bir pîne tıklamak kompakt bir durak kartı açmalı; içinde ETA, notlar ve sonraki aksiyonlar olsun.
Sürücü ekranı tüm plan yerine sonraki durak üzerine odaklanmalı.
İçerikler: sonraki durak adresi, talimatlar (kapı kodu, bırakma notu), iletişim butonları (dispatcher veya müşteri arama/mesaj), ve minimum yazma ile hızlı durum güncellemesi. Teslimat kanıtı destekleniyorsa bunu aynı akış içinde (fotoğraf/imza + kısa not) tutun.
Yöneticiler ham olaylar değil eğilimler ister: zamanında performans, bölgeye göre teslimat süresi ve en yaygın başarısızlık nedenleri. Raporları kolayca dışa aktarılabilir ve hafta hafta karşılaştırılabilir yapın.
Tasarım ipucu: her ekranda tutarlı bir durum sözlüğü ve renk sistemi tanımlayın—bu eğitim süresini kısaltır ve pahalı yanlış anlamaları önler.
Haritalar, “bir durak listesi”ni dispatch ve sürücüler için kullanılabilir bir şeye dönüştürür. Amaç gösterişli kartografya değil—daha az yanlış dönüş, daha net ETA'lar ve daha hızlı kararlar.
Çoğu lojistik web uygulaması aynı temel harita özelliklerine ihtiyaç duyar:
Başlangıçta tek bir sağlayıcıya mı dayanacağınızı (daha basit) yoksa sağlayıcıları bir iç servis arkasında soyutlayıp esneklik mi elde edeceğinizi (daha fazla iş) erkenden kararlaştırın.
Kötü adresler başarısız teslimatların başlıca nedenidir. Koruyucular oluşturun:
Orijinal metin adresini ve çözülmüş koordinatları ayrı saklayın ki tekrar eden sorunları denetleyip düzeltebilesiniz.
Başlangıçta manuel sıralama (sürükle-bırak) ile pratik yardımcılar sunun: “yakındaki durakları grupla”, “başarısız teslimatı sona taşı”, “acil durakları önceliklendir”. Sonra gerçek dispatch davranışını öğrendikçe basit optimizasyon kuralları ekleyin (en yakın-sonraki, sürüş süresini minimize et, geri gitmeyi önle).
MVP rota planlaması bile şu tür kısıtlamaları anlamalı:
Bu kısıtlamaları UI'da net belgelerseniz dispatch planına güvenir ve gerektiğinde manuel müdahalenin neden gerektiğini anlarsınız.
Gerçek zamanlı sürücü takibi ancak güvenilir, anlaşılır ve pil ömrüne saygılıysa fayda sağlar. Kod yazmadan önce “gerçek zamanlı”nın operasyonlarınız için ne demek olduğunu karar verin: dispatcher’lar saniye saniye hareket ister mi yoksa müşteri sorularına yanıt ve gecikmelere tepki için 30–60 saniye aralığı yeterli mi?
Daha yüksek güncelleme sıklığı panoda daha düzgün hareket sağlar ama pil tüketir ve mobil veri kullanır.
Pratik bir başlangıç:
Ayrıca varış/ayrılış gibi anlamlı olaylarda güncellemeler tetikleyebilirsiniz.
Dispatcher görünümü için iki yaygın desen vardır:
Birçok ekip önce periyodik yenileme ile başlar, dispatch hacmi arttığında WebSockets ekler.
Sadece son koordinatı tutmayın. Track point (zaman damgası + lat/long + isteğe bağlı hız/doğruluk) saklayın ki:
Mobil ağlar düşer. Sürücü uygulaması sinyal kaybında konum olaylarını yerelde kuyruğa almalı ve geri geldiğinde otomatik senkronize etmelidir. Panoda sürücüyü “Son güncelleme: 7 dk önce” olarak işaretleyin, noktanın güncelmiş gibi görünmesine izin vermeyin.
İyi yapıldığında gerçek zamanlı GPS takibi güven oluşturur: dispatch olanı görür ve sürücüler güvenilmez bağlantı nedeniyle cezalandırılmaz.
Bildirimler ve istisna yönetimi temel bir lojistik uygulamasını güvenilir takip yazılımına dönüştürür. Erken harekete geçmeyi sağlar ve müşterilerin arama sebeplerini azaltır.
Başlangıç için operasyonlara ve müşterilere önemi olan küçük bir olay setiyle başlayın: dispatched, yakında varıyor, teslim edildi ve teslimat başarısız oldu. Kullanıcıların kanalı seçmesine izin verin—push, SMS veya e‑posta—ve kimin ne aldığını belirleyin (sadece dispatcher, sadece müşteri veya her ikisi).
Pratik kural: müşteriye yönelik mesajları yalnızca bir şey değiştiğinde gönderin; operasyonel mesajlar daha detaylı (durak nedeni, iletişim denemeleri, notlar) olabilir.
İstisnalar net koşullar tarafından tetiklenmeli, içgüdü değil. Son mil teslimatında yaygın olanlar:
İstisna tetiklendiğinde dispatch panosunda önerilen bir sonraki adımı gösterin: “alıcıyı ara”, “yeniden ata” veya “gecikme olarak işaretle”. Bu kararları tutarlı tutar.
Teslimat kanıtı sürücüler için kolay, anlaşmazlıklarda doğrulanabilir olmalı. Tipik seçenekler:
POD'u teslimat kaydının bir parçası olarak saklayın ve müşteri desteği için indirilebilir yapın.
Farklı müşteriler farklı ifade ister. Mesaj şablonları ve müşteri başına ayarlar (zaman pencereleri, yükseltme kuralları, sessiz saatler) ekleyin. Bu, teslimat uygulamanızı kod değişikliği gerektirmeden büyüdükçe uyarlanabilir kılar.
Hesaplar ve erişim kontrolü, ilk anlaşmazlık, ilk yeni depo veya bir müşteri “Bu teslimatı kim değiştirdi?” dediğinde gözden kaçması kolaydır. Net bir izin modeli kazara düzenlemeleri, hassas verilerin sızmasını ve dispatch ekibini yavaşlatmayı engeller.
Basit bir e‑posta/şifre akışı ile başlayın, ama üretime hazır hale getirin:
Müşteriler veya daha büyük kullanıcılar kimlik sağlayıcıları (Google Workspace, Microsoft Entra ID/AD) kullanıyorsa SSO için yükseltme yolu planlayın. MVP'de olmasa bile kullanıcı kayıtlarını SSO kimliğiyle ilişkilenecek şekilde tasarlayın ki çift hesap oluşmasın.
Başlangıçta onlarca mikro izin oluşturmayın. Gerçek işlerle eşleşen küçük bir rol seti tanımlayın, sonra geri bildirime göre rafine edin.
Lojistik uygulamaları için yaygın roller:
Hassas işlemleri kimlerin yapabileceğini belirleyin: post‑dispatch düzenleme, fiyat/maliyet alanlarını görüntüleme, veri dışa aktarma gibi.
Birden fazla deponuz varsa tenant‑benzeri ayrımı erken isteyebilirsiniz:
Bu, ekipleri odaklı tutar ve yanlışlıkla başka bir deponun işlerine müdahaleyi azaltır.
Anlaşmazlıklar, chargeback'ler ve “neden yeniden yönlendirildi?” soruları için ana işlemlerle ilgili eklenebilir-only olay kaydı oluşturun:
Denetim girdilerini değiştirilemez ve teslimat ID'sine ve kullanıcıya göre sorgulanabilir yapın. Ayrıca teslimat detay ekranında insan tarafından okunabilir bir “Aktivite” zaman çizelgesi göstermek destek işini kolaylaştırır.
Entegrasyonlar, bir takip aracını günlük operasyonların merkezi haline getirir. Kod yazmadan önce zaten kullandığınız sistemleri listeleyin ve hangi sistemin siparişler, müşteri verisi ve faturalama için “gerçek kaynak” olduğunu belirleyin.
Çoğu lojistik ekibi birden fazla platforma dokunur: sipariş yönetim sistemi, WMS, TMS, CRM ve muhasebe. Hangi veriyi çektiğinizi (siparişler, adresler, zaman pencereleri, ürün sayısı) ve hangi veriyi geri gönderdiğinizi (durum güncellemeleri, POD, istisnalar, ücretler) belirleyin.
Basit bir kural: çift girişten kaçının. Dispatcher'lar bir OMS'de iş yaratıyorsa, teslimatları sizin uygulamanızda yeniden oluşturmaya zorlamayın.
API'nizi ekibinizin anladığı nesneler etrafında tutun:
REST endpoint'leri çoğu durum için uygundur, ve webhooklar harici sistemlere gerçek zamanlı güncellemeler göndermek için idealdir. Durum güncellemelerinde idempotency zorunlu kılın ki yeniden denemeler olay çoğaltmasın.
API'lere rağmen operasyon ekipleri CSV isteyecektir:
Gerekliyse planlı senkronizasyonlar (saatlik/gecelik) ekleyin; ne başarısız oldu, neden ve nasıl düzeltilir gibi açık hata raporlaması sağlayın.
İş akışınız barkod okuyucular veya etiket yazıcılar kullanıyorsa, bunların uygulamanızla nasıl etkileşeceğini tanımlayın (durak onayı için tarama, paketi doğrulamak için tarama, depoda etiket yazdırma). MVP için sınırlı bir destek seti ile başlayın, dökümante edin ve kanıtlandıktan sonra genişletin.
Teslimatları ve sürücüleri takip etmek çok hassas operasyonel veriler (müşteri adresleri, telefonlar, imzalar, gerçek zamanlı GPS) anlamına gelir. Birkaç erken karar maliyetli olayları önleyebilir.
En azından veriyi taşırken HTTPS/TLS ile şifreleyin. Kalan veride, barındırma sağlayıcınız destekliyorsa (veritabanları, fotoğraf için nesne depolama, yedekler) şifrelemeyi etkinleştirin. API anahtarlarını ve erişim belirteçlerini güvenli bir secrets manager’da saklayın—kaynak kodunda veya paylaşılan tablolar/elektronik tablolar içinde değil.
Gerçek zamanlı GPS güçlüdür ama gerekli olandan daha detaylı olmamalıdır. Birçok ekip için yeterli olan:
Net saklama süreleri tanımlayın. Örneğin: yüksek frekanslı konum pinglerini 7–30 gün saklayın, sonra performans raporlaması için downsample (saatlik/günlük) yapın.
Giriş, takip ve halka açık POD linkleri için abuse’u azaltmak adına rate limiting ekleyin. Uygulama olaylarını, admin işlemlerini ve API isteklerini merkezi loglayın ki “bu durumu kim değiştirdi?” sorusunu hızlıca cevaplayabilesiniz.
Ayrıca başından yedekleme ve geri yükleme planlayın: otomatik günlük yedekler, test edilmiş geri yükleme adımları ve ekibinizin kriz anında takip edebileceği bir olay listesi.
Sadece ihtiyacınız olanı toplayın ve nedenini belgeleyin. Sürücü takibi için onay ve bilgilendirme sağlayın; veri erişimi veya silinme taleplerini nasıl yöneteceğinizi tanımlayın. Hem dahili hem müşterilerle paylaşılacak kısa, sade bir politika beklentileri hizalar ve ileride sürprizleri azaltır.
Bir lojistik takip uygulaması gerçek hayatta başarılı olur veya başarısız olur: dağınık adresler, geç sürücüler, zayıf bağlantı ve baskı altındaki dispatcher’lar. Sağlam bir test planı, dikkatli bir pilot ve pratik eğitim "çalışan yazılım"ı "insanların gerçekten kullandığı yazılım" haline getirir.
Mutlu yol testlerinin ötesine geçin ve günlük kaosu yeniden yaratın:
Hem web (dispatch) hem mobil (sürücü) akışlarını ve başarısız teslimat, depoya dönüş veya müşteri evde değil gibi istisna akışlarını test edin.
Takip ve haritalar genellikle çökmeden önce yavaş hissedilir. Test edin:
Yüklenme sürelerini ve duyarlılığı ölçün, sonra ekibin izleyebileceği performans hedefleri belirleyin.
Bir depo veya bir bölge ile başlamak, tüm şirkete yaymaktan iyidir. Önceden başarı kriterleri belirleyin (örn. POD içeren teslimat yüzdesi, azalan “sürücüm nerede?” çağrıları, iyileşen zamanında teslimat oranı). Haftalık geri bildirim toplayın, sorunları hızlı düzeltin, sonra genişletin.
Kısa bir hızlı başlangıç kılavuzu oluşturun, ilk kez kullananlar için uygulama içi ipuçları ekleyin ve net bir destek süreci belirleyin: sürücüler yolda kime ulaşır, dispatcher nasıl hata bildirir. İnsanlar bir şey ters gittiğinde ne yapacağını bildiğinde benimseme artar.
Lojistik web uygulamasını ilk kez inşa ediyorsanız, en hızlı yol dispatch ve sürücüler için değer kanıtlayan dar bir MVP tanımlamak, ardından iş akışı stabil olunca otomasyon ve analiz eklemektir.
İlk sürüm için olmazsa olmazlar genellikle: teslimat oluşturup sürücü atayabilen bir dispatch panosu, durak listesini gören sürücü dostu basit bir mobil web görüntüsü veya uygulama, temel durum güncellemeleri (Picked up, Arrived, Delivered) ve rota görünürlüğü için bir harita.
İyi‑olur ama erken yavaşlatanlar: karmaşık rota optimizasyon kuralları, çoklu depo planlama, otomatik müşteri ETA'ları, özel raporlar ve geniş entegrasyonlar. Bunları MVP dışında tutun, gelir getirdiğini kanıtlamadıkça.
Pratik bir lojistik yığını:
Eğer ana hedefiniz ilk sürümü hızla doğrulamaksa, bir "vibe-coding" yaklaşımı işinizi görebilir. Koder.ai ile ekipler dispatcher panosunu, sürücü akışını, durumları ve veri modelini sohbette tarif ederek çalışan bir web uygulaması (React) ve Go + PostgreSQL arka ucu oluşturabilir.
Bu, pilot için özellikle yararlıdır:
MVP değer kanıtlayınca kaynak kodunu dışa aktarabilir ve geleneksel mühendislik hattına devam edebilirsiniz veya platform üzerinden dağıtmaya devam edebilirsiniz.
Teslimat takip yazılımında en büyük maliyet sürükleyici öğeler genellikle kullanım tabanlıdır:
Bu kalemleri tahmin etmede yardıma ihtiyacınız varsa, bir hızlı teklif talep etmek için /pricing veya iş akışınızı tartışmak için /contact üzerinden bilgi almayı düşünebilirsiniz.
MVP stabil olduğunda yaygın yükseltmeler: müşteri takip bağlantıları, daha güçlü rota optimizasyonu, teslimat analizleri (zamanında %, durma süresi), ana hesaplar için SLA raporları.
Başarı için önce birincil bir hedef belirleyin (ör. geç teslimatları azaltmak veya “sürücüm nerede?” aramalarını azaltmak) ve ardından 3 ölçülebilir sonuç belirleyin: zamanında teslimat oranı, başarısız durak oranı ve boşta geçen süre gibi. Bu metrikler MVP'nizi odaklı tutar ve “takip”in amaçsız bir harita ve özellik yığınına dönüşmesini engeller.
Sisteminizin ne yakalayacağını açık, paylaşılan bir tanım yazın:
Bu, ürün kararlarını yönlendiren ve ekipler arası beklentileri uyumlu kılan bir sözleşme olur.
Durumları birbirini dışlamayacak şekilde tutun ve her değişikliğin ne tetiklediğini kesinleştirin. Pratik bir temel set:
Bazı geçişleri otomatik (ör. navigasyon başlatıldığında “En route”) diğerlerini her zaman açık seçim olarak tanımlayın (ör. “Delivered” her zaman sürücü tarafından onaylanmalı).
Teslimatı bir iş (job) olarak ele alın ve teslimatı gelecekte çoklu durak içerebilecek şekilde modelleyin. Modellemeniz gereken temel varlıklar:
Bir eklenebilir-only (append-only) olay kaydı, anlaşmazlıklar ve analiz için gerçeğin kaynağıdır. Kaydedilmesi gerekenler:
Her girişte kim, ne zaman ve neden olduğunu gösterin ki destek ve operasyon ekipleri "ne oldu?" sorusuna tahminle değil, kanıtla cevap verebilsin.
Bir kullanıcının 10 saniye içinde aksiyon almasını sağlayacak ekranlara öncelik verin:
Adres kalitesi etrafında koruyucular oluşturun:
Ayrıca orijinal metin ve çözümlenmiş koordinatları ayrı saklayın ki tekrar eden sorunları denetleyip upstream düzeltmeler yapabilesiniz.
Kullanışlılık ile pil/ veri kullanımı arasında denge kuran pratik bir başlangıç politikası:
Periyodik güncellemeleri, varış/ayrılış gibi olay tetiklemeli pinglerle birleştirin. "Son güncelleme: X dakika önce" gösterimi eklemeyi unutmayın.
Güvenilmez bağlantıya hazırlıklı olun:
Rolleri az tutun ve gerçek işlere göre tanımlayın:
Birden fazla depo varsa erken aşamada şube/depo kapsamlaması ekleyin ve hassas işlemleri (dışa aktarma, dağıtımdan sonra düzenleme) daha sıkı izinlerle koruyun. Ayrıca güçlü bir denetim kaydı tutun.
