Entegrasyon durum sayfası: senkron sağlığını ve sonraki adımları gösterin

Müşterilerin senkron durumunu görmesi neden gerekli

Bir müşteri uygulamanızı açıp rakamlar yanlış görünce nadiren "senkron işi gecikti" diye düşünür. Ürünün bozuk olduğunu, bir ekip arkadaşının bir şeyi değiştirdiğini ya da kendilerinin hata yaptığını düşünürler. Bu kafa karışıklığı küçük bir entegrasyon aksaklığını destek talebine, müşteri kaybı riskine veya uzun bir e-posta zincirine dönüştürebilir.

Müşteri tarafından görülebilen bir durum sayfası varsayımı ortadan kaldırır. İnsanların gerçekten sorduğu soruya yanıt verir: "Verilerim güncel mi, değilse ne yapmalıyım?" Bu açıklık yoksa müşteriler işlemleri tekrar dener, hesapları yeniden bağlar veya sorunu çözmeyen ayarları değiştirir.

Ayrıca iki çok farklı durumu ayırt etmelerine yardımcı olur:

• Bir kesinti: üçüncü taraf servis çöktü ya da istekleri reddediyor, bu yüzden şu anda senkron başarısız oluyor.
• Gecikmiş bir senkron: senkron çalışıyor, ama bir sonraki çalışması kuyruğa alınmış, oran sınırlaması var veya olağandan daha uzun sürüyor.

Bu iki durumda beklentiler farklı olmalı. Bir kesinti sırasında en iyi sonraki adım genellikle "bekleyin, biz otomatik yeniden deneme yapacağız" olabilir. Bir gecikmede ise en iyi sonraki adım "bir sonraki senkron planlandı" veya "şimdi çalıştırabilirsiniz" olabilir.

Entegrasyon durum sayfası için "iyi" olması, bir müşterinin durumu 10 saniyeden kısa sürede anlayıp destekle iletişime geçmeden güvenli bir adım atabilmesidir. Sayfa şunları yapmalıdır:

• Açık bir sağlık göstergesi ve güncel bir zaman damgası ile güven inşa etmek
• "Senkronlandı mı?" ve "takılı kaldı mı?" gibi tekrar eden soruları azaltmak
• Durumu daha kötüleştirmeyecek belirli bir sonraki adım sunmak
• Suçu UI'dan uzak tutarken dürüst olmak

Örnek: Bir satış yöneticisi toplantıdan önce CRM'den yeni lead'lerin gelmesini bekliyor. Sayfa "Son başarılı senkron: 12 dakika önce" ve "Sonraki çalıştırma: 3 dakika içinde" gösteriyorsa, sayfayı yenilemeyi bırakıp toplantıya devam edebilir. Eğer "Dikkat: yeniden bağlanma gerekli" gösteriyorsa, tam olarak neyi düzeltmesi gerektiğini bilir.

Müşteri tarafından görünen bir durum sayfasının cevaplaması gerekenler

Müşteri tarafından görülen entegrasyon durum sayfası varsayımları ortadan kaldırmak için vardır. Bir senkron "takılmış" görünüyorsa insanlar destek bileti açmadan net cevaplar ister.

Sayfa basit ve anlaşılır bir dizi soruyu yanıtlamalıdır:

• Entegrasyon şu an çalışıyor mu?
• Son başarılı senkron ne zaman oldu?
• Ne başarısız oldu ve etki ne kadar büyük (tüm veriler mi yoksa sadece bir kısmı mı)?
• Bunu düzeltmek veya zararı azaltmak için ne yapabilirim?

Kime konuştuğunuzda net olmak da yardımcı olur. Bir yönetici (admin) yeniden bağlamak, yeniden denemek veya izinleri değiştirmek için yeterli detayı görmelidir. Bir son kullanıcı genellikle sadece güvence ve zaman çizelgesi ister. Destek ekipleri ise hızlıca ekran görüntüsü alıp gönderebilecekleri kısa bir özet ister.

