Müşteriler pes etmeden önce sitenizin bozuk olduğunu size bildiren rapor butonu

Salı öğleden sonra küçük bir SaaS aracını hayal edin. Bir dağıtım yapılmış, bir yapılandırma değeri yanlış girilmiş ve kayıt formu herkes için hata vermeye başlamış. Hiçbir şey gürültülü bir şekilde çökmez. Sunucu ayaktadır, ana sayfa yüklenir ve ekip zaten giriş yapmış olduğu için kontrol paneli onlara normal görünür. Üç saat boyunca, her yeni ziyaretçi çalışmayan bir formla karşılaşır, omuz silker ve ayrılır. Site sahibi o akşam durumu sadece sinirli bir tweet'ten öğrenir. Bu, web sitelerinin sessizce para kaybetme şeklidir. Dramatik bir kesinti değil, yalnızca ziyaretçilerin görebildiği ve ziyaretçilerin size neredeyse hiç söylemediği küçük bir arızadır. Birinin zaten bildiğini varsayarlar. Kendi bağlantılarından kaynaklandığını varsayarlar. Çoğunlukla, sadece yollarına devam ederler. ## Sorun: en son sizin haberiniz olur Canlı bir sitede bir şeyler bozulduğunda, bunu ilk fark edenler düzeltme yeteneği en az olan kişilerdir: ziyaretçileriniz. Onlar ile geliştiricileriniz arasında bir sürtünme duvarı vardır. Bir hatayı bildirmek için, bir ziyaretçinin normalde iletişim sayfanızı bulması, hangi e-postayı kullanacağını bulması, teknik bir sorunu kendi kelimeleriyle tanımlaması ve hangi sayfada olduğunu hatırlaması gerekir. Neredeyse hiç kimse çalışmadığı bir şirket için bunların hepsini yapmaz. Bu yüzden rapor asla gelmez. İzleme sisteminiz tam bir sunucu kesintisini yakalayabilir, ancak bozuk bir butonu, yalnızca Safari'de başarısız olan bir formu, yalnızca kupon uygulandığında hata veren bir ödeme sayfasını veya tek bir ürün sayfasında 404 hatası veren bir görseli nadiren yakalar. Bu 'kısmi' arızalar yaygındır, içeriden görünmezler ve tam olarak kayıtları ve satışları kaybetmenize mal olanlardır. Boşluk teknik değil. İnsanidir. Bir sorunu bildirmeyi o kadar kolaylaştırmalısınız ki, hafifçe sinirlenmiş bir yabancı bunu gerçekten yapsın. ## Çözüm: önceden doldurulmuş bir 'Sorun bildir' butonu Sitenize küçük, her zaman görünür bir **Sorun bildir** butonu ekleyin — altbilgide, bir köşede ve özellikle hata ile boş durum ekranlarınızda. Bir iletişim formuna yönlendirmek yerine, ziyaretçinin kendi e-posta uygulamasını mesaj zaten onlar için yazılmış olarak açan bir `mailto:` bağlantısıdır. Ziyaretçi bir kez tıklar. E-posta uygulamaları, Kime alanında geliştirici ekibiniz, net bir konu ve kısa bir şablon gövdesiyle açılır. Neyin yanlış gittiği hakkında tek bir satır yazarlar ve gönder'e basarlar. Tüm etkileşim budur — form yok, giriş yok, hesap yok. İşte butonun arkasındaki bağlantı: ```html <a href="mailto:[email protected]?subject=Site%20problem%20reported&body=What%20I%20was%20doing%3A%0AWhat%20went%20wrong%3A%0A%0APage%3A%0ABrowser%3A"> Sorun bildir </a> ``` Bu sitedeki oluşturucu (generator) bu bağlantıyı sizin için oluşturur ve kodlar, böylece başıboş bir boşluk veya parantez onu asla bozmaz. ## Rapor neleri içermeli Değer, önceden doldurulmuş gövdededir. Boş bir 'bize e-posta gönderin' bağlantısı size 'çalışmıyor' mesajını getirir. Önceden doldurulmuş bir rapor ise harekete geçebileceğiniz bir şey sağlar. Bir geliştiricinin her zaman sorduğu üç şeyi isteyin: - **Ziyaretçinin ne yaptığı** — başarısız olan işlem. - **Neyin yanlış gittiği** — hata metni veya ne görmeyi bekledikleri. - **Bağlam** — sayfanın URL'si ve ideal olarak tarayıcı ve saat. Eğer buton kendi uygulamanızın içinde bulunuyorsa, bağlamı otomatik olarak doldurabilirsiniz. Küçük bir script, mevcut URL'yi, tarayıcı bilgisini ve bir zaman damgasını e-posta açılmadan önce doğrudan gövdeye bırakabilir, böylece ziyaretçi sadece bir cümle yazar: ```html <a id="report" href="#">Sorun bildir</a> <script> const a = document.getElementById('report'); const body = 'What I was doing:\nWhat went wrong:\n\n' + 'Page: ' + location.href + '\n' + 'Browser: ' + navigator.userAgent; a.href = 'mailto:[email protected]' + '?subject=' + encodeURIComponent('Site problem: ' + document.title) + '&body=' + encodeURIComponent(body); </script> ``` Artık her rapor tam sayfa ve ortamla etiketlenmiş olarak geliyor. Geliştiriciniz çoğu zaman yanıt vermeden önce hatayı yeniden oluşturabilir. ## Beş dakikada kurulum 1. Raporları alacak adresi seçin. `dev-team@` gibi paylaşılan bir gelen kutusu veya takma ad iyi çalışır, böylece tüm ekip görebilir. 2. Oluşturucudaki bağlantıyı oluşturun: alıcıyı, 'Site problem reported' gibi net bir konuyu ve yukarıdaki üç istemi içeren kısa bir gövdeyi ayarlayın. 3. HTML parçasını kopyalayın ve altbilginize ve hata sayfanıza yapıştırın. 4. Bir uygulamanın içinde bulunuyorsa, URL'nin ve tarayıcının otomatik olarak dolması için küçük script'i ekleyin. 5. Taslağın doğru açıldığını onaylamak için kendinize bir test raporu gönderin. Arka uç yok, üçüncü taraf form hizmeti yok, yeni bir fatura yok. `mailto:` bağlantısı HTML'nin bir parçasıdır, bu nedenle statik bir sitede, açılış sayfasında, yardım masası makalesinde veya tam bir web uygulamasında çalışır. ## Size sağladığı tasarruf Tasarruf, **tespit süresindedir**. Sitenizin günde 1.000 ziyaret aldığını ve bir formun saat 14:00'te sessizce bozulduğunu varsayalım. Bir raporlama yolu olmadan, bunu o gece öğrenebilirsiniz — altı saat ve kaybedilen birkaç yüz kayıttan sonra. Tek tıklamalı bir rapor butonu ile, kafası karışan ilk ziyaretçi dakikalar içinde ekibinize haber verir. Bütün bir öğleden sonrayı kaybetmek yerine bir avuç kaydı kaybedersiniz. Aynı zamanda destek açısından da tasarruf vardır. Belirsiz 'siteniz bozuk' e-postaları, bir destek personelinin sadece hangi sayfa ve tarayıcı olduğunu araştırmak için her biri birkaç dakikasına mal olur. Önceden doldurulmuş bir rapor, bu soruları baştan yanıtlar, bu nedenle önceliklendirme dakikalardan saniyelere düşer. Ve raporlama zahmetsiz olduğu için daha fazla kişi bunu yapar — sessiz bir sorunu vahşi doğada gerçekte neyin bozulduğuna dair sürekli, dürüst bir sinyale dönüştürür. Ayrıca güveni korur. Bir aksaklığı tek bir tıklamayla bildirebilen bir ziyaretçi, bir şeyler bozulmuş olsa bile sesini duyurduğunu hisseder. Çalışmayan bir formla karşılaşan ve bunu size anlatmanın hiçbir yolu olmayan bir ziyaretçi ise sadece ayrılır ve sitenizi çalışmayan bir site olarak hatırlar. ## Daha da iyi hale getirin - Butonu, hayal kırıklığının en yüksek ve raporun en değerli olduğu **404 ve hata sayfalarınıza** koyun. - Her raporun doğru kanala yönlendirilmesi için basit bir gelen kutusu kuralı oluşturmak üzere `Site problem:` gibi bir **konu etiketi** kullanın. - Herkese açık sayfalarda adresi **gizlenmiş** tutun, böylece spam botları onu toplamasın — tıklandığında bağlantıyı birleştiren küçük bir script yeterlidir. - İnsanların butonun onlar için orada olduğunu bilmesi için görünür bir durum notu ('Sorun mu yaşıyorsunuz? Bize söyleyin') ile eşleştirin. ## Önemli çıkarımlar - Ziyaretçileriniz arızayı ilk görenlerdir, ancak neredeyse hiçbir zaman rapor etmezler — sürtünme çok yüksektir. - Önceden doldurulmuş bir `mailto:` 'Sorun bildir' butonu bu sürtünmeyi ortadan kaldırır: bir tıklama, bir cümle, gönderildi. - Her raporun yeniden oluşturulabilmesi için sayfa URL'sini ve tarayıcıyı otomatik olarak doldurun. - Arka uç veya bütçe gerektirmez ve tespit sürenizi saatlerden dakikalara indirir. Kendi rapor butonunuzu [oluşturucuda](/#generator) oluşturun veya başlamak için aşağıdaki kurulumu kopyalayın.