Canlı satış demolarında istikrarlı kalan demo ortamı kurulumu

Canlı demolar neden başarısız olur (ve genellikle neden önlenebilir)

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:

• Gerçek tut: temel iş akışı ekranları, gerçekçi kayıtlar, rol bazlı erişim
• Basitleştir: dış entegrasyonlar, uzun süren işler, uç durum ayarları
• Koruma: geri çevirilemeyecek şekilde veri değiştirebilecek her şey

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.

Ürününüz için “gerçekçi veri”nın ne anlama geldiğini tanımlayın

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.

Demo veri setinizi hikâye anlatacak şekilde planlayın

İ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:

• İki şirket: bir ücretli müşteri ve bir deneme müşterisi
• Üç rol: Admin (ayarlar), Manager (raporlar), Rep (günlük işler)
• Bir avuç aktif kayıt: 3 proje, 12 görev, 8 konuşma, 4 fatura
• Gerçekçi görünen ama güvenli bir entegrasyon ilişkili kayıt (ör. "son senkronizasyon" logu)

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.

Adım adım: üretime zarar vermeden gerçekçi veri seedleme

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.

Tekrar edilebilir kalan basit bir seed akışı

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:

• Önce birkaç şirket veya workspace oluşturun (planlar, bölgeler, ayarlar ile)
• Bu organizasyonlara bağlı kullanıcılar ve roller ekleyin
• Ürününüzün sattığı temel nesneleri ekleyin (projeler, biletler, faturalar, lead'ler vb.)
• Ekranların canlı görünmesi için aktivite ekleyin (yorumlar, durum değişiklikleri, girişler, e-posta olayları)
• Birkaç uç durum ekleyin (gecikmiş öğe, iptal edilmiş abonelik, bir boş durum)

"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.

Seed'in ne oluşturduğunu doğrulayın

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.

Sunumcunun güvenebileceği bir “Reset demo” butonu tasarlayın

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.

İşleyen iki reset deseni

Çoğu ekip sunum yapan kişiye ve zamana bağlı olarak her iki desene de ihtiyaç duyar:

• Full reset: tüm demo tenant'ını siler ve yeniden oluşturur, verileri yeniden seedler, oturumları temizler, kuyrukları boşaltır.
• Soft reset: sadece geçerli hesap veya workspace'i baseline'a geri döndürür, ortamın geri kalanını dokunulmamış bırakır.

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.

Entegrasyonları izole edin ki demonuz dış dünyaya bağlı olmasın

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.

"Demo modu" gerçek bir anahtar olsun

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:

• Harici gönderimleri (e-posta/SMS/push) engelle ve "gönderilmiş olacaktı" önizlemesi göster
• Yıkıcı eylemleri (silme, abonelik iptali, iade) devre dışı bırak veya onay kodu gerektir
• Öngörülebilir örnek yük ile anında dönen stub'lanmış webhook'lar kullan
• Yoğun demo günlerinde sağlayıcı hız sınırlamalarını tetikleyecek davranışları engelle

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."

Örnek senaryo: çok rollü bir B2B hesap demosu

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.

Üç rol, üç farklı görünüm

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.

Planlanmış bir problem ve toparlanma

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.

Demo-modu entegrasyonlar: sandbox veya stub

Ö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.

Çok kişi ve çok oturum için demo ortamını güvenli hale getirin

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.

Önceden hazırlanmış rollerle sürprizleri azaltın

İ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ı:

• Her temsilci için bir tenant (ve bir adet ortak çalışma ortamı)
• Üç demo kullanıcısı: Admin, Standard, Viewer (ön yapılandırılmış)
• Süresi dolan demo oturumları ve haftalık parola rotasyonu
• Silme ve geri alınamaz değişikliklerin engellendiği güvenli bir mod
• Her zaman temiz ve hazır bir yedek tenant

Anlık görüntüler, geri alma ve kontrollerle zamanı geçtikçe stabil tutun

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.

Hızlı geri yükleyebileceğiniz bilinen iyi bir baseline tutun

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.

Erken sorun yakalayan hafif kontroller ekleyin

Demo korumak için karmaşık bir izlemeye gerek yok. Kelime öncesi ve demo öncesi çalıştıracağınız birkaç temel kontrol ekleyin:

• Veritabanı erişilebilir ve migration'lar uygulanmış
• Arka plan işler çalışıyor
• Ana sayfalar yükleniyor (giriş, dashboard, bir temel iş akışı)
• Bir "oluştur sonra görüntüle" eylemi uçtan uca çalışıyor
• Harici çağrılar devre dışı veya stub'lanmış

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.

Satış demolarını kırılgan yapan yaygın hatalar

Ç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.

İnsanların yaptığı riskli kestirme yollar

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.

Gerçek reset olmayan sıfırlamalar

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:

• Veri sıfırlanır ama önbellekteki UI durumu, arka plan kuyrukları veya yüklemeler kalır
• Tek bir büyük demo hesabında her özellik etkin olduğu için ekranlar kalabalık ve yavaş olur
• Canlı entegrasyonlar tetiklenir ve tahmin edilemeyen yan etkiler oluşturur
• Hard-code edilmiş ID'ler artık var olmayan kayıtlara işaret eder
• Gerçek müşteri verisi sızar ve daha sonra ekran görüntülerinde veya dışa aktarımlarda görünür

Ö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.

Hızlı ön-demo kontrol listesi (5 dakika)

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.

• Demoyu taze açın ve başlangıç durumunun doğru göründüğünü onaylayın (ana ekran, örnek hesap adı, birkaç anahtar sayı "normal").
• Canlı göstereceğiniz sırayla 2–3 temel tıklamayı uçtan uca çalıştırın.
• Reset'e tıklayın ve zamanlayın. Eğer konuşma sırasında rahatça doldurabileceğinizden uzun sürüyorsa, yedek bir yol planlayın.
• Entegrasyonların sandbox'lı veya stub'lı olduğunu doğrulayın (ödemeler, e-posta, SMS, takvim, içe aktarmalar). İzole edilemeyen bir entegrasyon varsa, onu canlı hikâyeden çıkarın.
• Kullanıcı rolünün ve izinlerin sunacağınız persona ile eşleştiğini doğrulayın. Bir kısıtlı sayfayı kontrol ederek yanlışlıkla fazla göstermediğinizi onaylayı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.

Sonraki adımlar: demoyu her seferinde aynı çalışacak şekilde standartlaştırın

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.

Çoğu ekip için işe yarayan basit standart

Tek bir sahipli doküman (hatta tek sayfa) tutun ve sıkı tutun:

• Kapatmak için 3–5 demo hikâyesi ve beklenen ekranlar/sonuçlar
• Veri seedlemek için bir komut veya buton ve reset için bir buton
• Entegrasyon kuralı: canlı, mock veya demo için kapalı
• Demo ile ilgili herhangi bir değişiklikten sonra 2 dakikalık prova
• Bilinen kimlik bilgilerine sahip bir "golden" demo hesabı

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.