Nerede olmalı? İdeal olarak, problemi gösterdiği yerden kolayca ulaşılmalıdır. Birçok ürün bunu iki yerde sunar:

• Entegrasyona bağlı özelliğin içinde (küçük bir "Senkron durumu" paneli)
• Ayarlar veya Entegrasyonlar bölümünde (geçmişiyle birlikte tam durum görünümü)

Ne göstereceğinize dair beklentileri belirleyin. Müşteriler sağlık durumu, zamanlama ve insan tarafından okunabilir bir sebep görmelidir; ham stack trace'ler, iç servis isimleri veya gizli yük verileri gösterilmemelidir. Daha derin teşhis gerekiyorsa, bunları dahili loglarda tutun ve müşteri sayfasında kısa bir referans ID'si ekleyin.

AppMaster ile inşa ediyorsanız, basit bir ilk sürüm hedefleyin: bir durum kaydı (sağlık, son çalışma, son başarı, mesaj, sonraki eylem) ve bunu okuyan bir sayfa. Sonra genişletebilirsiniz; yukarıdaki cevaplar sayfayı kullanışlı yapan minimumlardır.

Bir bakışta gösterilmesi gereken ana alanlar

İyi bir entegrasyon durum sayfası beş saniyede okunabilir olmalıdır. Amaç her teknik detayı açıklamak değil; müşterinin "Şu an çalışıyor mu ve ne değişti?" sorusuna yanıt vermektir.

Tek bir durum özeti ile başlayın; basit etiketler kullanın: Healthy, Degraded, Down veya Paused. Kuralları tutarlı tutun. Örneğin "Degraded" bazı kayıtların başarısız olduğunu ama çoğunluğun hâlâ senkron olduğunu; "Paused" ise senkronun kasıtlı olarak durdurulduğunu (müşteri veya sistem tarafından) belirtebilir.

Özetin hemen altında insanların en çok önem verdiği üç zamanı gösterin. Hem okunabilir zaman damgası hem de göreli zaman ("12 dakika önce") kullanın ve her zaman zaman dilimini gösterin.

Aşağıdaki alanlar genelde durum sayfasının üstünde kalıcı yer almalıdır:

• Durum özeti (Healthy, Degraded, Down, Paused) ve tek satırlık sebep
• Son başarılı senkron (zaman ve göreli)
• Son denenen çalışma (başarısız olsa bile)
• Sonraki planlı çalışma (veya plan yoksa "manuel")
• Basit sayımlar: son çalışmada işlenen, başarısız olan, atlanan

Sayımlar yardımcı olmalı, gürültülü olmamalıdır. Ayrıntılı dökümler yerine küçük, stabil rakamları tercih edin. "İşlendi 1.240, Başarısız 18, Atlandı 6" çoğu müşteri için yeterlidir.

Somut örnek: Müşteri "Degraded" ile birlikte "Son başarılı senkron: 2 saat önce" ve "Son deneme: 3 dakika önce (başarısız)" görürse, sistemin denediğini ama başarılı olmadığını hemen anlar. "Sonraki planlı çalışma: 15 dakika içinde" ekleyin, bekleyip beklememeleri gerektiğini bilirler.

Aşırı paylaşmadan yardımcı olan hata detayları

Bir şey bozulduğunda müşteriler gizemli bir kod değil, net bir yanıt ister. Entegrasyon durum sayfasında, kullanıcıların ne yapabileceğini gösteren bir başlıkla başlayın. "Auth expired" veya "Permission removed" gibi ifadeler "401" yerine daha faydalıdır çünkü bir çözümü işaret eder.

Başlıktan sonra kısa bir sebep ve etki kapsamı verin. Kapsam basitçe hangi entegrasyon (örneğin "Salesforce"), hangi parçanın etkilendiği ("sadece Contacts senkronu") ve verinin gecikmeli mi yoksa eksik mi olduğu olabilir. Bu, sayfayı faydalı tutar ama teşhis konsoluna dönüştürmez.

