Dijital Ürün Teslimatı için Tekrarlanabilir Oyun Kitabı

Özet

Çoğu dijital ürün tavsiyesi tek seferlik bir lansman varsayar; bu da aynı işlemi birden fazla müşteri için yürütmeniz gerektiğinde işe yaramaz. Bu makale, stratejinin ürün olmadığını, teslimat olduğunu savunuyor. Bir teslimat spesifikasyonunu standartlaştırmayı, ödeme anını otomatikleştirmeyi ve destek ile iadeleri insani tutmayı öğreneceksiniz. Ayrıca, bir müşteri özel bir portal istediğinde nasıl geri adım atılacağını, ürün türüne göre nasıl fiyatlandırılacağını ve sürecin işe yaradığını kanıtlayan üç sayının ne olduğunu da ele alıyor. Amaç, müşterilerle temas halinde ayakta kalabilen tekrarlanabilir bir sistemdir, akıllı bir pazarlama hunisi değil. Sonunda, yarın tam olarak ne yapacağınızı bileceksiniz: spesifikasyonu yazmak.

Dijital ürün satma konusundaki çoğu tavsiye, bunu yalnızca bir kez yapacak biri için yazılmıştır. Bir platform seçin, bir dosya yükleyin, bir e-posta ekleyin ve buna lansman deyin. Aynı işlemi ikinci bir müşteri, sonra üçüncü bir müşteri için yürütmeniz gerektiği anda bu tavsiye çöker. Herkes için özel bir kurulum lüksüne sahip değilsiniz; tekrarlanabilir bir şey inşa etme yükümlülüğünüz var. Ürünün kendisi nadiren zor kısımdır. Asıl zor olan teslimattır. Ve teslimat yaratıcı bir sorun değil, bir sistem sorunudur.

MVST'nin dijital ürün iş modellerine genel bakışına göre, dijital ürünler pazarının 2027 yılına kadar 848,5 milyar dolara ulaşması öngörülüyor. Bu sayının ne kadar kesin olduğu hakkında hiçbir fikrim yok, sizin de yok. Bu sayı, bir partiye geç kalmış hissetmenizi sağlamak için var. Görmezden gelin. Önemli olan, partinin müşterilerin size yardım istemeye devam edeceği kadar büyük olması ve her işe bir kar tanesi gibi yaklaşırsanız, işin tadını çıkaramayacak kadar yorulacak olmanızdır.

Dijital ürün tavsiyelerindeki en büyük yalan nedir?

En büyük yalan, ürünün strateji olduğudur. Kârlı bir niş bulmak, mükemmel kurs taslağını tasarlamak veya tek seferlik satın almalar ile abonelikler arasında seçim yapmak hakkında çok şey duyacaksınız. Bunlar gerçek kararlar, ancak birden fazla müşteriye teslim etmek zorunda olan biri için bunlar gerçek darboğazın yukarısındadır. Darboğaz, devir teslimdir: birinin para ödemesi ile satın aldığını fiilen kullanması arasında olan şey. Otomatik bir sistem bu pencereyi saatlerden saniyelere indirebilir — ve daha da önemlisi, işleme dokunması gereken insan sayısını azaltabilir.

Yani gerçek hamle, bir müşterinin ürününe aşık olmak değil. Yeniden tasarlamadan yeniden yapılandırabileceğiniz bir teslimat mimarisi oluşturmaktır. Bu, çoğu dijital ürün tavsiyesinin eğittiği kastan farklı bir kas. Ürünler yerine ürün türlerini, özellikler yerine akışları düşünürsünüz. Bunu bu şekilde çerçevelediğinizde, bir sonraki soru açıktır.

Her müşteri farklı değil mi?

Kısmen, ama sizi inandırmak istediklerinden daha az. Bir kurs, bir şablon paketi, bir yazılım lisansı ve bir e-kitap farklı dosyalara, farklı fiyatlara ve farklı müşterilere sahiptir. Ayrıca ortak bir iskeleti paylaşırlar: satın al, teslim al, eriş, destek al. Bu iskeletle başlarsanız, kemikleri yeniden inşa etmeden ayrıntıları ayarlayabilirsiniz.

