Takip numaralarını saklayan, taşıyıcı güncellemelerini çeken ve müşterilere "teslimata çıktı" veya "gecikme" gibi otomatik mesajlar gönderen bir gönderi takip panosu oluşturun.
Çoğu “Siparişim nerede?” sorusu gerçekten meraktan kaynaklanmaz. İnsanlar belirsiz hissettiğinde ortaya çıkar: takip yavaş güncelleniyor, taşıyıcı ifadeleri kafa karıştırıyor veya teslimat penceresi hiçbir mesaj gelmeden geçiyor.
Destek ekipleri için bu belirsizlik sürekli bir bilet, sohbet ve takip akışına dönüşür. Bir gecikmiş paket kolayca üç ayrı konuşma yaratabilir: “Herhangi bir güncelleme?”, “Teslim edildi diyor ama elimde yok” ve “Takip bağlantısını yeniden gönderebilir misiniz?” Her biri zaman alır. Her biri iade talebi veya kötü bir yorum ihtimalini artırır.
Sorun, takip bilgileri dağınık olduğunda daha da kötüleşir. Takip numaraları elektronik tablolarda duruyorsa, taşıyıcı güncellemeleri gelen kutularına geliyor ve sipariş detayları mağaza yöneticisinde bekliyorsa, her müşteri sorusu mini bir soruşturmaya dönüşür. Birileri durumları kopyala-yapıştır yapar, “Yolda”nun bugün ne anlama geldiğini tahmin eder ve bir şey değiştiğinde müşteriyi bilgilendirmeyi unutabilir.
Bir gönderi takip panosu, güncellemeleri ortak bir gerçek kaynağına çevirir ve doğru zamanda doğru mesajı gönderir. Amaç basit: ekibiniz her şeyi tek bir yerde görsün ve müşteriler “teslimata çıktı” veya “gecikme” gibi proaktif güncellemeler alsın, sormak zorunda kalmasınlar.
Bu anlatım kasıtlı olarak pratik kalır:
Eğer bunu AppMaster gibi no-code bir araçla inşa ediyorsanız, tek güvenilir bir akış düşünün: takip bilgilerini sakla, düzenli aralıklarla güncellemeler çek, durumu normalize et ve önemli olduğunda bildirim gönder.
Bir gönderi takip panosu veriler düzenli kalırsa işe yarar. Her gün dokunacağınız kayıtlarla başlayın ve her taşıyıcının tüm ayrıntılarını baştan modelleme isteğine direnin.
En azından dört temel nesneye ihtiyacınız var: sipariş (order), müşteri, gönderi (shipment) ve taşıyıcı (carrier). Siparişler ve müşteriler çoğu sistemde zaten vardır, bu yüzden yeni iş genelde gönderi kaydıdır: hangi siparişe ait olduğu, hangi taşıyıcıya ait olduğu ve takip numarası (artı “UPS Ground” gibi gösterim adı). Bir sipariş birden fazla kutuda gönderilebiliyorsa, baştan her sipariş için birden çok gönderiyi destekleyin.
Durum geçmişi bir sonraki olmazsa olmazdır çünkü neyin ne zaman değiştiğini açıklar. Hem göstermek istediğiniz “temiz” alanları (olay türü, zaman damgası, konum) hem de ham taşıyıcı mesajını kaydedin. Ham mesaj, etiket kafa karıştırdığında veya normalize kurallarınız henüz olgunlaşmadığında güvenlik ağıdır.
Pratik bir başlangıç seti şöyle görünebilir:
Bu bildirim kaydı beklenenden daha önemlidir. Bir müşteri “bana mesaj göndermeyi bırak” dediğinde ne gönderdiğinizi, ne zaman ve hangi kanaldan gönderdiğinizi kanıtlamanız gerekir. Ayrıca bir sağlayıcı zaman aşımına uğradığında ve sisteminiz tekrar denediğinde aynı bildirimin çoğalmasını önlemeye yardımcı olur.
Gizliliği basit ama gerçek tutun. Kimlerin müşteri telefon numarasını ve e-postasını görebileceğini sınırlayın ve “gönderi durumunu görüntüle” ile “müşteri iletişimini görüntüle”yi ayırın. Bir depo kullanıcısı takip numarasını görmeye ihtiyaç duyabilir ama müşterinin telefonunu görmesi gerekmez.
AppMaster'da inşa ediyorsanız, bunları Data Designer'da ayrı varlıklar olarak modelleyin ve doğru ekranların doğru alanları göstermesi için roller ekleyin; böylece sonra ek yeniden çalışma yapmanız gerekmez.
Güvenilir takip sıkıcı bir kararla başlar: hangi taşıyıcılar en çok önem taşıyor. Haftada en çok gönderdiğiniz ilk 1–3 taşıyıcıyı seçin, onları baştan sona çalışır hale getirin, sonra uzun kuyruğu ekleyin.
Güncellemeleri almanın üç yaygın yolu vardır:
Güncellemelerin nasıl geldiği, nereden geldiklerinden en az onun kadar önemlidir. Webhook'lar (push) “teslimata çıktı” veya teslimat taraması gibi gerçek zamanlı değişikliklere yakın sonuç gerektiğinde idealdir. Polling (pull) daha basittir ve taşıyıcı webhook desteklemiyorsa işe yarar, ama gecikebilir ve daha fazla istek maliyeti doğurur.
Pratik bir kurulum hibrittir: mümkün olan yerlerde webhook, güvenlik ağı olarak planlı polling. Örneğin AppMaster'da webhook olaylarını kabul edecek bir endpoint oluşturabilir ve 12 saattir değişmeyen gönderileri yeniden kontrol etmek için zamanlanmış bir Business Process çalıştırabilirsiniz.
Her şeyi tek bir zamanlayıcıya bağlamak yerine gönderi aşamasına göre yenileyin. Bu maliyetleri düşürür ve API'ları gereksiz yere zorlamaz.
Taşıyıcı kesintilerine ve gecikmelere hazırlıklı olun. Son başarılı kontrol zamanını saklayın, geri çekmeli retry (backoff) uygulayın ve ekibin verinin taze olup olmadığını bilmesi için panoda “son güncelleme” zaman damgası gösterin.
Taşıyıcı takip beslemeleri dağınık olur. Bir taşıyıcı “Shipment information received” der, başka birisi “Electronic notification” der ve üçüncüsü gün içinde on farklı “in transit” taraması gönderir. Hepsini olduğu gibi gösterirseniz, takip panonuz gürültüye döner.
Ekip ve müşterilerin anlayabileceği küçük bir iç durum setiyle başlayın ve taşıyıcı ekledikçe bunları sabit tutun:
Sonra her taşıyıcı olayını bu kovalarından birine eşleyin. Eşlemeyi taşıyıcı olay koduna, olay metnine veya her ikisine göre yapabilirsiniz. Kuralı basit tutun: gelen her olay, gönderiyi ileri taşıyorsa veya gerçek bir sorunu işaret ediyorsa internal_status alanını güncellesin.
Ayrıca tüm ham taşıyıcı yükünü (tam olay JSON'u ve orijinal metin) saklayın. Panoda normalize edilmiş durum gösterilmeli, ama destek ve operasyon ekipleri bir şey ters gittiğinde taşıyıcının tam olarak ne gönderdiğini açıp görebilmelidir.
Bilinmeyen olaylar olacaktır. Onları “değişiklik yok” olarak ele alın ve inceleme için kaydedin. Tarama atlamaları da olur: bir paket “etiket oluşturuldu”dan “teslimata çıktı”ya atlayabilir. İş akışınız atlamalara izin vermeli, hata vermemeli veya kafa karıştırıcı mesajlar göndermemelidir.
Pratik bir desen olarak iki alan saklayın: internal_status ve carrier_last_event_at. Bir süre event görmüyorsanız, müşteriye gecikme deme yerine dahili olarak “inceleme gerekli” diye işaretleyin.
AppMaster'da bu eşleme iyi bir şekilde bir Business Process içine sığar: taşıyıcı olayını alır, ham yükü yazar, iç durumu hesaplar ve gönderi kaydını tek adımda günceller.
Bir iş akışı ancak öngörülebilirse işe yarar. Onu küçük bir boru hattı gibi düşünün: takip numarasını yakala, güncellemeleri çek, neyin değiştiğine karar ver, sonra bildir ve yaptıklarınızı kaydet.
Etiket oluşturulduğunda takip bilgisini toplayın. Hızlı manuel giriş ve fulfillment aracınızdan toplu içe aktarma destekleyin. Taşıyıcı adı, takip numarası, sipariş ID'si ve eklendiği zamanı kaydedin.
Savunulabilir bir zamanlamayla taşıyıcı güncellemelerini çekin. Örnek: “yolda” için her 2 saatte bir, “teslimata çıktı” için her 30 dakikada bir, “teslim edildi” için günde bir. Her çekme en son taşıyıcı olayını (durum, olay zamanı, varsa konum ve ham mesaj) saklamalıdır ki pano en yeni gerçeği yansıtsın.
Gerçek bir değişikliğin ne olduğunu belirleyin. Yeni bir tarama her zaman anlamlı değildir. Normalize edilmiş durum değiştiğinde (örneğin “yolda”dan “teslimata çıktı”ya), bir istisna görüldüğünde veya çok uzun süredir güncelleme yoksa (örneğin 48 saat tarama yok) tetikleme mantığı çalışsın.
Mesajı gönderin ve denetim izini (audit trail) yazın. Her bildirim bir log kaydı oluşturmalı: kim bilgilendirildi, kanal (email/SMS/Telegram), kullanılan şablon ve sonuç (gönderildi, başarısız, atlandı). Bu, destek ekibinin “Bana mesaj attınız mı?” sorusuna saniyeler içinde yanıt verebilmesini sağlar.
Hataları sakin, sıkıcı kurallarla yönetin. Zaman aşımı ve taşıyıcı API aksaklıkları normaldir. Artan beklemelerle yeniden deneyin (örneğin 5 dakika, 30 dakika, 2 saat), son tekrar sonrası gönderiyi “güncelleme başarısız” olarak işaretleyin ve sadece birçok gönderi arasında hatalar devam ederse ekibi uyarın. Eksik veri yüzünden müşteri uyarısı göndermeyin.
AppMaster'da inşa ediyorsanız, gönderileri ve olayları Data Designer'da modelleyebilir, polling ve karar mantığını bir Business Process içinde çalıştırabilir ve bildirim kaydını raporlama için birinci sınıf tablo olarak tutabilirsiniz.
Bir takip panosu yalnızca destek veya operasyon “Mevcut durum nedir ve bir sonraki adım ne olmalı?” sorusuna hızlı cevap verebiliyorsa yardımcı olur. Bir gelen kutusu gibi hissettiren tek bir ana ekranla başlayın.
Ana tabloyu sıkıcı ve hızlı yapın. İnsanların ilk taradığı alanları öne koyun: müşteri adı, sipariş numarası, taşıyıcı, mevcut durum ve “son güncelleme” zamanı. Bir sütun da “bir sonraki eylem” için ekleyin (örneğin: müşteriyi bilgilendir, bekle, incele). Bu küçük ipucu tahmin yürütmeyi azaltır.
Filtreler panoyu kullanışlı kılan yerdir. Sorunlara odaklı tutun:
Birisi bir gönderiyi açtığında detay görünümü hikâyeyi ekstra tıklama istemeden anlatmalı. Açık dille bir zaman çizelgesi gösterin ve kendi ileti geçmişinizi yanında tutun ki çakışan mesaj göndermeyin. Örneğin: “Müşteri gecikme hakkında 10:14'te bilgilendirildi” ve “Müşteri yanıtladı: ön büroya bırakın.”
Toplu işlemleri küçük, güvenli ve geri alınabilir tutun. Genelde fayda sağlayan birkaç şey: en son bildirimi yeniden gönder, şablon tabanlı manuel güncelleme gönder, dahili not ekle ve birine ata.
AppMaster'da bunu inşa ediyorsanız, önce iki temiz ekran (liste ve detay) hedefleyin ve sonra ekip günlük akışın doğal hissettirdiğini onaylayınca genişletin.
Takibi faydalı (spam olmayan) hissettiren en hızlı yol daha az mesaj göndermek ama zamanlamayı iyi yapmaktır. Müşterilerinizin zaten kullandığı kanallarla başlayın: çoğu güncelleme için e-posta, zaman hassas anlar için SMS ve kitleniz sohbet tercih ediyorsa Telegram.
Şablon kütüphanesini başta küçük tutun. Bir avuç mesaj çoğu ihtiyacı karşılar: teslimata çıktı, gecikme, teslim edildi ve istisna (adres sorunu, taşıyıcıda bekletme, iade).
Her şablon üç soruyu hızlıca yanıtlamalı: ne değişti, sonraki adım ne olacak ve son taşıyıcı güncellemesi ne zaman görüldü. Sipariş numarasını ve son bilinen taramanın zaman damgasını ekleyin ki destek biletleri hızla çözülsün.
Zamanlama kuralları sözcüklerden en az onun kadar önemlidir. Sessiz saatler belirleyin (mümkünse müşterinin saat dilimine göre) ve bir müşteriye beş tarama için beş ping göndermeyecek şekilde frekans sınırı koyun. “Günde en fazla bir proaktif güncelleme ve ayrıca teslim edildi” gibi basit bir kural birçok mağaza için iyi çalışır; ciddi sorunlar için istisnalara izin verin.
Tercihler basit ama etkili olabilir. En azından kanal bazlı vazgeçme bayraklarını saklayın (email kapalı, SMS kapalı, Telegram kapalı) ve bunlara iş akışında her yerde uyun. Birisi SMS'ten vazgeçtiyse, sonra “sadece bu sefer” diye SMS göndermeyin.
İyi bir varsayılan, normalize edilmiş anlamlı durum değişikliklerinde bildirim göndermektir, her taşıyıcı olayında değil. Taşıyıcı üç “yolda” taraması gönderiyorsa müşteri hiçbir şey görmez. “Teslimata çıktı”ya geçince bir mesaj görür.
AppMaster'da yerleşik email/SMS ve Telegram modüllerini kullanabilir ve sessiz saatler ile frekans sınırlarını tek bir Business Process içinde uygulayarak aynı kuralların tüm kanallarda korunmasını sağlayabilirsiniz.
İyi uyarılar gösterişli taktiklerden çok net kurallarla ilgilidir. Kural belirsizse, mesaj yanlış olur ve müşteriler güvenini kaybeder.
“Gecikme”yi nasıl tanımladığınızla başlayın. Pratik bir kural “X saat içinde yeni tarama yok” (tipik teslimat hızınıza uyan bir değer seçin) veya “beklenen teslimat tarih penceresi kaçtı” olabilir. İkisini birlikte kullanmak en iyisidir: ilki takılı kalan paketleri erken yakalar, ikincisi taramalar gelmeye devam etse bile geç teslimatları yakalar.
“Teslimata çıktı”yı tek seferlik bir an olarak ele alın. Taşıyıcılar bu olayı bazen tekrarlar. Müşteriye her gönderide bir kez bildirin, sonra tekrarları bastırın; durum daha sonra gerçekten sorun haline gelirse (örneğin “teslimata çıktı” sonrası bir istisna) yeniden bildirin.
“Teslim edildi”yi taşıyıcı teslim taramasıyla teyit edin ve bunu nihai kabul edin. Geri bildirim isteyecekseniz bunu daha sonra (örneğin ertesi gün) yapın ki paketi bulurken müşteriyi bölmeyin.
İstisnaların kendi kuralları olmalı çünkü genelde eylem gerektirir. Yaygın olanlar: adres sorunları, tesiste bekletme, teslim girişimi ve iade göndericiye. Bunlar hepsi aynı müşteri mesajını tetiklememeli. Bazıları önce ekibinize gitmeli, özellikle müşteri bununla tek başına uğraşamayacaksa.
Doğru kalan basit bir kural seti:
AppMaster'da bu kuralları düzenlenebilir tutun (eşik saatleri, yüksek-değer kesme noktası, sessiz saatler) ki iş akışını yeniden kurmadan ayarlayabilesiniz.
Takip gürültülü veya yanlış hissettirdiğinde güven çabuk kırılır. En büyük neden panoyu her taşıyıcı taramasının canlı akışı gibi kullanmaktır. Müşteriler art arda “Tesise ulaştı” gibi beş bildirime aldırmaz; onlar beklentilerini değiştiren birkaç net anla ilgilenir.
Diğer yaygın başarısızlık aşırı bildirimdir. İnsanlar mesajlar anlamsız geldiğinde vazgeçer ve vazgeçtiklerinde gerçek sorunlar için en iyi kanalınızı kaybedersiniz. Müşteri tarafında olayları sınırlı tutun (etiket oluşturuldu, teslimata çıktı, teslim edildi, gecikme, istisna) ve geri kalanı panoda bırakın.
Yeniden denemeler de güvenilirliği yok edebilir. Sistem zaman aşımına uğrayıp tekrar denerse aynı “teslimata çıktı” mesajını iki kez gönderebilir. Bunu idempotency ile çözün: her gönderi ve olay için benzersiz bir anahtar kaydedin (örneğin shipment_id + normalized_status + event_time) ve aynı bildirimi daha önce gönderdiyseniz tekrar gönderme.
Sessiz bir sorun da her gönderi için son başarılı senkronizasyonu takip etmemektir. Bunu yapmazsanız ya çok fazla yeniden çekme yapar (çoğalmaya neden olur) ya da güncellemeleri kaçırırsınız (sessizlik yaratır). last_synced_at zaman damgası ve işlenen son taşıyıcı olay ID'sini saklayın ve bunları yalnızca başarılı bir çekme sonrası güncelleyin.
Taşıyıcıları sabit kodlamak başka bir tuzaktır. Bir veya iki taşıyıcı için işe yarar, sonra yeni bir taşıyıcı eklemek yeniden yazım gerektirir. Gelen veriyi kendi durum modelinize normalize edin ve taşıyıcıya özgü eşlemeyi tek bir yerde tutun. AppMaster'da bu genelde her sağlayıcı için yeniden kullanılabilir bir “carrier adapter” Business Process anlamına gelir; hepsi aynı tabloları ve bildirim mantığını besler.
Müşteriyle yüzleşmeden önce hızlı bir kontrol yapın; odak nokta güven olmalı: doğru veri, öngörülebilir güncellemeler ve spam yapmayan mesajlar.
Hataların genelde başladığı yerden başlayın: fulfillment. Takip numarasının etiket oluşturulduğu anda yakalandığından ve doğrulandığından emin olun (taşıyıcı formatı, boş değil, fazladan boşluk yok). Eğer bazen birden fazla kutuda gönderiyorsanız, bir sipariş için birden çok takip numarasını ilkini üzerine yazmadan saklayabildiğinizi doğrulayın.
Çoğu boşluğu yakalayan kısa bir kontrol listesi:
AppMaster'da inşa ediyorsanız, bu işi yapan Business Process'i, denetim için kaydedilen log kayıtlarını ve destek ekibinin ilk günden kullanacağı filtreleri iki kere kontrol edin.
Küçük bir e-ticaret mağazası günde yaklaşık 80 sipariş gönderir. İki taşıyıcı kullanıyorlar ve takip numaraları etiket oluşturulur oluşturulmaz ekleniyor. Buna rağmen destek gelen kutusu günde yaklaşık 20 “Siparişim nerede?” mesajı alıyor. Çoğu müşteri kızgın değil, sadece son taramanın ne anlama geldiğinden emin değil.
Bir takip panosu kurdular; taşıyıcı güncellemelerini zamanlayarak çekiyor ve tek bir basit görünüm gösteriyor: normal hareket edenler, takılı kalanlar ve insan müdahalesi gerektirenler.
En büyük kazanım bir kuraldan geldi: 48 saattir taşıyıcı güncellemesi olmayan herhangi bir gönderiyi işaretle. Bu gönderiler “dikkat” kuyruğuna gidiyor, diğer her şey “yolda” olarak kalıp ekibin yolundan çekiliyor. Destek her siparişi takip etmeyi bırakıyor ve gerçekten riskte olan birkaç siparişe odaklanıyor.
Gerçekten gecikmiş bir paket olduğunda, müşteriye net ve eyleme geçirilebilir tek bir mesaj gidiyor. Her taramayı tekrar etmiyor. Ne değiştiğini, mağazanın ne yaptığını ve müşterinin bir sonraki adımda ne yapması gerektiğini söylüyor.
Örnek gecikme mesajı:
“Siparişiniz son 2 gündür hareket etmedi. Taşıyıcıyla kontrol ediyoruz. Eğer acil ihtiyaç duyuyorsanız, bu mesaja ‘ACİL’ diye yanıt verin, size seçenekler sunalım.”
Bir hafta sonra fark açıkça görülüyor. Pano hangi siparişlerin işlem gerektirdiğini (tarama yok, istisna durumu, adres sorunu) diğerlerinden ayırıyor. Daha az belirsiz güncelleme ve daha az manuel arama ile WISMO biletleri azalıyor çünkü müşteriler sormadan önce bilgilendirilmiş hissediyor.
AppMaster'da kurarsanız, Data Designer'da siparişleri ve gönderileri modelleyebilir, taşıyıcı polling'ini zamanlayabilir ve aynı iş akışından e-posta veya SMS bildirimleri gönderebilirsiniz.
Bilmeyerek büyük başlamak yerine kasıtlı olarak küçük başlayın. Bir sevkiyat takip panosu doğru, tutarlı ve desteklemesi kolay olduğunda güven kazanır. En hızlı yol, gözlemleyebileceğiniz dar bir sürüm oluşturup birkaç hafta sonra genişletmektir.
Başlangıç için bir taşıyıcı, bir bildirim kanalı ve iki müşteri mesajı: “Teslimata çıktı” ve “Gecikme” ile başlayın. Bu, takip çekimlerinizin çalıştığını, durum eşlemenizin dayandığını ve müşterilerin zamanlamadan dolayı kafalarının karışmadığını doğrulamak için yeterlidir.
İlk sürüm basit olabilir:
Temeller stabil olduktan sonra, sürprizleri önleyen parçaları ekleyin: istisna yönetimi ve dahili uyarılar. Örneğin, 48 saattir güncelleme yoksa ekibi bilgilendirin yerine müşteriyi mesajlamayın. Bir taşıyıcı hata döndürürse birkaç kez yeniden deneyin, sonra inceleme için işaretleyin.
Kod yazmadan yapmak istiyorsanız AppMaster (appmaster.io) veri modelini görselleştirmek, iş mantığını visual workflow'larda oluşturmak ve aynı yerden müşteri teslimat bildirimleri göndermek için pratik bir seçenek sunar. Ayrıca kuralları sonradan değiştirmeyi de kolaylaştırır.
Daha fazla taşıyıcıya ve daha fazla mesaj türüne ölçeklemeden önce, günlük işletmeyi nasıl yürüteceğinize karar verin: başarısız çekimleri izleme, mesaj loglarını gözden geçirme ve vazgeçmeleri tutarlı şekilde uygulama. Bunlar, hacim arttıkça panoyu işe yarar tutan şeylerdir.
Bir sevkiyat takip panosu gerçekten “Siparişim nerede?” taleplerini azaltır mı?Çoğu ekip, manuel aramaları bırakıp birkaç proaktif güncelleme göndermeye başladığında en büyük düşüşü görür. Tek bir doğruluk kaynağı artı “teslimata çıktı”, “gecikme” ve “teslim edildi” mesajları genellikle WISMO taleplerinin büyük kısmını ortadan kaldırır.
Panoyu kullanışlı tutmak için önce hangi verileri saklamalıyım?Önce sevkiyat kaydı, takip numarası, taşıyıcı, mevcut normalize edilmiş durum ve bir durum geçmişi tablosu ile başlayın. Erken bir bildirim kaydı ekleyin ki gönderilenleri kanıtlayın, kopyaları önleyin ve vazgeçmeleri (opt-out) tutarlı şekilde uygulayın.
Taşıyıcı durumlarını kafa karıştırıcı değil, okunabilir nasıl yaparım?Küçük, sabit bir küme tutun: Etiket oluşturuldu, Yolda, Teslimata çıktı, Teslim edildi ve İstisna. Her taşıyıcının olay kodunu veya mesajını bu kategorilere eşleyin ve ham taşıyıcı metnini sadece bir ekip üyesi ayrıntılara baktığında gösterin.
Taşıyıcı güncellemelerini çekmek için webhooks mu yoksa polling mi kullanmalıyım?En iyi sonuç için hibrit bir kurulum: taşıyıcı destekliyorsa webhooks (push), aksi halde periyodik sorgulama (polling) yedek olarak. “Teslimata çıktı” için daha sık, “yolda” için daha seyrek sorgulayın ve teslimat onaylandıktan sonra sorgulamayı durdurun.
Takip güncellemelerini ne sıklıkla yenilemeliyim?Her aşamaya göre yenileyin; hepsi için tek bir zamanlayıcı kullanmayın. Pratik bir varsayılan: ön-transitte günde 1–2 kez, transit halinde her 4–8 saatte bir, teslimata çıktıysa her 30–60 dakikada bir ve teslim edildikten sonra durdurun.
Bildirimi rahatsız edici değil, yardımcı olacak şekilde nasıl ayarlarım?Normalize ettikten sonra anlamlı durum değişikliklerinde bildirim gönderin, her taramada değil. Basit bir varsayılan: günde en fazla bir proaktif güncelleme ve ayrıca “teslim edildi” mesajı; ciddi sorunlar için istisnalar tanıyın.
Bir şeyin “gecikmiş” olduğunu anlamak için iyi bir kural nedir?“Gecikme” için net eşikler tanımlayın; örneğin “24–48 saat içinde yeni tarama yok” veya “beklenen teslimat penceresi kaçtı”. Eksik veriler için önce dahili inceleme bayrağı koyun, müşteri mesajı göndermeden önce emin olun.
Sistem yeniden denerken aynı SMS veya e-postayı tekrar göndermesini nasıl önlerim?Her gönderiyi kayıtlayın: shipment ID, kanal, alıcı, mesaj türü, zaman damgası ve sağlayıcı sonucu. Ayrıca shipment + status + event_time gibi benzersiz bir anahtar kullanarak aynı uyarının tekrar gönderilmesini engelleyin.
Destek ve operasyonlar için panolar hangi öğeleri içermeli?Destek için hızlı bir liste görünümü verin; filtreler: istisnalar, son X saatte güncelleme yok, bugün teslimata çıktı ve bugün teslim edildi. Ayrıntılar bölümünde açık bir zaman çizelgesi ve ileti geçmişi gösterin ki ajanlar çakışan mesaj göndermesin.
Bunu AppMaster'da çok fazla kod yazmadan oluşturabilir miyim?Evet—bir taşıyıcı, bir kanal ve iki mesajla başlayın (“teslimata çıktı” ve “gecikme”) ve akışın çalıştığını doğrulayın. AppMaster'da Data Designer ile veri modelini kurabilir, Business Process ile güncelleme mantığını çalıştırabilir ve bildirimleri ve logları aynı uygulama içinde tutabilirsiniz.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