İyi bir desen, destek ile paylaşılması güvenli küçük bir "Detaylar" görünümüdür. Bu görünüm sadece olayı tanımlamaya yardımcı olacak bilgileri içermelidir; isteği yeniden oluşturacak verileri değil.

Güvenli Detaylar görünümüne neler eklenmeli

Kısa ve tutarlı tutun:

• Hata kodu (örneğin 401, 403, 429)
• Zaman damgası (zaman dilimi ile)
• İstek ID'si veya korelasyon ID'si
• Son başarılı senkron zamanı (ilgiliyse)
• Kısa, hassas olmayan bir mesaj (bir cümle)

Gizli bilgileri sızdırabilecek her şeyden kaçının. Erişim token'ları, API anahtarları, tam header'lar veya tam istek/yanıt yükleri gösterilmemelidir. "Zararsız" görünen parçalar bile e-postalar, kayıt ID'leri veya gizli alanlar içerebilir.

Küçük örnek

Bir müşteri bir aracı disconnect edip yeniden bağladığında, sonraki çalışma süresi dolmuş bir token nedeniyle başarısız olabilir. "401 Unauthorized" yerine şöyle gösterin:

"Auth expired. We can’t refresh your connection to HubSpot, so new leads are not syncing. Details: code 401, 2026-01-25 10:42 UTC, request ID 8f2c..., last success 2026-01-25 08:10 UTC."

Bu, müşteriye güven verir ve ekibin sorunu hızlıca izleyebilmesi için yeterli bağlam sağlar; aynı zamanda aşırı paylaşım yapmaz.

Müşterinin gerçekten yapabileceği sonraki adımlar

Bir şey bozulduğunda en iyi entegrasyon durum sayfası sadece "başarısız" demez. Müşteriye şu an ne yapabileceğini ve sonrasında ne olacağını söyler.

En sık görülen üçüncü taraf API hatalarının çoğunu çözecek eylemlerle başlayın. Her buton veya yönerge özel olmalı, genel değil; ayrıca beklenen süre belirtilmelidir.

• Hesabı yeniden bağla: onları yeniden yetkilendirme akışına yönlendirin, sonra "Bağlandı"yı onaylayıp yeni bir senkronu kuyruğa alın (genellikle 1–5 dakika içinde).
• İzinleri güncelle: hangi iznin eksik olduğunu açıklayın, sonra erişimi tekrar kontrol edip son başarısız işi otomatik olarak yeniden deneyin.
• Senkronu yeniden dene: önce yalnızca başarısız adımı yeniden çalıştırın, başarılı olursa tam senkrona devam edin (tahmini zaman aralığı gösterin).
• Senkron ayarlarını değiştir: engel olan yükü azaltmak için kapsamı daraltmalarına izin verin (örneğin daha az kayıt), sonra daha sonra genişletirler.
• Hata raporu dışa aktar: dahili paylaşım için müşteri güvenli kısa bir özet indirme imkânı verin.

Her eylemden sonra açık bir sonuç gösterin: "Otomatik olarak yeniden denenecek", "Sonraki çalışma 14:00'te planlandı" veya "Sağlayıcının yanıtını bekliyoruz" gibi. Geri çekilmeli yeniden denemeler yapıyorsanız bunu sade bir dille söyleyin: "Önümüzdeki 30 dakika içinde en fazla 3 kez yeniden deneyeceğiz."

Eylem gerektirmeyen sorunlarda dürüst ve sakin olun. Örneğin: "Sağlayıcı bir kesinti yaşıyor. Değiştireceğiniz bir şey yok. Onlar toparlandığında senkron yeniden başlayacak ve 60 dakika içinde burada bir güncelleme paylaşacağız."

Destek gerektiğinde müşterilere tam olarak ne göndermeleri gerektiğini söyleyin ki sorunu hızlıca çözebilesiniz:

• Entegrasyon adı ve bağlı hesap e-postası (veya ID)
• Son başarılı senkron zamanı ve son hata zamanı
• Sayfada gösterilen hata kodu (ham log değil)
• Neye tıkladıkları ve ne olduğuna dair kısa açıklama

AppMaster ile inşa ediyorsanız, bu eylemleri hassas sağlayıcı verilerini açmadan basit backend uç noktalarına bağlayabilirsiniz.

Durum sayfasını adım adım nasıl inşa edersiniz

Durum sayfanızı küçük bir ürün özelliği gibi ele alarak başlayın; bir debug ekranı gibi değil. Eğer müşteri "Çalışıyor mu ve bir sonraki adım ne?" sorusunu cevaplayabiliyorsa, işin çoğu yapılmıştır.

Adım 1: Durumları ve kurallarını tanımlayın

Kısa bir durum seti seçin ve bunları tüm entegrasyonlarda tutarlı hale getirin. Yaygın seçimler: Healthy, Delayed, Failing, Paused. Her durumu tetikleyecek kesin kuralları yazın (örneğin "Son 3 çalışmanın hepsi hata ile sonuçlandıysa Failing" veya "6 saatte başarılı bir çalışma yoksa Delayed").

Adım 2: Doğru olayları takip edin

Sayfanız ancak sahip olduğunuz veri kadar net olabilir. Her çalışmayı, her yeniden denemeyi ve her hatayı yapılandırılmış şekilde loglayın. "Son başarılı senkron zamanı"nı ham loglardan hesaplamak yerine birinci sınıf alan yapın.

Adım 3: Basit bir düzen tasarlayın

İyi bir entegrasyon durum sayfası genelde üç bölümden oluşur: üst özet (durum + son başarı), kısa geçmiş (son çalışmaları) ve net bir eylem alanı (müşterinin şimdi ne yapabileceği). Detayları bir tık ötede tutun ki ana görünüm sakin kalsın.

Basit inşa sırası:

1. Durum modelini ve kurallarını oluşturun.
2. Çalışma geçmişini, hataları ve yeniden denemeleri kaydedin.
3. Özet, geçmiş ve eylemler UI'sını oluşturun.
4. Rol bazlı görünürlük ekleyin (admin vs görüntüleyici).
5. Gerçek hatalarla sayfayı doğrulayın.

Adım 4: Rol bazlı görünürlük ekleyin

Farklı detay seviyeleri gösterin. Görüntüleyiciler durum, zamanlama ve güvenli rehberlik görsün. Adminler hata kodlarını, başarısız uç noktaları ve yapılandırma ipuçlarını (örneğin "token süresi doldu") görebilsin.

Adım 5: Gerçek hata senaryolarıyla test edin

Sadece mutlu yol testleriyle yetinmeyin. Yaygın hataları yeniden üretin:

• Süresi dolmuş token
• Oran limiti aşımı
• Ağ zaman aşımı
• Geçersiz izinler
• Kötü veri eşlemesi

AppMaster içinde inşa ediyorsanız, tabloları Data Designer'da modelleyebilir, olayları Business Processes ile yakalayabilir ve UI'yı web veya mobil builder ile kod yazmadan bir araya getirebilirsiniz.

Sayfanın arkasında ihtiyaç duyduğunuz veri

Müşteri görünür bir entegrasyon durum sayfası, arkasındaki veri kadar iyidir. Sayfanın hızlı yüklenmesi ve tutarlı kalması için "hızlı sağlık" verilerini daha derin geçmiş ve ham loglardan ayırın.

Bir çalışma geçmişi tablosu ile başlayın. Bu tablo "son çalışma", "son başarılı" ve trend görünümleri için omurgadır. Her satır bir senkron denemesini temsil etmelidir, erken başarısız olsa bile.

Çalışma kaydını küçük ve tutarlı tutun:

