Düzeyleri, logo dosyalarını, fatura durumunu ve vaat edilen faydaları net tutarak etkinlik gününde hiçbir şeyin gözden kaçmamasını sağlayan bir sponsor takipçisi oluşturun.
Çoğu sponsor problemi “büyük” sorunlar değil. Genellikle çatlaklardan süzülen küçük detaylardır: hiç gelmeyen bir logo, yazılı kaydı olmayan bir vaat, gönderilmiş ama ödenmemiş bir fatura veya sadece birinin e-postasında kalan bir son tarih.
Kontrol edilecek tek bir yer yoksa bilgi gelen posta dizilerinde, sohbet mesajlarında, paylaşılan sürücülerde ve birilerinin hafızasında yayılır. Böylece yanlış logo versiyonunun son anda basılması, vaat edilen bir teşekkürün atlanması veya sponsorun hala ödeme yapmadığının çok geç fark edilmesi gibi sürprizlerle karşılaşırsınız.
Basit bir takipçi, herkesin aynı görünümü görmesini sağlar; insanlar günde 10 dakika sponsorlarla ilgileniyor olsalar bile. İşin sırrı, farklı insanların farklı detaylara ihtiyaç duymasıdır:
Amaç “daha fazla evrak” değil. Amaç daha az utanç verici an ve etkinlik öncesi daha az acil mesaj. Her sponsorun net bir durumu ve kısa bir sonraki adımı olduğunda sorunları erken fark edip sakin şekilde çözebilirsiniz.
Bu tür bir takipçi aynı zamanda sağlıklı beklentiler oluşturur. Tam bir CRM değildir ve olması gerekmez. Her görüşmeyi kaydetmeye ya da bir satış hattı oluşturmaya çalışmıyorsunuz. Satışını yaptığınız şeyi teslim etmeye çalışıyorsunuz.
Gerçekçi bir örnek: Altın sponsorunuz “web sitesinde logo, sahnede anons ve iki bilet” diyor. Bu sadece e-postadaysa sahne sunucusu bunu hiç görmeyebilir. Takipçideyse sahne anonsunu atayabilir, logo versiyonunu onaylayabilir ve baskı gününden önce biletleri gönderilmiş olarak işaretleyebilirsiniz.
Eğer bir hesap tablosu yerine küçük bir dahili araç yapmayı tercih ediyorsanız, aynı alanları Koder.ai (koder.ai) içinde hafif bir uygulama olarak yeniden oluşturabilir ve her etkinlik için yeniden kullanabilirsiniz.
Sponsor takipçisi, ekibinizin gerçek işleri etkileyen ayrıntılar için tek doğru kaynağıdır: sponsorun ne satın aldığı, size ne borçlu olduğu, onların size ne borçlu olduğu ve hangi varlıklara hâlâ ihtiyaç duyduğunuz. Ekip, bir e-posta göndermeden, bir tasarımı onaylamadan veya baskıya gitmeden önce kontrol etmesi gereken tek yer bu olmalıdır.
Hızlıca cevap vermenizi gerektiren her şeyi ekleyin. En azından şunları yakalayın:
İyi bir takipçi tam bir muhasebe sistemi değildir. Vergeleri hesaplaması, banka mevduatlarını uzlaştırması veya mali tablolar üretmesi gerekmez. Ayrıca her sözleşmeyi ve e-postayı saklaması da gerekmez. Bazı ekipler “sözleşme alındı: evet/hayır” ve kısa bir not alanı ekler, ama amaç açıklık, belge depolama değil.
Düşündüğünüzden daha erken başlayın. Temas kurulduğu anda, potansiyel her sponsor için bir satır oluşturun — hatta “belki” olanlar için bile. Anlaşmalar hızlı hareket eder ve bir satırın eksik olması ayrıntıların kaybolmasına yol açar.
Basit bir kural yardımcı olur: bir detay tasarımı, pazarlamayı, tabelayı veya parayı etkiliyorsa, takipçide yer alır. Hukuki dosyalama veya derin finans konularıysa muhtemelen başka bir yerde kalır.
Bir takipçi, ekiplerin yoğun bir haftada nasıl davrandığıyla örtüşürse işe yarar. Küçük başlayın. Her ekstra sütun, bayat bilgi için başka bir yerdir ve bayat bilgi eksik bilgiden daha kötüdür.
Üç grupta düşünün: sponsor kim, ne anlaşıldı ve sırada ne var.
Günlük referans alacağınız temel bilgiler şunlardır:
Bir "Sahip" sütunu ekleyin. Bir sponsor “herkesin işi” olursa, kimsenin işi olmaz. Bir sonraki aksiyondan sorumlu bir kişiyi atayın, diğerleri yardımcı olsa bile.
Kısa, net statüler kullanın ki saniyeler içinde sıralayabilin veya filtreleyebilin. Basit bir akış yeterlidir:
Beş çeşit “belki” takip etmekten kaçının. Nüans gerekiyorsa notları kullanın, daha fazla statü icat etmeyin.
Gerçek dünya ayrıntıları için bir not alanı tutun: özel istekler (ek biletler, sahne anonsu), kısıtlamalar (yanına rakip logo konamaz) ve kesin son tarihler (baskı kesimleri). Notları, yarın sponsoru bir ekip arkadaşına devrederken okunacak şekilde yazın: kısa, spesifik ve tarihli.
Koder.ai gibi bir araç içinde takipçi kuruyorsanız, bu alanları birinci sürüm olarak görün. Bu alanlarla etkinliği yönetebilmelisiniz.
Sponsor düzeyleri yalnızca herkes ne anlama geldiğini anlıyorsa işe yarar. Basit düzey isimleri kullanın ve her düzeyi bir kısa cümleyle tanımlayın. "Premium" gibi belirsiz etiketlerden kaçının; yerine tam olarak hangi teslimatlar olduğu yazılmalı. İyi bir test: bir gönüllü düzey açıklamasını okuyup sizden soru sormadan ne yapacağını anlayabilir mi?
Düzeyleri etkinlik boyunca sabit tutun, ama faydaları sponsor düzeyinde takip edin. Aynı düzey içinde bile sponsorlar küçük değişiklikler pazarlık edebilir (ek bir sosyal gönderi, daha büyük bir stant, farklı bir konuşma zamanı). Takipçiniz hem düzey kurallarını hem de sponsorun gerçek taahhüdünü göstermelidir.
Her sponsor için faydaları tek tek işaretlenebilecek maddeler olarak yazın:
Her öğeyi tartışmasız "tamamlandı" olarak işaretlenebilecek şekilde ifade edin.
"Vaat edildi" ile "teslim edildi" yeterli değildir. Her fayda için bir teslim tarihi ekleyin; basım günü veya etkinlik haftası gibi ifadeler bile olabilir. Bu, faydaları bir dilek listesinden programa çevirir.
Ayrıca bir "Kanıt" alanı ekleyin: ekran görüntüsü adı, fotoğraf dosya adı veya kısa bir onay notu (ör. "Slayt destesinde logo v3, Sam tarafından 12.01 onaylandı"). Bir sponsor "Gönderimiz yayımlandı mı?" diye sorduğunda, 10 saniyede yanıt verebilmelisiniz.
Logolar sponsor işinin sık sık bozulduğu yerdir. Dosyalar geç gelir, birisi yanlış sürümü kullanır veya bir pankart baskıya gitmeden önce sponsor onay vermez. Takipçiniz logo işlerini sıkıcı ve öngörülebilir yapmalıdır.
Logoyu küçük bir proje gibi ele alın ve net bir statü tutun. Herkes tablodan hızlıca neyin engellendiğini anlayabilmelidir:
Tasarımın gerçekten ihtiyaç duyacağı dosya detaylarını yakalayın. "E-posta dizisinde" demeye güvenmeyin.
Sonra logonun nerede görüneceğini kaydedin. "Web sitesi" demek ayrıntıyı vermez; footer, sponsor sayfası, kayıt sayfası veya hepsi olabilir. Basit yerleşim alanları yardımcı olur: Web sitesi yerleşimi, Basılı pankart, Slaytlar, Yaka kartları ve ayrıca boyut veya kilitleme notları.
Son olarak gerçek bir onay adımı ekleyin. "Onaylayan", "Onay tarihi" ve "Onay kaynağı" (e-posta, mesaj, arama) bilgilerini tutun. Sponsor daha sonra değişiklik isterse temiz bir kayıt olur.
Gerçekçi bir senaryo: "Acme_logo.png" alırsınız ve çevrimiçi iyi görünür ama 3 metrelik bir pankartta bulanık çıkar. Eğer takipçide "Gerekli format: SVG" ve "Logo durumu: Alındı (onaylanmadı)" yazıyorsa, tasarım kesinleşmeden önce sorunu yakalarsınız.
Bir hesap tablosu yerine küçük bir dahili araç tercih ediyorsanız, Koder.ai içinde basit bir takipçi uygulaması bu alanları yansıtabilir ve yüklemeleri, onayları ve yerleşimleri tek yerde tutabilir.
Sponsorlar heyecanlı olabilir ama ödeme konusunda yavaş davranabilir. Takipçiniz fatura durumunu bir bakışta göstermiyorsa, yanlış kişileri aramakla zaman kaybedersiniz veya daha kötüsü, ödeme yapmamış bir sponsora fayda teslim edersiniz.
Tek bir, tutarlı bir durum sütunu ile başlayın. Basit tutun: Taslak, Gönderildi, Gecikmiş, Ödendi ve iade (gerçekten iade işlemi yapıyorsanız). Statüyü hislere değil tarihlere bağlayın.
Statü yanında, aceleyle sorulacak soruları yanıtlayacak alanlar ekleyin: fatura numarası, gönderim tarihi, son tarih, tutar ve ödeme yöntemi (kart, banka havalesi, çek). "Kime fatura edilecek" (AP iletişim kişisi adı ve e-posta) saklarsanız, takipler ekip içinde dolaşmaz.
Takipler bir kişi tarafından sahiplenildiğinde en iyi sonucu verir. Çoğu etkinlik için işe yarayan basit bir program:
Teslimat tetikleyicilerini net yazın. Bir kişi sözlü "evet"i yeterli sayarken diğeri ödemeyi bekliyorsa takımlar takılır.
Yaygın tetikleyiciler: imzalı sözleşme, yazılı taahhüt (e-posta) veya ödeme alındı. Örneğin, web sitesine logoyu imzalı anlaşmadan sonra koyabilirsiniz ama tabelaları sadece fatura "Ödendi" olarak işaretlendikten sonra basabilirsiniz.
12 sponsorlu tek günlük bir konferans için bu netlik, Platinum bir pankartı fatura Taslak durumdayken basma gibi utanç verici anları önler.
Bir sponsor takipçisini temel bir hesap tablosuyla oluşturabilirsiniz. Oradan başlayın. Hızlı, paylaşması kolay ve çoğu etkinlik ekibi için yeterlidir.
60–90 dakikanızı ayırın ve beş şeyi yapın:
Bir karışıklığı önleyen küçük ama etkili bir değişiklik: "Sahip" sütununu tutun ve kullanın. Her sponsor için bir kişi bir sonraki aksiyondan sorumlu olmalı.
Tablo büyürse, aynı alanları basit bir dahili uygulamaya (örneğin Koder.ai içinde bir sohbet isteminden oluşturulan) dönüştürebilirsiniz; süreciniz değişmeden alanlar aynı kalır.
300 katılımcılı tek günlük bir topluluk konferansını ve 12 sponsoru hayal edin. Ekip, her sponsor için bir satır ve günlük soruları cevaplayan birkaç sütun (kim onaylandı, hangi düzeyde, logo onaylandı mı, fatura ödendi mi, hangi faydalar hâlâ verilecek) içeren basit bir takipçi kullanıyor.
Aynı sayfada üç sponsor çok farklı görünebilir:
Planlamanın ortasında, koordinatör bir güncelleme yapar ve çok fazla yazışmayı kurtarır. Northside Bank logo gönderir. Dosya eklenir, "logo alındı" Evet olarak değişir ama "marka onayı" Karanlık arka planda çalışıp çalışmadığını sponsor ekibinin onaylaması gerektiği için Beklemede kalır. Fatura durumu "Gecikmiş" olarak işaretlenir (10 gün gecikmiş) ve teslimatlar notu güncellenir: "Sahne anonsu 10:05 için planlandı."
BrewCo için takipçi "fatura: UYGULANAMAZ" ve "fayda: 300 kişilik kahve, teslim 07:30" gösterir. Teslimatı onayladıklarında fayda Durumunu Planlandı olarak işaretlersiniz, Tamamlandı değil, böylece kimse bunun hâlâ yapılacak bir iş olduğunu unutmaz.
Etkinlikten bir hafta önce ekip, hâlâ kırmızı olanları filtreler:
O tek görünüm ekibe bugün ne takip edileceğini söyler; baskı zamanında sorunları keşfetmek yerine bugün hangi işleri yapacaklarını bilirler.
Çoğu sponsor baş ağrısı "kötü sponsor" kaynaklı değildir. Tamamlanmış görünen ama basit soruları hızlıca cevaplayamayan bir takipçi yüzünden olur: Kim ne borçlu? Ne onaylandı? Ne eksik?
Yaygın bir hata, aynı hücrede görevleri ve gerçekleri karıştırmaktır. "Logo gönderildi, onay bekleniyor, fatura gerekiyor" gibi bir not filtrelenemez. Kimin sizden bir şey beklediğini kimin beklediğini bilmeniz gerektiğinde bu işe yaramaz.
Diğer bir sorun sahipliğin eksik olmasıdır. "Fatura takibi" veya "Sahne anonsunu onayla" yanında kimse isimlendirilmemişse genelde herkesin işi olur, bu da nihayetinde kimsenin yapmaması demektir.
Faydalar son tarih olmazsa kaybolur. Bir sponsor bülten bahsi, stant konumu veya saha tabelası vaat edilebilir ama son tarih yoksa iş sessizce baskı gününe kadar kayar.
Logo kaosu, beklenenden daha fazla son dakika yeniden çalışmasına yol açar. Her dosyayı kabul ederseniz, ekran görüntüleri, minik PNG'ler, çekilmiş JPEG'ler veya eski marka kullanımları alırsınız. Tasarımcı zaten pankartları yerleştirirken yeni bir dosya peşine düşmek zorunda kalırsınız.
Ayrıca faydalar çok erken "yapıldı" olarak işaretlenebilir. "Sosyalde paylaşıldı" kanıt sayılmaz. "Web sitesinde logo" doğrulama olmadan onay işareti değildir. Kanıt yoksa sonra tartışma çıkar veya yeniden kontrol için ekstra zaman harcarsınız.
Bunları önlemenin basit yolu:
Örnek: Bir Altın sponsorunuz varsa ve takipçide "Altın", "Logo onayı: Evet", "Fatura: Gönderildi", "Ödeme: Beklemede", "Stant boyutu: Onaylı" ve slayt destesi için bir son tarih varsa, gerçek riski saniyeler içinde görüp aksiyon alabilirsiniz.
Baskı günü ve etkinlik günü küçük boşlukların büyük strese dönüştüğü anlardır. Amaç basit: ekipten herkes sponsorun ne için ödeme yaptığını, ne aldığını ve teslim edilip edilmediğini saniyeler içinde cevaplayabilmeli.
Önce para ve düzey ayrıntılarıyla başlayın. Bir sponsor birinin posta kutusunda "Altın gibi" görünüyorsa ama takipçide yoksa yanlış yerleşim vaat edilir veya bir fayda atlanır.
Hızlı bir kontrol yapın:
Eğer yalnızca bir ekstra adım için zamanınız varsa, bir "baskı kilidi" notu ekleyin: logo değişikliklerini kabul ettiğiniz son tarih. Yoksa baskıdan 12 saat önce yeni bir logo alırsınız.
Saha için kolay kullanılabilir tek sayfalık bir sponsor özeti hazırlayın. Sponsor adı, düzeyi, telaffuz notları, logonun nerede göründüğü ve canlı anlar (MC anonsu, sahne teşekkürleri, stant konumu) dahil edin.
Gerçekçi bir örnek: MC metniniz "Platin sponsorlar" içeriyorsa ama takipçide iki düzey hâlâ beklemedeyse, ya ödememiş bir sponsoru fazla öne çıkarırsınız ya da ödemiş birini eksik bırakırsınız.
Koder.ai içinde bu takipçiyi kuruyorsanız, baskı öncesi anlık görüntüler ve geri alma kullanışlı olabilir; böylece bir sürümü dondurup yanlışlıkla son dakika düzenlemelerini engelleyebilirsiniz.
En büyük kazanım mükemmel bir tablo değil. Tekrarlanabilir bir süreç. Etkinlikten sonra takipçiyi kopyalayın, satırları temizleyin ve yapıyı saklayın ki bir sonraki etkinlik %80 hazır başlasın.
Hesap tablosunun yeterli olup olmadığına karar verin. Eğer yalnızca bir kişi güncelliyorsa ve otomatik hatırlatmalara ihtiyaç yoksa, bir tablo yeter. Birden fazla kişi güncelliyorsa, değişiklikler sıksa veya sponsorlar farklı kişilere e-posta atıyorsa, kısa sürede acı çekersiniz. Bu durumda izinler (kim neyi düzenleyebilir), küçük giriş formları ve eksik faturalar veya onaylar için hatırlatmalar gerekecektir.
Bilgi toplama şeklini standartlaştırın. Kısa bir sponsor giriş formu, logo ama fatura kontak eksikliği gibi yaygın yazışmaları önler. Formu kısa tutun ki sponsorlar doldursun.
Yönetilebilir bir iş akışı:
Bir tablo'dan daha yapılandırılmış bir şeye ihtiyaç duyuyorsanız ama yine de hafif kalmak istiyorsanız, Koder.ai içinde küçük bir dahili araç oluşturabilirsiniz: sponsor listesi, logo onay görünümü ve fatura durum panosu. İhtiyaçlarınız daha sonra büyürse, platform kaynak kodu dışa aktarmayı da destekler, böylece aracı ekip tercih ettiği şekilde barındırabilir.
Ayrıca "etkinlik paket"inizi saklayın: geçen yılın düzeyleri, fayda dilleri, e-posta şablonları ve son tarihler. Bir dahaki sefere her şeyi baştan kurmak yerine detayları güncellersiniz.
Teslimatı bozabilecekleriyle başlayın: basımda nasıl görünmesi gerektiği açısından sponsor adı (basımda görüneceği gibi), düzey ve tutar, vaat edilen faydalar, logo durumu ve fatura/ödeme durumu. Bir sahip ve birkaç son tarih ekleyin, böylece her sponsor için bir sonraki yapılacak iş bir bakışta görülebilir.
Paranın, tasarımın veya sahadaki işlerin etkilediği her kararda kullanın. Birisi bir afişi onaylamadan, sahne anı planlamadan veya fatura takibi göndermeden önce tracker'a bakmalı; aksi takdirde eski bilgilere göre hareket edilebilir.
Kısa, standart statüler kullanın ve daha fazla nüans gerekiyorsa notlar alanına koyun. Statüler filtrelenebilir ve hızlıca anlaşılabilir olmalı; uzun paragraflara bağımlı olmamalısınız.
Düzey kurallarını ayrı tutun, ancak gerçek vaatleri her sponsor düzeyinde kaydedin. Aynı düzey içindeki sponsorlar küçük değişiklikler pazarlık edebilir; tracker o sponsorun gerçekte ne alacağını göstermeli, yalnızca paket adını değil.
Logoyu kendi iş akışı gibi ele alın: net bir statü, onaylanmış kullanım için dosya kaydı ve karanlık/açık arka plan kuralları. Kim ne zaman onayladı ve ne zaman onaylandı bilgisini yazın, böylece sonradan değişiklik istenirse kayıt temiz olur.
Tek bir basit fatura durum akışı seçin ve statüleri tarihlere bağlayın. Fatura numarası, gönderim tarihi, son ödeme tarihi, tutar ve kime fatura edileceğini kaydedin ki herkes takip edebilsin.
Düşük riskli faydaları daha erken teslim etmeyi ve maliyeti/riski yüksek olanları ödeme teyidi alınana kadar bekletmeyi varsayılan olarak kullanabilirsiniz. Örneğin, web sitesine logo yayınlama imzalı anlaşma alınca olurken, baskı işleri için fatura "Ödendi" olana kadar bekleyebilirsiniz.
Her sponsor için bir sonraki aksiyonun sahibini atayın; başkaları katkıda bulunsa bile bir kişi sorumlu olmalı. Sahipsiz öğeler genelde yavaşlar çünkü herkes başkasının hallettiğini varsayar.
Bir baskı ve yayın kesme tarihi belirleyin ve uygulayın; son dakika değişiklikleri pahalı hatalara neden olur. Baskı günü öncesinde ödenmemiş faturalar, eksik veya onaylanmamış logolar ve sahibi/due date olmayan faydaları tarayın.
Birden fazla kişinin güncelleme yapması, izinler, hatırlatmalar veya yüklemelerin daha iyi yakalanması gerekiyorsa; o zaman bir dahili uygulamaya geçmek mantıklı olur. Hafif bir dahili araç Koder.ai içinde aynı alanları yansıtabilir ve yine de basit kalır.