Aşağıdaki tablo kasıtlı olarak kabadır. Bu bir strateji değil; tasarıma başlamadan önce müşteri isteklerini sıralamanın bir yoludur.

Müşteri durumu	Gerçekte önemli olan	Nereye çaba harcanmalı
Tek dosya (e-kitap, PDF, şablon paketi)	Anında, kurtarılabilir indirme	Dosya depolama, indirme sayfası, basit bir lisans notu
Modüller veya damla içerikli kurs	Erişim kontrolü, ilerleme takibi	Giriş, teslimat programı, e-posta hatırlatıcıları
Yazılım veya lisans anahtarları	Anahtar oluşturma ve doğrulama	Otomatik anahtar teslimi, net bir destek yolu
Üyelik veya abonelik	Tekrarlayan erişim ve faturalandırma	Ödeme entegrasyonu, iptal işlemleri

Bir müşteri hangi satırda olduğunu söyleyemiyorsa, daha iyi bir platforma ihtiyacınız yok. Daha iyi bir konuşmaya ihtiyacınız var.

Her müşteri için farklı bir platform seçmeli miyim?

Hayır. Ve eğer buna başınızı sallıyorsanız, size bir yıllık acıdan kurtarayım. Soğukkanlılıkla bildiğiniz varsayılan bir platform, her işte yeniden öğrenmeniz gereken daha esnek bir platformdan iyidir. Müşteri hangi platformu kullandığınızı umursamaz. İndirmenin çalışmasını umursar. Bir birincil satış ortamı seçin, sınırlamalarını öğrenin ve teslimat mimarinizi bu sınırlamalar etrafında tasarlayın. Bir müşteri varsayılanın yapamayacağı bir şey istediğinde, özel bir yapım hakkında konuşmanın zamanı gelmiştir — daha önce değil.

Bu, müşterinin mevcut kurulumunu görmezden gelmeniz gerektiği anlamına gelmez. Bir fikrinizin olması gerektiği anlamına gelir. Bir müşteri zaten bir platformda olduğunu ve işleri farklı yaptığını söylüyorsa, göreviniz onların durumunu varsayılanınızla karşılaştırmaktır, onlar için tekerleği yeniden icat etmek değil. Tekrarlanabilir bir süreç, varsayılanı olan bir süreçtir.

Ya müşterinin zaten bir mağaza kurulumu varsa?

O zaman spesifikasyonunuz değişti. Sıfırdan tasarlamıyorsunuz; mevcut bir akışı denetliyorsunuz. Onlarla dört soruyu gözden geçirin: müşteri ne alır, ne zaman, nasıl ve başarısızlık durumunda ne olur. Mevcut kurulumların çoğu son soruda başarısız olur. 'İndirme bağlantısının süresi doldu' için kimsenin bir yedeği yok. Bu, tüm mağazalarını sökmeden değer katma fırsatınızdır.

Mevcut kuruluma kutsal gibi davranma cazibesine direnin. Mevcut bir mağaza sadece bir başlangıç noktasıdır. Teslimat yolu manuel ise, müşteri günde bir saat dosyaları elle gönderiyor ve size bir çözüm için ödeme yapıyor. Bunu daha fazla adım ekleyerek çözmezsiniz. Bunu, devir teslimi ödeme anına taşıyarak çözersiniz.

Bir sürecin gerçekten tekrarlanabilir olduğunu nasıl anlarım?

Yazın. Süreci bir yükleniciye on dakika içinde açıklayamıyorsanız, bir süreciniz yok, bir alışkanlığınız var. Tekrarlanabilir bir süreç, yarı yolda fikrini değiştiren bir müşteriyle temas halinde ayakta kalır ve kötü bir gününüzde sizinle temas halinde ayakta kalır.