• Başlangıç zamanı ve bitiş zamanı (veya süre)
• Sonuç (başarılı, kısmi, başarısız)
• İşlenen öğe sayısı (isteğe bağlı olarak başarısız öğe sayısı)
• Entegrasyon/sağlayıcı tanımlayıcısı (çoklu sağlayıcı ürünler için)
• Korelasyon ID'si (çalışmaları hatalar ve dahili loglarla ilişkilendirmek için)

Ardından normalize edilmiş bir hata kaydı saklayın. Ham stack trace'leri müşteri görünür veriye dökmeyin. Bunun yerine yapılandırılmış bir hata türü (auth, rate limit, validation, timeout), kısa bir mesaj, sağlayıcı adı, ilk oluş zamanı ve son oluş zamanı saklayın. Bu tekrar eden hataları gruplayıp "Salıdan beri hâlâ başarısız" gibi bir gösterim sağlamanıza izin verir.

Hızlı okumalar için küçük bir "entegrasyon sağlığı" modeli ekleyin. Bu müşteri ve entegrasyon başına önbelleğe alınmış bir özet gibi düşünün: güncel durum, son başarılı senkron zamanı, son çalışma zamanı ve kısa bir sebep kodu. UI önce bunu okumalı, detaylar istendiğinde çalışma geçmişini getirmelidir.

Son olarak, saklama süresini belirleyin. Müşteriler genelde neyin değiştiğini anlamak için günler veya haftalarca çalışma geçmişi ister; dahili loglar ise denetimler ve hata ayıklama için daha uzun süre tutulabilir. Müşteri görünür geçmiş için açık sınırlar belirleyin (örneğin 30–90 gün) ve ham yükleri sadece dahili depolamada tutun.

AppMaster üzerinde inşa ediyorsanız, bu modeller Data Designer tablolarına rahatça eşlenir; senkron akışınız her defasında aynı yere çalışma ve hata kayıtları yazabilir.

Yaygın hatalar ve tuzaklar

Durum sayfanız gerçeklikle uyuşuyorsa kullanışlıdır. Güveni kaybetmenin en hızlı yolu, son başarılı senkron üç gün önceyken yeşil "Her şey iyi" rozeti göstermektir. Verileriniz bayat ise bunu söyleyin ve "Son başarılı senkron"u mevcut durum kadar görünür yapın.

Diğer yaygın hata, ham hata kodlarını döküp işi bitmiş saymaktır. "401" veya "E1029" doğru olabilir ama yardımcı değildir. Müşteriler neyin bozulduğunu ve bunun neyi etkilediğini açık, insan dilinde görmek ister (örneğin "Yeni siparişler içe aktarılmayacak, mevcut siparişler etkilenmedi").

Yeniden deneme davranışı gizlendiğinde de sorun yaşanır. Sistem her 15 dakikada yeniden deniyorsa ama sayfa bunu göstermiyorsa müşteriler sürekli "Şimdi senkronla" butonuna basar, sonra işe yaramayınca destek açarlar. Yeniden denemeleri görünür yapın: sonraki planlı deneme ve manuel yeniden denemenin izin verilip verilmediği gibi bilgileri gösterin.

Bu tuzaklara dikkat edin:

• "Son zamanlarda hata yok"a dayalı yeşil durum yerine "son başarılı senkron"a dayalı yeşil durum gösterme
• Teknik hata kodlarıyla sınırlı açıklamalar, insan dilinde etki açıklaması yok
• Otomatik yeniden denemeler, backoff ya da kuyruğa alınmış çalışmalar hakkında görünürlük olmaması
• Hata detaylarının gizli bilgileri sızdırması (tokenlar, tam headerlar, müşteri verisi)
• Çok fazla durum etiketi (10+), kimsenin "engellendi" ile "gecikmiş"i ayırt edememesi

Durum etiketlerini küçük ve net tutun: Healthy, Delayed, Action required, Outage gibi. Sonra bunları bir kere tanımlayıp tutarlı kullanın.

