10 Eki 2025·7 dk
Canlı satış demolarında istikrarlı kalan demo ortamı kurulumu
Satış ekipleri için demo ortamı önerileri: gerçekçi veri seedleyin, bir sıfırlama butonu ekleyin ve entegrasyonları izole edin ki demolar güvenilir kalsın.
Satış ekipleri için demo ortamı önerileri: gerçekçi veri seedleyin, bir sıfırlama butonu ekleyin ve entegrasyonları izole edin ki demolar güvenilir kalsın.
Canlı demolar genellikle ürünün “kararsız” olmasından değil, sıkıcı nedenlerden dolayı başarısız olur. Çoğu ekip, zamanla sessizce sürüklenen bir ortamı demo ediyor.
En yaygın neden eski veya dağınık veridir. Birisi önemli bir kaydı siler, deneme hesabının süresi dolar veya geçen haftanın testleri yarım kalmış nesneler bırakır. Hikâye "Acme hesabını aç ve Orders'a tıkla"ya dayanıyorsa, eksik veriler kendinden emin akışı garip aramalara dönüştürür.
Bir diğer büyük neden entegrasyonlardır. Gerçek e-posta gönderimi, gerçek ödeme sağlayıcıları veya üçüncü taraf bir API'ye bağlı demolar en kötü anda bozulabilir: hız sınırlamaları, ağ kopmaları, süresi dolmuş tokenlar veya sandbox arızası. Daha da kötüsü, gerçek kişilere gerçek mesajlar gönderebilir.
İzinler ise sessiz katildir. Admin hesabı çalışır, fakat “manager” rolü birdenbire göstermek istediğiniz sayfayı göremez veya bir özellik kapalıdır. Gösterilecek olanı anlatmak zorunda kalırsınız, olanı değil.
Kötü bir demo birkaç dakikadan fazlasına mal olur. Güveni yakar. Potansiyel müşteriler satın aldıktan sonra başka neyin arızalanacağını merak etmeye başlar ve ekibiniz çağrı sırasında toparlanmaya çalışırken ivme kaybeder.
İyi bir demo ortamı tekrarlanabilir, öngörülebilir ve tıklamaya karşı güvenli olmalıdır. Biri yanlış düğmeye bassın, toparlanma hızlı olmalıdır.
Bunun başlangıcı kapsam belirlemektir. Bazı şeyler gerçek görünmelidir: isimler, tarihler, toplamlar, roller ve inandırıcı bir iş yükü. Diğer şeyler bilinçli olarak basitleştirilmelidir: sahte e-posta gönderimi, mocklanmış ödeme başarıları, örnek analizler.
Sınırı çizmenin basit bir yolu:
B2B bir uygulama demo ediyorsanız, gerçek görünümlü faturalar ve aktivite geçmişi gösterebilirsiniz, ama "Fatura e-postası gönder" işlemi gerçek posta göndermek yerine demo bir çıkış kutusuna (outbox) yazmalı.
Snapshot ve rollback destekleyen bir platform kullanıyorsanız, demoyu talep üzerine sıfırlanabilecek bir şey gibi ele alın. Örneğin Koder.ai snapshot ve rollback içerir; bu, birinin beklenmedik şekilde tıklaması sonrası bilinen bir duruma dönmeyi kolaylaştırır.
Gerçekçi veri "çok fazla satır" değildir. Ürünü canlı hissettiren ve alıcının tıklamasını beklediği küçük kayıt kümesidir.
Çoğu alıcı, bunun gerçek bir iş akışı olduğunu gösteren birkaç sinyal arar: tanıdık isimler (User 1, User 2 değil), anlamlı tarihler, UI'ı değiştiren statüler ve görünüşün neden öyle olduğunu açıklayan aktivite geçmişi. Ayrıca toplamların uyuşmadığını, rollup'ların tutmadığını veya boş görünen bir grafiği hemen fark ederler.
Sonra 2–3 hikâye seçin ve veri setini bunlara göre şekillendirin. B2B ürünleri için bu genellikle onboarding (ilk proje oluşturma), raporlama (eğilimler gösteren bir dashboard) ve onay süreçleridir (bir isteğin roller arasında ilerlemesi). Her hikâye 2–4 dakikada tamamlanabilir olmalı, çıkmaz yol olmamalı.
Sıfırlamalar arasında hangi şeylerin sabit kalması gerektiğine karar verin. Arayüz "Hesap Kimliği", e-postalar veya aylık toplamlar gösteriyorsa, ekran görüntüleri, betikler ve konuşma metinleri farklılaşmasın diye bunları sabit tutun. Tutarlılık ayrıca ortamın beklenen duruma geri döndüğünü doğrulamayı kolaylaştırır.
Son olarak, kırmızı çizgiler belirleyin. Gerçek müşteri verilerini, gerçek ödeme bilgilerini veya PII gibi karıştırılabilecek herhangi bir şeyi asla kullanmayın. Bariz sahte domainler, üretilmiş isimler ve yalnızca test kart numaraları kullanın.
Demo uygulamanızı Koder.ai üzerinde inşa ediyorsanız, seed verisini uygulama spesifikasyonunun bir parçası gibi ele almak yardımcı olur: önce hikâyeleri tanımlayın, sonra veriyi ve ekranları onlara göre üretin.
İyi bir demo veri seti küçük, tamamlanmış ve öngörülebilirdir. Amaç her özelliği göstermek değil. Amaç, her ekranın bakılacak anlamlı bir şey olduğu basit bir hikâye boyunca birini yönlendirmektir.
Başlangıçta ürününüzün en küçük "tam" modelini seçin. Bu genellikle tek bir hesap ve çoğu ekranı etkileyen birkaç ana nesneyi (örneğin: kullanıcılar, müşteriler, projeler, faturalar, mesajlar) içerir. Bu, etrafta atladığınızda demoyu tutarlı tutar.
Veriye bir oyuncu kadrosu verin. Birkaç inandırıcı şirket ve persona oluşturun, sonra bunları gerçek müşterilerin birbirleriyle bağlandığı şekilde ilişkilendirin.
Pratik bir örnek:
Zaman çizelgesini güncel hissettirin. Her şeyin "6 ay önce" olduğunda insanlar hemen fark eder. Seed sırasında göreli zaman damgaları (ör. "şimdi eksi 3 gün") saklayın ki etkinlikler her zaman yakın görünsün: son 24 saatte etkinlik, son 7 günde kayıtlar, son 30 gündeki eğilimler gibi.
Birkaç uç durumu kasıtlı bırakın, ama temada sadece bir taneyle sınırlayın. Bir gecikmiş fatura uyarıların nasıl çalıştığını gösterir. Başarısız bir senkronizasyon hataların nasıl ele alındığını gösterir. Bir boş durum (ör. "henüz kaydedilmiş filtre yok") ürünün temiz başladığını kanıtlar.
Güvenli bir demo ortamının bir kuralı vardır: demo veriniz asla üretimle aynı veritabanını, API anahtarlarını veya admin erişimini paylaşmamalıdır. Demoyu kendi sınırları olan ayrı bir ürün gibi ele alın.
Bilinen bir başlangıç noktasından başlayın. Bu boş bir veritabanı veya güvendiğiniz bir snapshot olabilir, ama her zaman aynı temel olmalıdır.
Sonra ilişkiler mantıklı olacak şekilde veri katmanlarını oluşturun. Pratik bir sıra:
"Gerçekçi" değerler üretirken rastgelelikten ziyade inanılır desenler hedefleyin. Sahte isimler ve domainler kullanın, sayıları normal aralıkta tutun ve hikâye anlatan zaman damgaları ayarlayın. Bu, bir dashboard'un %0 dönüşüm göstermesi veya gelecekteki tarihler içermesi gibi garip anları önler.
Canlı olarak göstereceğiniz birkaç ekran üzerinde hızlı bir kontrol yapın. Toplamların eşleştiğini, grafiklerin ilginç olacak kadar nokta içerdiğini ve herhangi bir "ilk 5" widget'ının tam beş öğe gösterdiğini kontrol edin.
Seed sürecini saklayın ki herkes aynı script'i yeniden çalıştırabilsin. Script, konfigürasyon ve beklenen sonuçları birlikte tutun (ör. "Org A'nın 12 ticket, 3 gecikmiş olmalı"). Snapshot ve rollback'e güveniyorsanız (Koder.ai dahil), yeniden seedlemeden önce baseline'a geri dönebilir ve ertesi gün aynı demoyu sürpriz olmadan tekrarlayabilirsiniz.
Sıfırlama butonu "bazı satırları silmek" değildir. Canlı bir satış demo ortamında reset, ürünü bilinen iyi bir hikâyeye geri koymalıdır: aynı hesaplar, aynı örnek etkinlikler, aynı izinler ve sunumcunun beklediği aynı UI durumu.
Önce demo için "temiz" olanın ne anlama geldiğini yazın. Genelde veri (kayıtlar), oturumlar (kim giriş yapmış) ve UI durumu (seçilmiş workspace, onboarding banner'ları, filtreler, turlar) dahildir. Bunlardan biri kirli kalırsa bir sonraki demo rastgele veya bozuk görünebilir.
Çoğu ekip sunum yapan kişiye ve zamana bağlı olarak her iki desene de ihtiyaç duyar:
Soft reset birden çok temsilcinin aynı demo ortamını paylaştığı durumlarda iyidir. Full reset ise kritik çağrılardan önce en güvenli seçenektir.
Reset'i görünür ama korumalı yapın. Butonu sunumcunun hızlı bulabileceği bir yere koyun, ardından onay adımı, rol kontrolü (ör. sadece "Demo Admin") ve "Reset Sam tarafından 10:14'te tetiklendi" gibi basit bir denetim notu ile koruyun. Bu audit izi, "Kim oturumumu sıfırladı?" sorusuna cevap verir.
Bir hedef zaman belirleyin ve geriye doğru çalışın. 60 saniyenin altında hedefleyin. Buna ulaşmak için seed verisini küçük ama anlamlı tutun ve uzun beklemelere zorlayacak şeylerden kaçının.
Veri dışı kalanları unutmayın. Reset dosya yüklemelerini, bildirimleri, arka plan işlerini ve planlanmış e-postaları temizlemeli. Demo "fatura PDF'leri" gösteriyorsa eski yüklemelerin kaybolduğundan ve bir sonraki aramaya sızmadığından emin olun.
Bir demo kusursuz görünebilir ama kontrolünüz dışındaki bir şey değiştiğinde yine başarısız olabilir: webhook yavaşlar, e-posta sağlayıcısı gönderimi engeller veya ödeme sandbox'ı devre dışı kalır. Kararlı bir demo her entegrasyonu isteğe bağlı kabul eder, hatta gerçek ürün onlara bağımlı olsa bile.
Gönderebilen veya ücretlendirebilen her şey için sandbox hesapları kullanın: e-posta, SMS, ödemeler, haritalar, AI sağlayıcıları. Sandbox anahtarlarını üretimden ayrı tutun ve aceleyle yanlış token kopyalanmaması için açıkça etiketleyin.
Güvenli varsayılanlarla bir demo-modu toggle'ı (özellik bayrağı) ekleyin. UI ve loglarda kolayca fark edilir olsun ki çağrı sırasında davranışı açıklayabilesiniz.
Demo modunda varsayılanlar genelde şöyle görünür:
Kırılgan bağımlılıklar için, sağlayıcının ayakta kalmasına güvenmek yerine stub veya mock kullanın. Uygulamanız normalde bir webhooks bekleyip ödemeyi onaylıyorsa, demo modunda aynı ekranları gösterirken "ödenmiş" olayını simüle ederek anında kabul edebilirsiniz.
Her entegrasyon çağrısını düz İngilizce bir çıktı ile kaydedin: "SMS engellendi (demo modu)" veya "Ödeme simüle edildi."
Mid-size bir şirket olan Northwind Tools'un ürününüzü değerlendirdiğini hayal edin. Demoya zaten aktif görünen tek bir hesapla başlarsınız: gerçek müşteri isimleri ("Test 1" değil), birkaç açık görev, geçen haftadan etkinlik ve küçük bir dikkat gerektiren sorun.
Admin olarak başlayın. Admin faturalamayı, kullanıcı yönetimini ve "API anahtarı döndü" veya "Çeyreklik rapor dışa aktarıldı" gibi inandırıcı olayları gösteren denetim günlüğünü görür. 8–12 karma statülü kullanıcı ekleyin: yakın zamanda davet edilmiş bir kullanıcı, devre dışı bırakılmış bir kullanıcı ve farklı erişim kurallarına sahip iki ekip.
Manager'a geçin. Manager, üzerinde çalışılan işleri gösteren bir dashboard ile karşılaşır: 6 fırsatlı pipeline, 2 gecikmiş takip ve bir büyük yenileme. Manager düzenleyebilir, atayabilir ve onaylayabilir.
Son olarak Viewer'a geçin. Viewer yalnızca okuma yetkisine sahiptir. Kayıtları ve yorumları açabilir, ancak "Sil", "Planı değiştir" veya "Tümünü dışa aktar" gibi işlemler devre dışıdır. Bu rol, ürünün varsayılan olarak güvenli olduğunu göstermeye yardımcı olur.
Yarısında bilinçli olarak önceden bilinen bir hata durumu tetikleyin: Manager bir kaydı senkronize etmeye çalışır ve "Harici senkronizasyon geçici olarak kullanılamıyor" hatası alır. Bu sürpriz bir başarısızlık olmamalı. Bu, dayanıklılığı gösteren senaryolaştırılmış bir andır.
Sonra önemli olanı gösterin: UI sorunu açıkça anlatır, demo gerçek zarara sebep olmaz (tekrar eden kayıtlar veya kısmi yazmalar yok), Admin güvenli bir şekilde yeniden deneyebilir ve tek tıklamayla reset her şeyi başlangıca döndürebilir.
Ödemeler sandbox ortamında çalışır. E-posta ve SMS stub'lanmıştır, böylece uygulama içinde "Gönderildi" mesajlarını kimseye temas etmeden gösterebilirsiniz. Webhook'lar demo inbox'una yakalanır.
Demo paylaşılan bir oyun alanı haline geldiğinde risk artar. İki temsilci (veya iki potansiyel müşteri) aynı hesabı kullanırsa, bir tıklama herkesin hikâyesini değiştirebilir. En basit çözüm, her demoyu kendi tenant'ı, verisi, ayarları ve kullanıcıları olan ayrı bir tenant olarak ele almaktır.
Her temsilciye adanmış bir demo tenant verin (veya her aktif anlaşma için bir tane). Gün içinde birkaç demo çalıştırmanız gerekiyorsa Demo-01, Demo-02, Demo-03 gibi küçük bir havuz tutun ve takvime göre atayın. Demo bittikten sonra o tenant'ı bilinen bir duruma resetleyin.
Kimlik bilgileri çağrıda yazması kolay ama dikkatsiz olmamalı. Hiç değişmeyen paylaşılan parolalardan kaçının. Kısa ömürlü erişim (süresi dolan oturumlar) kullanın, demo parolalarını düzenli döngüde değiştirin ve potansiyel müşteriler için ayrı bir viewer oturumu bulundurun.
İzin bulmacaları ivmeyi öldürür. Göstermeyi planladığınız tam rolleri oluşturun ve script ile aynı isimleri kullanın (Admin, Manager, Read-only). Her rolün temiz bir dashboard ile, doğru kaydedilmiş filtreler ve örnek kayıtlarla açıldığından emin olun.
Canlıya geçmeden önce eş zamanlılığı test edin: iki kişi aynı anda Approve'a tıklarsa ne olur, veya aynı kaydı iki kişi aynı anda düzenlerse? Demolar için genellikle yıkıcı eylemleri engellemek veya copy-on-write yapmak (eylem paylaşılan öğeyi değiştirmek yerine yeni bir örnek oluşturur) daha iyidir.
Pratik bir yapı:
Demo ortamları çoğunlukla yavaş sürüklenme yüzünden bozulur. Birisi bir kaydı düzenler, bir arka plan işi takılır, yeni bir sürüm iş akışını değiştirir ve "bilinen iyi" hikâye kaybolur.
En iyi demo durumunuzu altın bir imaj gibi ele alın. Veri seedledikten ve tüm tıklama yolunu doğruladıktan sonra geri yükleyebileceğiniz bir snapshot alın.
Sürüklenmeyi önlemek için otomatik sıfırlamalar planlayın. Çoğu ekip için gece sıfırlamaları yeterlidir, ancak aynı ortamı birçok kişi kullanıyorsa saatlik sıfırlamalar daha iyi olabilir.
Basit bir kural işe yarar: sıfırlama bir kahve molasından uzun sürüyorsa, demo güvenli değildir.
Demo korumak için karmaşık bir izlemeye gerek yok. Kelime öncesi ve demo öncesi çalıştıracağınız birkaç temel kontrol ekleyin:
Demo veri seedleri ve demo script'ini sürüm kontrolünde tutun, ürün değişikliklerini aynı şekilde izleyin. Bir ürün değişikliği geldiğinde seed ve script'i aynı pull request içinde güncelleyin ki uyum korunmuş olsun.
Ayrıca demo sürüm takvimini hızlı geliştirilen yapıların takviminden ayırmayı düşünün. Demo-safe bir build'i öngörülebilir bir programda, kontrolleri geçtiğinde promote edin; böylece satış ekibinizin güvendiği yol aniden bozulmaz.
Çoğu demo başarısızlığı şans eseri değildir. Demo ortamı yarı-test yarı-prod gibi davranan, gizli durumlar ve bağımlılıklar barındıran bir sistem olduğunda meydana gelir. Sağlam bir kurulum sürprizleri ortadan kaldırır ve demoyu tekrarlanabilir kılar.
En hızlı şekilde utanç verici duruma düşmenin yollarından biri gerçek müşteri verilerini "sadece demo için" kullanmaktır. Bu özel bilgileri açığa çıkarabilir ve anlamadığınız uç durumları ortaya çıkarır. Daha güvenli yaklaşım, yeterince gerçekçi görünen sentetik veri kullanmaktır: inandırıcı isimler, gerçekçi tarihler ve ürününüzün beklediği desenler.
Bir diğer tuzak demo ID'lerini hard-code etmektir. Bir satış script'i "Hesap #123" veya "Proje ABC" üzerine dayanır, sonra seed değişir, bir reset çalışır veya bir migration kayıt numaralarını değiştirir. Aniden butonunuz boş bir sayfa açar. Demo akışınız belirli bir kayda ihtiyaç duyuyorsa, veritabanı ID'si yerine kararlı bir anahtar veya etiketle referans verin.
Entegrasyonlar da sessiz kaos kaynağıdır. Demo canlı e-posta, ödeme veya CRM API'lerini çağırıyorsa her şey olabilir: hız sınırları, süresi dolmuş tokenlar, gerçek mesajların gitmesi veya beklenmedik webhook'ların veriyi orta demo değiş tokuş etmesi.
Pek çok "Reset demo" özelliği yalnızca tabloları siler ama UI durumunu, arka plan kuyruklarını veya yüklenen dosyaları bırakır. Bu yüzden demo sıfırlanmış görünür ama yanlış davranır.
Alıcıların göreceği yaygın başarısızlıklar:
Örnek: "demo şirketi"ni sıfırlarsınız ve dashboard temiz görünür, ama arka plan kuyrukları hala eski bildirimleri gönderir. Bir alıcı aniden neden beş bildirim aldığını sorar. Eğer snapshot ve rollback kullanıyorsanız (Koder.ai dahil), reset'i "snapshot'a dön" olarak ele alın: veri, dosyalar ve işler bilinen bir duruma geri gelmelidir.
Stabil bir demo kusursuzlukla ilgili değil. Her seferinde aynı temiz yerden başlamayla ilgilidir, böylece konuşmaya odaklanabilirsiniz.
Bunu çağrıdan 5 dakika önce yapın, izlenirken değil. Demoyu özel bir pencerede (veya ayrı bir tarayıcı profili) açın ki önbelleğe alınmış oturumlar ve eski girişler sizi şaşırtmasın.
Eğer bir şey başarısız olursa, ummayın düzelecek. Hemen yedek yola geçin. E-posta gönderimi bugün sorunluysa, Canlı Gönder butonuna basmak yerine sıradaki mesajı ve zaman çizelgesini gösterin.
Bir ipucu daha: tek bir bilinen iyi demo hesap adını yazılı tutun (ve ona bağlı kalın). Baskı altında tutarlılık yaratıcılıktan üstündür.
Demo, küçük bir tekrar edilebilir hikâye seti etrafında kurulduğunda stabil kalır. Kapatmak için gerekli en az hikâyeyi seçin ve her şeyi bu anlara göre tasarlayın. Hikâyeleriniz için gerekli olmayan her şeyi demo ortamından çıkarın.
Hikâyelerinizi kısa scriptler olarak yazın: net bir başlangıç ve bitiş durumu olsun. Örnek: "Admin olarak giriş yap, bir takım arkadaşını davet et, bir proje oluştur, bir rapor çalıştır, sonra takım arkadaşı görünümüne geçip onayla." Bu size seedlenecek somut bir veri seti ve net bir reset noktası verir.
İnsanların unuttuğu kısımları otomatikleştirin. Bir ekip üyesi demoyu farklı çalıştırdığında ortam sürüklenir ve sonraki demo garipleşir.
Tek bir sahipli doküman (hatta tek sayfa) tutun ve sıkı tutun:
Bir değişiklik kuralı belirleyin ve uygulayın: bir değişiklik demo yolunu etkiliyorsa, yayınlanmadan önce demo ortamında hızlı bir prova yapılmalı. Bu, alan adının yeniden adlandırılması, izin eksikliği veya yeni bir onboarding adımı gibi sürprizleri önler.
Hızlı bir demo uygulaması oluşturuyorsanız, Koder.ai gibi sohbet tabanlı bir oluşturucu pratik olabilir: istemlerden web, backend veya mobil uygulamalar oluşturabilir, kaynak kodu dışa aktarabilir ve planning mode ile snapshot/rollback kullanarak demoyu tutarlı tutabilirsiniz.
Amaç mükemmel bir ortam değildir. Amaç her seferinde aynı başlayan, aynı hikâyeyi anlatan ve aynı şekilde biten bir ortam yapmaktır.
Çoğu canlı demo ortamı zaman içinde sürüklenme (drift) yaşadığı için başarısız olur. Veriler düzenlenir veya silinir, tokenlar süresi dolar, entegrasyonlar aksar veya izinler değişir; planladığınız tıklama yolu artık ekrandakiyle eşleşmez.
İş akışını canlı hissettiren en küçük veri kümesini hedefleyin. İnandırıcı isimler, güncel etkinlik ve UI'ı değiştiren durumlar kullanın; toplamların ve rollup'ların eşleştiğinden emin olun, böylece çağrı sırasında hiçbir şey "garip" görünmez.
Göstermek istediğiniz 2–3 kısa hikâyeyi seçin ve her hikâyeyi tamamlamak için gereken kayıtları seed edin; çıkmaz bir yola girmesinler. Sıfırlamalar arasında konuşma metninizin ve ekran görüntülerinizin kaymaması için ana hesap adlarını ve anahtar tanımlayıcıları sabit tutun.
Üretim veritabanını, API anahtarlarını veya yönetici erişimini asla paylaşmayın. Ayrı bir demo ortamı oluşturun, sahte isimler ve sahte domainler kullanarak sentetik veri üretin ve seed sürecini herkesin aynı başlangıç durumunu yeniden oluşturabileceği şekilde saklayın.
Bilinen bir başlangıç noktasından başlayın, sonra gösteri sırasında kullanacağınız birkaç ekrana bakarak doğrulayın. Ana widget'ların anlamlı değerler gösterdiğini, grafiklerin yeterli veri noktasına sahip olduğunu ve rol bazlı görünümlerin beklediğiniz gibi davrandığını kontrol edin.
Güvenilir bir sıfırlama, sadece bazı tablaları silmek değil, tüm demo hikâyesini geri getirmelidir: aynı hesaplar, aynı örnek etkinlikler, aynı izinler ve sunucunun beklenen UI durumuyla başlamalıdır.
Birden fazla temsilci aynı ortamı paylaşıyorsa ve sadece bir workspace/hesabı geri almak istiyorsanız soft reset kullanın. Yüksek riskli bir görüş öncesi her şeyi sıfırdan temizlemek istiyorsanız full reset tercih edin.
Demo sırasında entegrasyonları isteğe bağlı hale getirin. Gönderimleri engelleyin ve "gönderilmiş olacaktı" önizlemesi gösterin, kırılgan webhook'ları stub'layın ve ödemeler gibi kritik işlemler için sandbox hesapları kullanın.
Her temsilciye kendi demo tenant'ını verin veya küçük bir tenant havuzu oluşturun; her demo sonrası o tenant'ı resetleyin. Kısa ömürlü oturumlar, düzenli parola rotasyonu ve ayrı viewer girişleri kullanarak bir kişinin tıklamaları diğerinin demosunu bozmasın.
Onaylanmış "golden" demo durumunun bir anlık görüntüsünü (snapshot) alın ve planlı aralıklarla veya gerektiğinde ona geri dönün. Koder.ai gibi platformlar snapshot ve rollback destekliyorsa, beklenmedik tıklamalardan sonra hızlıca bilinen bir duruma dönebilirsiniz.