Test basit: spesifikasyonu başka birine verip aynı çıktıyı alabilir misiniz? Bir ajans bağlamında, bu tek seferlik iş ile hizmet arasındaki farktır. Bir hizmetin tanımlı bir sınırı vardır ve sınır, stres eklemeden ölçeklenmenizi sağlar. Süreç sizin odada olmanıza bağlıysa, tekrarlanabilir değil, sadece güvenilirdir.

Önce neyi standartlaştırmalıyım?

Gerçekten kopyalayabileceğiniz şeyle başlayın: bir teslimat spesifikasyonu. Bu, sattığınız her ürün türü için müşterinin ne aldığını, ne zaman aldığını, ona nasıl eriştiğini ve nasıl yardım aldığını tanımlayan tek sayfalık bir belgedir. Kulağa sıkıcı geliyor. Sıkıcıdır. Tam da bu yüzden işe yarar.

Bir platform seçmeden önce spesifikasyonu yazın. Sonra her müşteri aynı şablonun bir varyasyonu olur. 'Müşteri ne alır? Bir PDF ve bir indirme bağlantısı. Ne zaman? Hemen. Nasıl erişir? Yalnızca onların ulaşabileceği bir sayfa aracılığıyla. Ya bozulursa? Bir destek formu.' Artık ne inşa edeceğinizi biliyorsunuz ve spesifikasyonu bir geliştiriciye, bir yükleniciye veya gelecekteki kendinize verebilirsiniz. Bunu yeniden kullanılabilir bir yapıta dönüştürme hakkında her müşteri için teslimat spesifikasyonu yazdım, ancak bugün ihtiyacınız olan versiyon sadece yukarıdaki dört sorudur.

Gerçekte neyin otomatikleştirilmesi gerekiyor?

Ödeme anını otomatikleştirin. Bir işlem tamamlandığı anda müşteri dosyayı, bağlantıyı, lisans anahtarını veya kilidi açan e-postayı almalıdır. Bu yolda hiçbir insan olmamalıdır. Otomasyon rehberleri bunun 'teslimat süresini saatlerden saniyelere düşüreceğini' vaat etmeyi sever, bu kulağa bir teknoloji broşürü gibi gelir, ancak bu durumda teknoloji gerçekten sözünü tutar. Müşteriler etkilenmek istemez; satın aldıklarını isterler.

Ancak tüm müşteri ilişkisini otomatikleştirmeyin. Devir teslimi otomatikleştirebilir, sonra konuşmayı insani tutabilirsiniz. Ayrım eski kafalı olmakla ilgili değil. Müşterinin bir insan için ödeme yapmak istememesi nedeniyle her destek talebinin soruyu yanıtlamayan otomatik bir yanıt alması durumundan kaçınmakla ilgilidir. Doğru sıra şudur: devir teslimi görünmez yapın, sonra insanı erişilebilir kılın.

Neler manuel kalmalı?

Destek, iadeler ve muhakeme. Bunlar otomatikleştirilebilecek gibi görünen ve kesinlikle otomatikleştirilmemesi gereken görevlerdir, en azından birkaç düzine gerçek işlem görmeden önce. Otomatik bir akışa gömülü bir iade politikası, bunu nasıl kullanacağını bilen müşteri için bir hediyedir. Otomatik yanıt alan bir şikayet bir duvar gibi hissettirir.

Bu, tartışmanın karşıt görüşlü kısmı: size her şeyi otomatikleştirmenizi söyleyen bir dünyada, rekabet avantajınız erişilebilir olmaktır. Satın alma sonrası saat, güvenin inşa edildiği veya yok edildiği yerdir ve bir insan o saatte herhangi bir e-posta dizisinden daha fazlasını yapabilir. Bunu yazılıma devretme isteği duyuyorsanız, devretmeden önce satın alma sonrası saat makalesini okuyun.

Müşteri 'beni hemen satışa geçir' diyor — nereden başlarım?

Bir müşteri size bu cümleyi söylediğinde, hemen tasarıma atlama dürtüsüne direnin. Üç soru sorun: Ne satıyorsunuz, nasıl teslim etmek istiyorsunuz ve biri satın aldıktan sonra ne olmalı? Cevap veremiyorlarsa, cevap verene kadar onlar için bir platform seçmeyin.