Pratik örnek: Shopify token'ı süresi dolduysa stack trace veya token yerine "Bağlantı süresi doldu" gösterin; ne zaman bozulduğu, hangi verinin senkronlanmayacağı ve güvenli sonraki adım olarak "Hesabı yeniden bağlayın" verin. AppMaster ile inşa ediyorsanız, hata metnini kullanıcıya yönelik içerik olarak değerlendirin, ham log dökümünü değil; hassas alanları varsayılan olarak sansürleyin.

Yayına almadan önce hızlı kontrol listesi

Entegrasyon durum sayfasını yayına almadan önce, veri eksik olduğunu yeni fark eden bir müşteri rolünde hızlı bir kontrol yapın. Amaç basit: ne bozuldu, ne kadar kötü ve bir sonraki güvenli adım nedir—panik veya tahminde bulunmadan.

Üst satırdan başlayın. Durum etiketi net olmalı (Healthy, Delayed, Action required) ve her zaman son başarılı senkron zamanını içermelidir. Eğer "son başarı"yı güvenle gösteremiyorsanız müşteriler her şeyin çalışmadığını varsayar.

Sonra eylemleri kontrol edin. Yeniden bağlamak veya yeniden denemek mümkünse bunu bariz ve güvenli hale getirin. Bir admin temel bir düzeltme (hesabı yeniden yetkilendirme gibi) yapmak için destek açmak zorunda kalmamalıdır.

Yayın öncesi kontrol listesi:

