Ağır CRM yükü olmadan Taslak'tan Kazanıldı/Kaybedildiye kadar teklifleri takip etmek, durum bazlı hatırlatmalar tetiklemek ve hizmet türüne göre kapanış oranlarını ölçmek için bir teklif hattı uygulaması oluşturun.
Çoğu serbest çalışan teklifleri işin zayıf olmasından kaybetmez. Kaybederler çünkü teklif ortadan kaybolur.
Alışılmış dağınıklık şöyle görünür: bir taslak dokümanda, son PDF bir klasörde, son müşteri mesajı e-postada veya sohbette gömülü ve tek “durum” sizin hatırladığınız şeydir. Müşteri iş teslimatlarıyla meşgulken, kimin bir teklifi beklediğini ve kime ikinci bir hatırlatma gerektiğini unutmak çok kolaydır.
Teklifler şu yerlere saçılır:
Teklifler tek bir sebepten kayar: bir sonraki aksiyonu gösteren tek bir yer yok. Eğer 10 saniyede “Bir sonraki ne yapmalıyım ve hangi müşteri için?” sorusuna cevap veremiyorsanız, takipler gecikir. Geciken takipler, müşteri ilgili olsa bile kaybedilmiş anlaşmalara dönüşür.
Boru hattı, sade tabiriyle budur: her teklifin nerede olduğunu ve bir sonraki adımın ne olması gerektiğini gösteren küçük bir durum seti. Bir teklif hattı uygulaması süslü bir satış makinesi değildir. Hem skor tablosu, hem yapılacaklar listesi gibidir.
Beklentileri gerçekçi tutun. Tahminleme, bölge yönetimi ve asla okumayacağınız raporlarla dolu karmaşık bir CRM inşa etmiyorsunuz. Gerçekte nasıl çalıştığınıza uyan, “bir sonraki adımı” bariz kılan hafif bir araç istiyorsunuz.
Bunun önlediği şey şöyle: Salı günü bir web tasarımı teklifi gönderip Cuma takip edeceğinizi söylersiniz. Cuma işlerle dolu olur. Pazartesiye geldiğinizde zaten kontrol edip etmediğinizi hatırlayamazsınız. Bir görünür “Müşteri bekleniyor” aşaması ve net bir sonraki takip tarihi olan küçük bir pipeline bu sessiz kaybı durdurur.
Bir teklif hattı uygulamasının işi nettir: her teklifi mümkün olan en az eforla Taslaktan Kazanıldı veya Kaybedildiye doğru ilerletmek. Eğer ekstra idari iş yaratırsa, ihtiyaç duyduğunuz anda kullanmayı bırakırsınız.
Bir şey tasarlamadan önce, aylar sonra bile bir teklif hakkında ne bilmeniz gerektiğine karar verin. Takip etmenize, gelir tahmini yapmanıza ve neyin sattığını öğrenmenize yardımcı olan birkaç detaya indirgeyin.
Pratik bir minimum her teklif için:
Sonra "bitti"nin ne anlama geldiğini tanımlayın ki uygulama güvenilir kalsın. Bir teklif Sonsuza kadar Gönderildi halinde kalmamalı. "Bitti", duraklayan öğelerin hatırlatmaları tetiklemesi, geri dönüş alındığında sonuçların kaydedilmesi ve dışa aktarmadan basit raporlama görebilmeniz demektir.
Başlangıçta kapsamı küçük tutun. Tek kullanıcı, tek çalışma alanı ve basit alanlar, sürdürülemeyen büyük bir sistemden daha iyidir. Bu hafta üç teklif gönderirseniz (ikisi "landing page + metin", biri "retainer destek" için), bir sonraki takip tarihini ve bir sonucu zorlayan bir pipeline hangi hizmetin daha sık kapandığını ve nerede zaman kaybettiğinizi çabucak gösterir.
Durumlar yalnızca gerçek gününüzü yansıtıyorsa yardımcı olur, izlemediğiniz ideal bir süreci değil. Kartı ileri taşımak zahmetsiz hissetmeli; bu yüzden seti küçük tutun.
Pratik bir set:
İsimleri kısa ve eylem odaklı tutun. Bir duruma bakınca ne yapmanız gerektiğini söyleyemiyorsanız, adını değiştirin.
Sonra hiçbir şeyin zombi projeye dönüşmemesi için birkaç basit kural koyun.
Örneğin:
Takip tarihleri diğer koruyucu hattır. Her durum hatırlatma gerektirmeyebilir, ama bazıları gerektirir. Sağlam bir varsayılan: Gönderildi ve Takip zamanı için bir sonraki takip tarihi olmalı. Müzakere de gerektirebilir, ama yalnızca sonraki adım sizin üzerinizdeyse.
Kısa bir senaryo: Pazartesi bir web tasarımı teklifi gönderirsiniz. Perşembe’ye kadar haber alamazsanız, teklif Takip zamanı olarak görünür. Müşteri "blogu kaldıralım ve fiyatı düşürelim" diye yanıt verirse, onu Müzakereye taşıyıp bir sonraki takibi ertesi güne ayarlarsınız. Bu, iş akışınızı kağıt işine çevirmeden ivmeyi korumak için yeterli yapıdır.
Bir teklif hattı uygulaması veriye bağlıdır. Yapı çok gevşekse alanları atlayarsınız. Çok sıkıysa kullanmayı bırakırsınız. Güvenebileceğiniz küçük bir kayıt seti hedefleyin, sonra gerçek ihtiyaç hissettiğinizde ayrıntı ekleyin.
Dört temel nesneyle başlayın: Müşteriler, Teklifler, Hizmetler ve Aktiviteler.
İlk versiyonu basit tutun:
Teklifler için sonraki_takip_tarihi gelecekteki kendinizin güvenlik ağıdır. sonuc_sebebi, Kazanıldı veya Kaybedildi işaretlendiğinde önemlidir; çünkü "Kaybedildi: çok pahalı" ile "Kaybedildi: zamanlama" farklı düzeltmeler gerektirir.
Tek teklif başına bir hizmet türü en hızlı kurulumdur ve net paketler satıyorsanız işe yarar. Birden fazla hizmet, pakette işliyorsanız daha iyidir (tasarım + geliştirme + bakım gibi), ama karmaşıklık ekler. Bir ilişki tablosu (ör. ProposalServices) gerekir ve raporlama zorlaşır.
İyi bir uzlaşma, başlangıçta tek hizmet türüyle başlamak ve gerçekten karışık teklifler görmeye başladığınızda çoklu hizmet desteği eklemektir.
Aktiviteler, e-posta karıştırmadan hafif bir geçmiş sağlar. Bir teklif gönderdikten sonra, "v2 gönderildi, müşteri zaman çizelgesini sordu" gibi kısa bir not kaydedin. Sonra ne olduğunu bir bakışta görebilirsiniz.
Bir teklif hattı uygulamasının birkaç ekranı yeterlidir, her biri net bir soruyu yanıtlamalı. Amaç hız: açın, dikkat gerektirenleri görün, bir güncelleme yapın, devam edin.
Burada hayatınızı geçirirsiniz. Her sütun bir durumdur. Her kart şu kadarı göstermeli ki bir sonraki adımı belirleyesiniz:
Hızlı eylemler mükemmel düzenlemeden daha önemlidir. Karttan (veya küçük bir detay çekmecesinden) durumu değiştirebilmeli, takip tarihi atayabilmeli, not ekleyebilmeli ve uzun bir form doldurmadan Kazanıldı veya Kaybedildi işaretleyebilmelisiniz.
Panolar akış için harikadır, ama bulmak için listeler daha iyidir. Durum, müşteri, hizmet türü ve gecikmiş takip gibi filtrelerle basit bir tablo stili liste kullanın. Hafta yoğunlaştığında bu sizin "yakalama" görünümünüz olur.
İki sayfa yeterli: Bir Teklif sayfası ve bir Müşteri sayfası.
Teklif sayfası zaman çizelgesi (notlar, durum değişiklikleri, sonraki takip tarihi) ile değer ve hizmet türü gibi ana alanlar içindir. Müşteri sayfası bağlamın olduğu yerdir: iletişim bilgileri, mevcut teklifler ve son aktiviteler.
Bir takip tarihini değiştirmek 30 saniye alıyorsa, güncel tutmazsınız. Bu sayfaları tek dokunuşla düzenlemeye göre optimize edin.
İlk etapta bir hafif rapor yeter: hizmet türüne göre kapanış oranı ve ortalama kapanma süresi. İki soruyu yanıtlamalı: "Daha çok ne satmalıyım?" ve "Anlaşmalar nerede takılıyor?"
Kullanılabilir bir teklif hattı uygulaması "tam CRM" değildir. Aktif olanı, takılı kalanı ve bugün takip edilmesi gerekeni görmenizi sağlar.
Veri modelinden başlayın ve akışı test etmek için birkaç sahte kayıt oluşturun. Bir müşteri, iki teklif ve en az iki hizmet türü (ör. “Website refresh” ve “Ongoing SEO”) oluşturun.
Sonra iki ana ekran yapın: durumlara göre sütunlu bir pano ve teklif detay formu. Pano günlük tarama içindir. Form doğru güncellemeler içindir.
İleriye taşıyacak bir yapım sırası:
Bunu güvenilir yapan şey budur.
Örnek: bir teklifi Taslaktan Gönderildiye sürüklediğinizde, uygulama müşteri e-postası veya teklif tutarı yoksa sizi durdursun. Bu küçük sürtünme, daha sonra veri dağınıklığını önler.
Bir varsayılan kural her şeyi sürüklenmemiş halden uzak tutar: her açık teklifin bir sonraki takip tarihi olmalı. Eksikse panoda uyarı gösterin.
"Kullanılabilir" için basit bir tanım:
Hatırlatmalar, boru hattındaki belirli bir ana bağlandığında en iyi çalışır, rastgele bir takvim zili gibi değil. Uygulama mevcut durumu bilirse, teklif bayatlama olasılığı yüksek olduğunda sizi dürtebilir.
Çok fazla tetikleyiciye gerek yok. Basit bir düzen şöyle görünür:
Hatırlatıcı metinlerini kısa ve eylem odaklı tutun. Sadece kimin, hangi teklif hakkında ve bir sonraki eylem ne olduğuna değinin:
Gürültü olmasın diye koruyucular ekleyin: bir teklif için günde bir hatırlatma ile sınırlandırın ve Erteleme seçenekleri (1 gün, 3 gün, gelecek hafta) sunun.
Her hatırlatmanın sonucunu da takip edin. Küçük bir sonuç kaydı tutun: tamamlandı, ertelendi (ne zamana kadar), atlandı veya gönderildi.
Örnek: "Website refresh - Acme Co" teklifini Pazartesi Gönderildi olarak işaretleyip takibi Perşembe yaparsınız. Perşembe sabahı bir hatırlatma alıp Cuma'ya ertelersiniz. Cuma takip edip hatırlatmayı tamamlandığına işaretlersiniz; "Gönderildi halde X gün sonra yanıt yok" sayaç sıfırlanır.
Teklif hattı uygulaması, ne yapılacağına karar vermenize yardımcı oluyorsa değerlidir. Bunu yapmanın en kolay yolu, genel orana değil hizmet türüne göre kapanış oranlarını takip etmektir. "Web sitesi yeniden tasarımı" ve "aylık bakım" genelde farklı işler gibi davranır.
Önce sonuçları tutarlı yapın:
Bir kural seçin ve ona sadık kalın, yoksa sayılarınız gürültü olur.
Kayıp nedenlerini kısa ve tutarlı tutun:
Sonra kapanış oranını, gerçekten kullandığınız bir zaman penceresinde hesaplayın (son 30 veya 90 gün). Eğer 12 "Marka stratejisi" teklifi gönderip 3'ünü kazandıysanız, bu %25 kapanış oranıdır. 6 "Landing page" teklifinden 4'ünü kazandıysanız, bu %67'dir. Kusursuz olması gerekmez, tutarlı olması yeterlidir.
Ayrıca "kapanma süresi"ni takip edin. Gönderilen tarihten Kazanıldı veya Kaybedildi tarihine kadar geçen günleri kaydedin. Belki "SEO audit" 5-10 günde kapanırken, "Tam site yeniden yapımı" 30-45 gün sürer. Bu, ne sıklıkla takip edeceğinizi ve gelir tahmininizi değiştirir.
Sayıları kullanışlı hale getirmek için basit bir kural uygulayın. Bir hizmet düşük kapanış oranı ve uzun kapanma süresine sahipse, teklifi sıkıştırın (kapsam, kanıt, fiyat) veya teklif yazmadan önce daha iyi nitelendirin. Yüksek oranlı hizmete ise müdahale edin: işe yarayanı yeniden kullanın ve fiyatınızı dikkatli yükseltin.
Teklif hattı uygulamasını işe yaramaz hale getirmenin en hızlı yolu onu kafa karıştırıcı yapmak. Serbest çalışanlar iyi niyetle başlar, sonra güvenmedikleri bir aracın içine sıkışırlar.
Bir tuzak çok fazla durumun aynı şeyi ifade etmesidir. "Gönderildi", "Sunuldu", "Teslim edildi" ve "İncelemede" arasındaki farkı bir cümlede açıklayamıyorsanız muhtemelen sadece birine ihtiyacınız vardır.
Bir diğer tuzak Gönderildi'nin mezarlık haline gelmesine izin vermektir. Takip tarihi zorunlu değilse, daha sonra panoyu açtığınızda bir sonraki adımı olmayan teklif yığını görürsünüz. Bu çoğu şeyi düzelten basit bir kural: Gönderildi içindeki her teklifin bir sonraki aksiyonu planlanmış olmalıdır.
Sessizce odak bozacak birkaç hata daha:
Hatırlatmaları sıkıcı ve spesifik tutun. Bir takip tarihine bağlı tek bir hatırlatma genelde yeterlidir. Daha fazla kural bir aylık gerçek kullanım veriniz olduğunda bekleyebilir.
Üç teklif üst üste "zamanlama çok uzun" notuyla kaybederseniz, bu daha küçük bir ilk aşama teklif etmeniz gerektiğinin işaretidir, beş yeni durum eklemeniz değil.
Teklif hattını tek doğruluk kaynağınız saymadan önce hiçbir şeyin limbo'da kalmadığından ve sonraki adımın bariz olduğundan emin olun.
Pipeline görünümünü açın ve kendinizi zamanlayın. Bugünün önceliklerini 30 saniyeden kısa sürede anlamalısınız. Bir sonraki adımı bulmak için birden çok teklife tıklamanız gerekiyorsa, tasarım en önemli alanı gizliyor demektir.
Kontrol listesi:
Küçük bir stres testi yapın. Farklı hizmetler için üç örnek teklif oluşturun, durumlar arasında taşıyın ve hatırlatmaları tetikleyin. Beş dakikada kırabiliyorsanız, yoğun bir haftada da kırılacaktır.
Pazartesi beş teklif gönderirsiniz. Üçü web yeniden tasarımı paketine, ikisi aylık destek retainer'ına aittir. Hepsi Taslak'ta başlar, e-posta gönderildiğinde Gönderildi'ye geçer.
Çarşamba geldiğinde durumlar bir hikâye anlatır:
Hatırlatmalar işi bırakmamanızı sağlar. "Görüntülendi ama 2 gün içinde cevap yok" kuralı, Cuma sabahı iki yeniden tasarım leadini takip etmeniz için sizi dürter. "Gönderildi ama 3 gün içinde görüntülenmedi" kuralı sessiz olanı yakalar, böylece daha kısa bir mesajla tekrar gönderirsiniz.
Gerçek hayat karmaşıktır. Bir müşteri Pazar günü geç cevap verip "Yoğun haftaydı" der ve gelecek ay başlamak ister; bu durumda On Hold'a taşırsınız, Gönderildi'de çürütmek yerine. Müzakere aktif kalır, ama hatırlatma her gün tekrar etmez; bir kez kontrol eder.
Hafta sonunda, hizmet türüne göre kapanış oranı aydınlatıcıdır: destek retainer 1/2 kazanıldı, web yeniden tasarımı 0/3. Ertesi hafta yeniden tasarım kapsamını iki seviyeye sıkıştırır ve kısa bir geri bildirim süresi eklersiniz.
En hızlı yol, her gün gerçekten açacağınız en küçük sürümü yayınlamaktır. İlk gün şablonlara, karmaşık otomasyonlara ve grafiklere ihtiyacınız yok. Gönderdiklerinizi, bekleyip beklemediklerinizi ve bir sonraki adımın ne olduğunu söyleyen bir şey lazım.
Durumlarınızı her birinin şu soruyu yanıtladığı şekilde ayarlayın: şimdi hangi eylem bekleniyor? Bir durumu bir cümlede açıklayamıyorsanız, sizi yavaşlatacaktır.
Bu hafta yapılacak üç eylem:
Temel döngü doğal hissettirmeye başladıktan sonra iyileştirmeleri birer birer ekleyin. İyi bir sıra: önce hatırlatmalar (hiçbir şey kaymasın), sonra raporlama (öğrenin), sonra şablonlar (zaman kazanın). Hepsini aynı anda eklerseniz hangi unsurun fayda sağladığını veya gürültü yarattığını anlayamazsınız.
Ağır kodlama olmadan bu yapıyı kurmak isterseniz, AppMaster (appmaster.io) pratik bir seçenektir: veritabanını (müşteriler, teklifler, hizmetler) modelleyebilir, UI ve durum kurallarını aynı yerde inşa edebilir ve süreç değiştikçe yineleyebilirsiniz.
Yükseltmeleri küçük ve ölçülebilir tutun. Bir hafta sonra sorun: daha hızlı mı takip ettim ve daha az cevap mı kaçırdım? Bir ay sonra sorun: hangi hizmet en iyi kapanıyor ve hangisi daha iyi bir teklif veya daha yüksek fiyat gerektiriyor?
İlk sürümü kişisel bir araç gibi görün; ürün gibi değil. Yeni bir teklifi kaydetmek veya ilerletmek 30 saniyeden fazla sürüyorsa, alanları ve ekranları basitleştirin. Zahmetsiz hissettiğinde, gerçekten kullanırsınız ve veriler güvenilir kalır.
Teklif hattı uygulaması nedir ve bir serbest çalışan neden buna ihtiyaç duyar?Bir teklif hattı uygulaması, her teklifi Taslak aşamasından Kazanıldı veya Kaybedildiye kadar takip etmek için kullanılan basit bir yerdir. Ana amaç, bir sonraki aksiyonu belirgin kılarak müşteriye teslimat yaparken takipleri unutmanızı önlemektir.
Hafif bir teklif hattı için hangi durumları kullanmalıyım?Gerçek gününüzle eşleşen en küçük setle başlayın: Taslak, Gönderilmeye Hazır, Gönderildi, Takip zamanı, Müzakere, Kazanıldı, Kaybedildi. İki durum pratikte aynı hissediyorsa, ileri taşımayı zahmetsiz tutmak için birleştirin.
Her teklif için saklamam gereken en az bilgi nedir?Takip etmenize ve hangi tekliflerin satıldığını öğrenmenize yardımcı olan az ama gerekli bilgileri saklayın: müşteri, hizmet türü, tahmini ücret, gönderim tarihi, güncel durum ve bir sonraki takip tarihi. Kazanıldı veya Kaybedildi işaretlendiğinde bir sonuç sebebi ekleyin ki raporlar işe yarasın.
Gerçekten her teklif için bir takip tarihine ihtiyacım var mı?Açık teklifler için, özellikle Gönderildi ve Takip zamanı durumlarında, varsayılan olarak bir sonraki takip tarihi gerektirin. Bir teklifin bir sonraki adımı yoksa sessizce unutulur ve daha sonra ne yapacağınızı bilemezsiniz.
Bildirimlerden rahatsız olmadan hatırlatıcıları nasıl ayarlarım?Hatırlatmaları boru hattı anlarına bağlayın, rastgele takvim uyarılarına değil. Pratik bir düzen: teklif Gönderildiğinde bir takip tarihi zorunlu olsun; o tarihte tek bir hatırlatma gönderilsin; uzun süre Gönderildi halinde kalırsa yeni bir takip görevi oluşturulsun.
Sayılarım karışmasın diye "Kazanıldı" ne sayılır?Sayılarınızın karışmaması için tutarlı bir kural kullanın. İyi bir varsayılan: Kazanıldı, yalnızca imzalı bir sözleşme, ödenmiş bir depozito veya onaylanmış bir başlangıç planı sonrası verilsin. Böylece “belki” anlaşmalar kazanma oranlarını şişirmez.
Tekliflerin neden kaybedildiğini nasıl takip etmeliyim?Her Kaybedildi işaretlediğinizde kısa bir kayıp nedeni kaydedin: fiyat, zamanlama, kapsam uyumsuzluğu, yanıt yok veya rakip seçildi gibi. Mükemmel detaya gerek yok; tutarlılık, desenleri görmenizi sağlar ve teklifinizi düzeltmenize yardımcı olur.
Bir teklif bir hizmet türüne mi sahip olmalı yoksa birden fazla mı?Hızlı raporlama için önce tek bir hizmet türüyle başlayın—bu işleri hızlandırır ve raporlamayı basit tutar. Paketler yaygınsa ve gerçekten kararlarınızı etkileyecekse sonra çoklu hizmet desteği ekleyin.
Notlar ve aramalar gibi aktiviteleri neden takip etmeliyim?Önemli anlardan sonra hızlı bir aktivite notu bırakın; örneğin revize edilmiş bir sürümü gönderdiğinizde veya müşteri zaman çizelgesini sorduğunda. Hafif bir aktivite geçmişi, e-postalarda arama yapmaktan kurtarır ve daha hızlı, tutarlı cevap vermenizi sağlar.
Bunu ağır kodlama olmadan yapabilir miyim ve AppMaster nasıl uyuyor?Müşterileri, teklifleri, hizmetleri ve aktiviteleri modelleyip durum kuralları ve takip hatırlatmalarıyla bir pano görünümü oluşturabilirsiniz. No-code bir araç olan AppMaster ile veritabanını modelleyip hızlıca çalışan bir uygulama üretebilir, durumları ve gerekli alanları yineleyerek hafif tutabilirsiniz.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