Tipik bir örnek: bir müşterinin zanaatkarlar için bir dizi SVG dosyası var. Bunları satmak istiyorlar, ancak teslimat hakkında hiçbir fikirleri yok. Bir üyelik portalına, bir mobil uygulamaya veya bir damla kampanyasına ihtiyacınız yok. Bir ödeme sayfasına, bir indirme bağlantısına ve alıcının dosyalarla neler yapabileceğini belirten küçük bir sayfaya ihtiyacınız var. Bunu inşa edin, sonra gerçek bir satın almayla test edin. Bu kadar.

Her müşteri için sıralama aynıdır: ürün türünü tanımlayın, en basit yerine getirme yolunu seçin, satın alma sonrası deneyimi haritalayın ve yolun çalışıp çalışmadığını söyleyen bir metrik ekleyin. Basit bir ürün için tüm bunları bir günde yapabilirsiniz. Platform bir ayrıntıdır.

Ya müşteri özel bir portal, bir üyelik sitesi ve bir mobil uygulama isterse?

Burası dürüst olmanız gereken yerdir, satışa mal olsa bile. Özel portallar inşa etmesi pahalı ve bakımı acı vericidir. Bunu isteyen bir müşterinin çoğu zaman buna ihtiyacı yoktur; profesyonel hissetmek için bir bahaneye ihtiyaçları vardır. Göreviniz 'bunu istiyorum'u 'buna ihtiyacım var'a çevirmektir.

Tekrarlanabilir mimari, çalışmayana kadar çalışır. Ürün gerçekten ilerleme takibi olan bir üyelik sistemi gerektiriyorsa, bunu kendi teslimat spesifikasyonuna sahip ayrı bir ürün türü olarak inşa edin. Ancak müşteri PDF satmaktan utandığı için bir mobil uygulama istiyorsa, indirme anında gerçekleştiğinde ve içerik iyi olduğunda hiçbir müşterinin bir PDF'den şikayet etmediğini hatırlatın. Tekerleği yeniden icat etmeden önce geri adım atın.

Peki fiyatlandırma?

Fiyatlandırma kendi sürecini hak eder ve bir müşterinin garip indirim alışkanlıklarının teslimat mimarinizi kirletmesine izin vermemelisiniz. Ancak teslimat spesifikasyonunuz aslında fiyatlandırma konuşmasını şekillendirir. Müşterinin ne aldığını, ne zaman aldığını ve yedeğin ne olduğunu biliyorsanız, güvenle fiyatlandırabilirsiniz — ve bir müşteriye 'marka değeri' hakkında bir hikaye uydurmadan fiyatı açıklayabilirsiniz.

Müşteriler arasında fiyatlandırmayı makul tutmanın en kolay yolu, fiyatı müşterinin coşkusuna değil ürün türüne bağlamaktır. Tek dosyalık bir şablon paketi, tam bir kurstan farklı bir fiyat aralığına sahiptir ve spesifikasyonunuz bu karşılaştırmayı doğal hale getirir. Daha derinlemesine bilgi için maksimum kâr için dijital ürün fiyatlandırma makalesine bakın.

Peki trafik ve pazarlama?

Çoğu tavsiyenin 'sosyal medyada paylaş ve umut et'e dönüştüğü yer burasıdır. Pazarlamayı başka bir tekrarlanabilir sistem olarak ele alarak daha iyisini yapabilirsiniz: sonucu açıklayan bir ürün açıklaması, bir örnek veya tanıtım ve lansmandan önce e-posta adreslerini toplamanın basit bir yolu. Viral bir huniye ihtiyacınız yok. Öngörülebilir bir huniye ihtiyacınız var.

Tuzak, her müşterinin 'marka sesinin' yepyeni bir pazarlama sürecini haklı çıkarmasına izin vermektir. Tonu ayarlayabilirsiniz, adımları değiştirmeden. Adımlar şunlardır: sorunu göster, çözümü göster, kanıt göster, satışı iste. Bu bir e-kitap, bir kurs ve bir dizi SVG dosyası için çalışır. Dramatik değildir ve markalarının nasıl ses çıkarmasını istedikleri hakkında hiçbir fikri olmayan bir müşteriyle temas halinde ayakta kalır.