• Net durum etiketi artı son başarılı senkron zamanı (ve varsa mevcut çalışma durumu)
• Admin için tek tıklamayla yeniden bağlama veya yeniden deneme yolu, ve sonrasında ne olacağına dair kısa onay
• Suçu belirten değil etkiyi açıklayan hata metni; beklentileri belirten ifade (örneğin "15 dakikada otomatik yeniden denenecek")
• Hiçbir gizli bilgi veya kişisel veri gösterilmemesi (tokenlar, tam istek yükleri, ham ID'ler yok)
• Destek ekibinin müşteri görünümünü dahili loglarla eşleştirebilmesi için korelasyon ID'si veya kısa referans kodu

Gerçek bir senaryo ile ifade testleri yapın: örneğin üçüncü taraf API oran limiti pik sırasında vurdu. Sayfa hangi verinin geciktiğini, eski verinin hala görünür olup olmadığını ve bir sonraki yeniden denemenin ne zaman planlandığını söylemeli. "Onların API'si başarısız oldu" demek yerine "Oran limitleri nedeniyle senkron duraklatıldı. 14:30 UTC'de yeniden denenecek. İşlem yapmaya gerek yok." gibi açık olun.

AppMaster ile inşa ediyorsanız, durum metnini ve eylemleri ürün akışının bir parçası olarak düşünün: müşteri sayfası, yeniden dene butonu ve dahili log referansı aynı backend durum kaydından beslenmeli ki farklılık olmasın.

Örnek: üçüncü taraf API token'ı süresi dolduğunda

Gerçek bir vaka: CRM senkronunuz, CRM yönetici ayarlarında birileri izinleri değiştirdiğinde durabilir. Uygulamanın kullandığı token hâlâ "mevcut" görünse bile ana nesnelere erişim kalmamış veya tamamen süresi dolmuştur. Sizin tarafınızdan işler hata vermeye başlar. Müşteri tarafında veriler sessizce güncellenmeyi bırakır.

Entegrasyon durum sayfanızda müşteri net, sakin bir özet görmelidir. Örneğin: Durum: Degraded (CRM senkronu duraklatıldı) ve Son başarılı senkron (örneğin "Son başarı: 25 Oca, 10:42"). Etkiyi açıklayan kısa bir satır ekleyin: "Yeni kişi ve fırsatlar bağlantı düzeltildiğinde görünmeye başlayacak."

Ayrıca hangi verinin etkilendiğini log dökmeden göstermek yardımcı olur. Basit bir "Etkilenen veriler" alanı yeterlidir: Contacts: senkronlanmıyor, Deals: senkronlanmıyor, Notes: tamam. Ürününüz birden fazla workspace veya pipeline içeriyorsa hangi alanların etkilendiğini gösterin.

Sonra muhtemel çözümle eşleşen tek önerilen eylemi verin:

• CRM hesabını yeniden bağlayın (erişimi yeniden yetkilendirin)
• Kullanıcının Contacts ve Deals'i okuma iznine sahip olduğundan emin olun
• Yeniden bağladıktan sonra yeniden denemeyi çalıştırın

Yeniden bağlandıklarında, sayfa bir sonraki tam çalışmadan önce bile hemen değişmeli. "Bağlantı geri yüklendi. Sonraki senkron 5 dakika içinde başlayacak" veya "Yeniden deneme şimdi çalışıyor" gösterin. Yeniden deneme bittiğinde uyarıyı "Senkron sağlıklı. Veri 11:08'de güncellendi." ile değiştirin.

AppMaster kullanıyorsanız, "bağlantı durumu", "son başarı" ve "sonraki çalışma"yı Data Designer'da modelleyebilir, ardından sync akışından Business Process Editor ile güncelleyerek durum sayfasının destek gerektirmeden doğru kalmasını sağlayabilirsiniz.

Ürüne uygulamak için sonraki adımlar

Hızlıca göndermek ve gerçek kullanımdan öğrenmek için küçük başlayın. Tek bakışta görünen bir durum özeti ve son başarılı senkron zamanı çoğu müşteri sorusunu hemen cevaplayacaktır. Bu güvenilir olduktan sonra, son hatalar, hangi işlemlerin yeniden denendiği ve müşterinin atabileceği adımlar gibi daha derin detayları ekleyin.

Doğruluk tasarımdan daha önemlidir. Durum sayfanız bir kere yanlış bilgi verirse müşteriler ona artık güvenmez ve tekrar destek ile iletişime geçer. Her çalışmayı açık bir sonuç (başarılı, kısmi, başarısız), zaman damgası ve stabil bir hata kategorisi ile instrument edin. Yeniden denemeleri de aynı şekilde izleyin; bir sonraki yeniden deneme ne zaman planlandıysa bunu kaydedin.

Pratik bir yol haritası:

• v1'i gönder: durum rozeti + son başarılı senkron zamanı + "X dakika önce güncellendi"
• Log ekleyin: entegrasyon başına son çalışma, son başarı, hata sayısı ve sonraki yeniden deneme zamanını saklayın
• Rehberlik ekleyin: her hata kategorisini müşteri dostu bir mesaja ve belirli bir eyleme eşleyin
• Destek ile hizalayın: destek oyun planınız ile aynı dili kullanın ki müşteri çelişkiye düşmesin
• Genişletin: temeller sağlam olduğunda kısa bir "son etkinlikler" zaman çizelgesi ekleyin

Sözlüklü ifadeleri ürün ve destek arasında tutarlı kılın. Destek "Hesabı yeniden bağlayın" diyorsa UI da aynı ifadeyi kullansın, mühendislerin kullandığı "Reauthorize OAuth" gibi teknik terimler değil. Ayrıca müşterinin bir işlem yaptıktan sonra ne olacağını gösterin: "5 dakika içinde otomatik olarak yeniden deneyeceğiz."

Ağır mühendislik olmadan inşa etmek isterseniz AppMaster gibi no-code/low-code platformları veri, mantık ve UI'yi tek yerde tutabilir. Integration ve SyncRun modellerini Data Designer'da (PostgreSQL) oluşturun, sync akışından Business Process Editor ile sonuçları kaydedin ve web UI builder ile müşteri odaklı bir sayfa inşa edin. Gereksinimler değiştiğinde AppMaster uygulamayı temiz şekilde yeniden üretir; böylece alanları ve metinleri güvenle iteratif olarak güncelleyebilirsiniz.