Bunu bir danışman gibi görünmeden müşteriye nasıl sunarım?

Süreci bir süreç olarak sunmayın. Onu alacakları şey olarak sunun: ürünü müşteriye otomatik olarak teslim eden bir mağaza vitrini, müşterinizin hafta sonunu yemeyen bir destek yolu ve bir geliştirici gerektirmeyen bir lansman. 'Teslimat spesifikasyonu' ile başlarsanız, onları kaybedersiniz. 'Müşterileriniz ödediklerini anında alacak' ile başlarsanız, kaybetmezsiniz.

Bonus, tekrarlanabilir bir sürecin size savunulabilir bir kapsam vermesidir. Müşteri spesifikasyonun dışında bir şey istediğinde, 'bu ayrı bir ürün türü' diyebilirsiniz, 'bu çok fazla ekstra iş' yerine. İkincisi bir bahane gibi görünür. Birincisi profesyonel bir sınır gibi görünür. İkisi de hayır der; biri ilişkiyi sağlam tutar.

Ya müşterinin henüz bir ürünü yoksa?

O zaman bir teslimat projesi yapmıyorsunuz, bir ürün geliştirme projesi yapıyorsunuz. Başlamadan önce farkı netleştirin. 'Size bir kurs inşa edeceğim' demek cazip, ancak müşteri alıcının elde edeceği sonucu söyleyemiyorsa, var olmayan içerik için bir platform inşa ediyor olacaksınız.

Bu durumda, ilk adım hala bir spesifikasyondur — ancak spesifikasyon yalnızca teslimatı değil, ürünü tanımlar. Alıcı kim? Ne sorunu var? Satın aldıktan sonra ne yapabilir hale gelecekler? Bu cevaplar mevcut olduğunda, teslimat mimarisi diğer tüm ürün türleriyle aynıdır. Ürünün yokluğunun teslimatı aşırı karmaşık hale getirmek için bir bahane olmasına izin vermeyin.

Neyi ölçmeliyim?

Devir teslimi ölçün. Spesifik olarak, ödeme ile müşterinin yararlı bir şeye sahip olması arasındaki süreyi, satın almaların başarılı indirmelere oranını ve iade taleplerinin oranını ölçün. Bu üç sayı, teslimat sisteminin sağlıklı olup olmadığını söyler. Kimsenin okumadığı raporlar üretmek için para almıyorsanız, sayfa görüntüleme, gösterim veya 'etkileşim' ile dikkatinizi dağıtmayın.

Devir teslim süresi sürekli kısa olduğunda, iadelerin düştüğünü ve destek taleplerinin daha az tuhaf hale geldiğini göreceksiniz. Bu bir istatistik yığını değil; insanlar ödediklerini aldıklarında olan şeydir. Bunun için bir kontrol paneline ihtiyacınız yok. Devir teslimi izlemeniz gerekiyor.

Yarın yapmanız gereken tek şey nedir?

Teslimat spesifikasyonunu yazın. Yarın değil — bu öğleden sonra. Büyük olasılıkla bir sonraki satacağınız ürün türünü alın, boş bir belge açın ve dört soruyu yanıtlayın: ne, ne zaman, nasıl ve ya bozulursa. Bu tek yapıt, herhangi bir yeni platform özelliğinden daha değerlidir.

Dijital ürün tavsiyelerindeki diğer her şey çoğunlukla gürültüdür. Pazar büyük, abartı yüksek ve araçlar her çeyrekte isim değiştiriyor. Ayakta kalan şey, 'Müşteri X bir şey satmak istiyor' ifadesini önceden düşünülmüş tekrarlanabilir bir cevaba dönüştüren bir süreçtir. Bunu bir kez inşa edin ve zamanınızı satmayı bırakırsınız. Sistemi satmaya başlarsınız.