Hibe değerlendirme portalı: vakıflar için net bir iş akışı

Hibe değerlendirmelerini takip etmek neden zorlaşır?

Küçük bir vakıf bir dönemde yalnızca 40 veya 50 başvuru alsa bile değerlendirme süreci hızla karmaşıklaşabilir. Bir kişi formları e-postayla toplar, başka biri elektronik tablo tutar, değerlendiriciler de yorumlarını ayrı belgelerde gönderir. Kısa sürede kimse birkaç kişiye sormadan tüm resmi göremez.

E-posta özel bir sorun yaratır. Bir değerlendirici eski bir ileti dizisine yanıt verebilir, yanlış puanlama formunu ekleyebilir veya program yöneticisini bilgiye eklemeyi unutabilir. Önemli ayrıntılar ilgili başvurunun yanında değil, kişisel gelen kutularında kalır. Elektronik tablolar toplamları hesaplamaya yardımcı olur, ancak başvuruyu, değerlendirici notlarını, çıkar çatışması bildirimlerini ve karar geçmişini genellikle bir arada tutmaz.

Durum bilgilerindeki boşluklar gecikmelere yol açar. Başvuru sahibi vakfın gönderiyi alıp almadığını bilemeyebilir. Değerlendirici, ekibin zaten gönderdiği bir atamayı bekleyebilir veya yönetici, değerlendiricilerin gönderdiği fakat tamamlandı olarak işaretlemediği puanların peşine düşebilir. Bu boşluklar daha fazla takip mesajı doğurur ve son tarihleri belirsiz hale getirir.

Hibe değerlendirme portalı her başvuru için sürecin tamamını izleyen ortak bir kayıt oluşturur: gönderim, uygunluk kontrolü, değerlendirici ataması, çıkar çatışması bildirimi, puanlama, kurul kararı ve nihai mektup. Ekip sıradaki görevin kimde olduğunu görür, değerlendiriciler ise yalnızca kendilerine atanan başvurulara erişir.

Bu yapı kararları daha sonra açıklamayı da kolaylaştırır. Bir başvuru sahibi geri bildirim istediğinde ekip eski posta kutularını aramak yerine kayıtlı puanları ve notları kontrol edebilir. Bir yönetim kurulu üyesi bir teklifin neden ilerlediğini sorarsa ekip aynı geçmişi birlikte inceleyebilir.

Örneğin, her biri için üç değerlendirici bulunan 60 başvuruyu yöneten bir vakıf normalde 180 ayrı puanlama formu toplar. Ortak bir portal her puanı doğru teklifle eşleştirir ve hangi değerlendirmelerin tamamlanmadığını gösterir. Herkes güncel bilgiyle çalışır.

Amaç basit: dağınık dosyaların, belirsiz sorumlulukların ve eksik güncellemelerin yarattığı belirsizliği, bunlar başvuru sahiplerini veya fonlama kararlarını etkilemeden ortadan kaldırmak.

Portalı oluşturmadan önce iş akışını haritalayın

Hibe değerlendirme portalı, vakfınızın karar alma biçimini izlemeli ve belirgin boşlukları kapatmalıdır. Formları veya değerlendirici ekranlarını oluşturmadan önce her aşamayı yazın: taslak, gönderildi, uygunluk kontrolü, değerlendirme, karar ve bildirim.

Her aşama için net bir başlangıç ve bitiş belirleyin. Başvuru sahibi gönderimden önce taslağı düzenleyebilir. Ekip uygunluk kontrolü sırasında eksik bir başvuruyu geri gönderebilir, ancak değerlendiriciler yalnızca temel kuralları karşılayan başvuruları görmelidir.

Kimin ne yapacağına karar verin

İzinleri yalnızca unvanlara değil, gerçek sorumluluklara göre belirleyin. Bir program sorumlusu uygunluğu kontrol edip değerlendiricileri atayabilir. Değerlendiriciler kendilerine atanan başvuruları okuyabilir, çıkar çatışması bildirebilir ve puan gönderebilir. Yönetim kurulu üyeleri önerileri inceleyip ödülleri onaylayabilir, küçük bir ekip de karar mektuplarını gönderebilir.

Başlamadan önce gönderilmiş bir başvuruyu kimin yeniden açabileceğini, iletişim bilgilerini ve ekleri kimin görebileceğini, değerlendirici atamalarını kimin değiştirebileceğini, ödülleri veya retleri kimin onaylayacağını ve bildirimleri kimin göndereceğini kararlaştırın. Bu kararları belgelemek, bir kişinin sorumlu olduğu sonraki kararı haber vermeden puan veya durum değiştirmesini önler.

Her görev devrinin yanına tarih koyun

Başvuru sahiplerinin bir gönderim son tarihine ihtiyacı vardır. Ekibin uygunluk kontrolleri için zamana ihtiyacı olur. Değerlendiricilerin geç yanıtlar, görüşme ve onay için zaman bırakacak bir puanlama son tarihi olmalıdır. Son karar tarihini dönem başlamadan önce belirleyin ve planı geriye doğru oluşturun.

Her başvurunun durumunu dahili ekip için görünür tutun. Basit bir görünüm «Uygunluk kontrolü tamamlandı», «İki değerlendirme bekleniyor» veya «Karara hazır» ifadelerini gösterebilir. Ekip ne olduğunu öğrenmek için e-posta dizilerini aramamalıdır.

Ayrıca geciken son tarihlerin nasıl ele alınacağına karar verin. Portal geciken değerlendirmeleri işaretleyebilir, ancak vakfın yine de bir kuralı olmalıdır: hatırlatma gönderme, başvuruyu yeniden atama veya değerlendirme süresini uzatma. Tutarlı kurallar benzer durumların benzer biçimde ele alınmasına yardımcı olur.

Değerlendiricilerin kullanabileceği bir başvuru formu oluşturun

Hibe formu, başvuru sahiplerinin çalışmalarını açıkça anlatmasına ve değerlendiricilerin her teklif için aynı bilgileri görmesine yardımcı olmalıdır. Kuruluş adı, iletişim kişisi, tüzel statü, konum ve ilgiliyse vakfınızdan geçmişte alınan fonlar gibi kimlik bilgileriyle başlayın.

Kısa bir proje özeti isteyin, ardından amaç, planlanan faaliyetler, hizmet verilen kişiler, takvim ve beklenen sonuçlarla ilgili ayrı sorular sorun. 150 kelimelik bir özet ilk değerlendirme ekranının okunabilir kalmasını sağlar. Daha uzun yanıtları değerlendiricilerin ek bağlama ihtiyaç duyduğu alanlara bırakın.

Talep edilen tutarı metin kutusu yerine sayı alanında toplayın. Buna toplam proje bütçesini, kesinleşmiş geliri ve bekleyen diğer fonları ekleyin. Böylece değerlendiriciler talebin çalışmanın belirli bir bölümünü mü finanse ettiğini, yoksa büyük bir açık mı bıraktığını görebilir.

Değerlendiricilerin başvuruları adil biçimde karşılaştırmak için ihtiyaç duyduğu bilgileri isteyin. Çok fazla zorunlu soru süreci bir engel parkuruna çevirir. Küçük bir yerel grubun denetlenmiş hesapları veya resmi stratejik planı yoksa başvuruyu reddetmek yerine kısa bir açıklama alanı sunun.

Forma sığmayan bilgiler için destekleyici dosyalar yine önemlidir. Proje bütçesi, güncel mali tablolar, yönetişim listesi ve çalışma örnekleri veya değerlendirme raporları için ayrı yükleme alanları kullanın. Her alana net bir etiket, kabul edilen dosya türleri ve boyut sınırı ekleyin. Değerlendiricilerin bütçeyi hızla bulması gerekiyorsa genel bir «ek belgeler» alanından kaçının.

Taslakları otomatik kaydedin ve başvuru sahiplerine hangi zorunlu yanıtların eksik kaldığını gösterin. Başvuru sahipleri mali rakamları, onayları ve belgeleri birkaç gün içinde toparlayabilir. Taslağın kaydedilmesi, yanıtları yeniden yazmadan geri dönmelerini sağlar; portal yine de başvuruları yayımlanan son tarihte kilitleyebilir.

Koder.ai, bu yapıyı sohbet arayüzü üzerinden özel bir vakıf hibe yönetimi formuna dönüştürebilir. Başvuru sahibi alanları, dosya yüklemeleri ve taslak durumu da buna dahildir. Formu odaklı tutun. Her soru, değerlendiricilerin fonlama kararında kullanabileceği bir bilgi sağlamalıdır.

Değerlendiricileri karışıklık yaratmadan atayın

Bir vakıfta 40 başvuru, küçük bir gönüllü kurul ve örtüşen ilgi alanları olduğunda değerlendirici atamak zorlaşır. Hibe değerlendirme portalı her başvuruyu, mevcut sorumlusunu ve son tarihini tek yerde göstermelidir.

Başvuruları program alanı, konum, başvuru sahibi türü veya konuya göre etiketleyin ve alanı bilen değerlendiricilerle eşleştirin. Bir gençlik tiyatrosu teklifi, yalnızca boş zamanı olduğu için seçilen biri yerine gençlik programlarını veya sahne sanatlarını bilen kişilere gitmelidir.

Her atamayla birlikte bir son tarih belirleyin. Değerlendiriciler puan ve yorumları ne zaman göndereceklerini, yöneticiler de hangi işlerin geciktiğini, beklediğini veya tamamlandığını bilmelidir. Son tarihten önce bir hatırlatma gönderin, ancak insanların görmezden gelmeyi öğreneceği tekrarlı uyarılardan kaçının.

Atama görünümü atanmamış başvuruları, her değerlendiricinin iş yükünü, atama tarihlerini, değerlendirme son tarihlerini ve bildirilen çıkar çatışmalarını göstermelidir. Yöneticiler ayrıca işleri yeniden atayabilmeli ve nedeni kaydedebilmelidir.

İlk değerlendirme aşamasında özel yorumlar önemlidir. Değerlendiriciler birbirlerinin görüşlerini çok erken okursa ilk güçlü görüş sonraki puanları etkileyebilir. Her değerlendiriciye notlar ve ölçüt puanları için özel bir alan verin. Ortak yorumları yalnızca kurul görüşmesi sırasında veya yönetici paylaşmaya karar verdiğinde açın.

İş yükü sınırlarını da kullanın. Bir kişiye altı ayrıntılı teklif, başka bir kişiye ise tek kısa teklif vermek genellikle eşit dikkatle sonuçlanmaz. Hibe başvuru iş akışı atamaları dosya sayısına, beklenen değerlendirme süresine ve son tarihe göre dengeleyebilir.

Açık bir dönem boyunca yöneticiler atanmamış başvuru kuyruğunu her gün kontrol etmelidir. Geç gönderilen veya çıkar çatışması bildirilen bir başvurunun ardından değerlendiricisi olmayan başvurular kolayca gözden kaçabilir. Görünür bir kuyruk bu işi son dakika sorunundan rutin bir göreve dönüştürür.

Çıkar çatışması bildirimlerini erkenden yönetin

Bir değerlendirici adil olmaya çalışsa bile çıkar çatışması hibe kararını etkileyebilir. Değerlendiricilerden tam başvuruları okumadan önce mali, kişisel veya mesleki bağlantılarını bildirmelerini isteyin. Bu, hem başvuru sahiplerini hem de değerlendiricileri korur.

Bildirim formu sade seçenekler kullanmalı ve kısa bir açıklamaya yer bırakmalıdır. Bir değerlendirici başvuru sahibiyle çalışmış, başvuru sahibi kuruluşun yönetim kurulunda yer almış, projede görev alan birini yönetiyor veya bu kişilerle yakın kişisel ilişki içinde olabilir. Ücretli iş, yatırım veya beklenen sözleşme gibi mali bağlar da önemlidir.

Değerlendiricilerden her atanmış başvuru için iki ifadeden birini onaylamalarını isteyin: «Çıkar çatışmam yok» veya «Aşağıda açıklanan olası bir çıkar çatışmam var.» Bağlantının görevi bırakmayı gerektirip gerektirmediğini vakıf yazılı politikasını kullanarak belirlemelidir.

Erişimden önce çatışmaları kontrol edin

Portalın, değerlendirici tam başvuruyu açmadan önce çıkar çatışması bildirimini tamamlamasını sağlayın. Değerlendiricinin başvuru sahibini tanıması için yalnızca kuruluş adı, proje başlığı ve baş iletişim kişisi gibi yeterli bilgileri görmesi gerekir. Portal yanıtı tarih ve saat bilgisiyle kaydetmelidir.

Bir değerlendirici çıkar çatışması bildirirse hibe yöneticisi atamayı hızla kaldırmalı ve başka bir nitelikli değerlendirici seçmelidir. Çıkar çatışması bulunan kişiyi başvurudan, yorumlardan, puanlardan ve kurul materyallerinden uzak tutun.

Bu yaklaşım, değerlendiricinin ikna edici bir teklifi okuduktan sonra başvuru sahibini tanıdığını fark ettiği rahatsız edici durumu önler. Ayrıca özel bütçelere, iletişim bilgilerine veya eklere yanlışlıkla erişilmesini de engeller.

Ekibin kontrol edebileceği bir kayıt tutun

Her bildirimi değerlendirme dönemi, değerlendirici adı, başvuru, yanıt, açıklama ve nihai işlemle birlikte saklayın. Bir yönetim kurulu üyesi atamanın neden değiştiğini veya bir başvuru sahibi sürecin adilliğini sorguladığını sorduğunda ekibin bu kayda ihtiyacı olur.

Dahili günlük, ekibin bildirimi istediği tarihi, değerlendiricinin yanıtını, bildirilen bağlantıyı, ekip kararını, yerine atanan değerlendiricinin adını ve sonraki güncellemeleri içermelidir. Değerlendiriciler bağlantıyı daha sonra fark ederse okumayı bırakmalı, hibe yöneticisine haber vermeli ve talimat beklemelidir.

İnsanların tutarlı biçimde uygulayacağı puanlama ölçütleri oluşturun

Değerlendirici puanlama ölçütleri vakfın yayımlanmış öncelikleriyle örtüşmelidir. Bir fon gençlerin sanata erişimini destekliyorsa toplum erişimi ve gerçekçi bir uygulama planı, parlak yazı dilinden daha fazla ağırlık taşımalıdır.

Ölçütleri sınırlı tutun. Beş net ölçüt, değerlendiricilerin aceleyle tamamladığı uzun bir listeden genellikle daha iyi kararlar doğurur. Nihai toplamın vakfın önceliklerini yansıtması için her birine ağırlık verin.

Örneğin küçük bir vakıf başvuruları şu başlıklarda puanlayabilir:

• Fonun amacıyla uyum: %30
• Hizmet verilen kişiler için beklenen fayda: %25
• Planın ve bütçenin uygulanabilirliği: %20
• Başvuru sahibinin işi yürütme kapasitesi: %15
• Fon ihtiyacı ve kesinleşmiş diğer destekler: %10

Her puan için sade etiketler kullanın. Her sayının kısa bir açıklaması olduğunda 1 ila 5 arası ölçek iyi çalışır. 1, başvurunun ölçütü karşılamadığı; 3, yeterli biçimde karşıladığı; 5 ise güçlü ve iyi desteklenmiş bir gerekçe sunduğu anlamına gelebilir.

Açıklama olmadan «mükemmel» veya «zayıf» gibi etiketler kullanmayın. Bu tür etiketler kişisel yoruma açıktır. Uygulanabilirlikte en yüksek puan, net kilometre taşları, işi yürütecek sorumlu kişilerin adları ve anlatılan çalışmayla uyumlu bir bütçe gerektirebilir.

Her puanın yanına bir yorum alanı koyun. Değerlendiricilerden başvurudaki kanıtlara, örneğin izleyici sayısına, kesinleşmiş bir ortağa veya eksik bir maliyete atıfta bulunmalarını isteyin. Bu notlar onay grubunun toplam puanı anlamasına ve başvuru sahipleri geri bildirim istediğinde ekibin bir kayda sahip olmasına yardımcı olur.

Hibe değerlendirme portalı ağırlıklı toplamları otomatik hesaplayabilir. Böylece ekip rakamları elektronik tablolar arasında kopyalamak zorunda kalmaz. Toplam, görüşmeye yön vermeli ancak sonucu tek başına belirlememelidir. İki teklif aynı puanı alabilir, fakat biri acil bir yerel ihtiyacı karşılayabilir veya mevcut hibe alanlar arasındaki bir boşluğu doldurabilir.

Nihai onayı bireysel puanlamadan ayrı tutun. Onay grubu puanları, yorumları, çıkar çatışmalarını ve bütçe sınırlarını birlikte inceleyip her ödül veya ret için kısa bir gerekçe kaydedebilir. Bu, karar mektuplarını hazırlamayı kolaylaştırır.

Örnek: yerel bir sanat fonunun değerlendirme dönemi

Yerel bir sanat fonu toplum projeleri için küçük bir hibe dönemi açar. Fonun bütçesi 40.000 ABD dolarıdır ve 28 başvuru alır. Her başvuru sahibi aynı formu doldurur: proje özeti, toplumsal fayda, bütçe, takvim, ekip bilgileri ve talep edilen tutar. Portal gönderimden önce eksik alanları işaretler, böylece ekip daha sonra temel bilgilerin peşine düşmez.

Son tarihten sonra hibe koordinatörü uygunluğu kontrol eder. Dört başvuru fonun coğrafi alanının dışındadır. Koordinatör nedeni kaydeder ve bu başvuruları değerlendirmeden çıkarır. Kalan 24 başvuru hibe başvuru iş akışında ilerler.

Koordinatör her başvuruya iki değerlendirici atar. Bir değerlendirici gençlik tiyatrosu projesi için atamayı açtığında kardeşinin tiyatronun yönetim kurulunda olduğunu görür. Çıkar çatışması bildirimi yapar, bağlantıyı açıklar ve atamayı reddeder. Portal erişimini kaldırıp koordinatörü uyarır; koordinatör de başka bir değerlendirici atar.

Değerlendiriciler aynı puanlama ölçütlerini kullanır. Toplumsal faydayı, sanatsal niteliği, uygulama planının gerçekçiliğini ve bütçeyle uyumu beş üzerinden puanlar, ardından kısa yorumlar ekler. Tiyatro projesinde bir değerlendirici 20 üzerinden 17 puan verir ve yerel talebin güçlü olduğunu, ancak beklenmeyen gider bütçesinin yetersiz kaldığını belirtir. Diğeri 14 puan verir ve takvimin iddialı olduğunu söyler.

Karar toplantısında grup her iki puanı, yorumları, talep edilen 8.000 ABD dolarını ve proje belgelerini birlikte görür. Desteği onaylar, ancak bütçenin daha net bir alternatif plan gerektirmesi nedeniyle ödülü 6.500 ABD dolarına indirir.

Koordinatör şu kaydı oluşturur: onaylandı, 6.500 ABD doları, gerekçe: «Güçlü toplumsal fayda ve yetkin ekip; azaltılan tutar bütçe riskini yansıtıyor.» Ekip bu kaydı karar mektubu ve sonraki sorular için kullanabilir; toplantı notlarına veya hafızaya güvenmesi gerekmez.

Adil olmayan veya geciken kararlara yol açan hatalar

Değerlendiriciler kendilerine hiç verilmeyen bilgileri değerlendirmek zorundaysa portal süreci düzeltemez. Değerlendiricilerin toplum erişimini puanlaması gerekiyorsa başvuru formunda kitle, konum ve beklenen katılımcı sayısıyla ilgili net bir soru bulunmalıdır. Aksi halde değerlendiriciler boşlukları tahminlerle doldurur ve başvuru sahipleri tutarsız muamele görür.

Bir dönem başlamadan önce her ölçütü formla karşılaştırın. Her puan, değerlendiricilerin okuyabileceği bir yanıta, eke veya bütçe alanına dayanmalıdır. Portal bu bağlantıyı açıkça göstermeli, böylece değerlendiriciler ilgili ayrıntıları sayfalar arasında aramak zorunda kalmamalıdır.

Gizli veriler başka bir yaygın sorundur. Değerlendiricilerin proje planlarına ve bütçelere ihtiyacı olabilir, ancak banka bilgilerine, kişisel adreslere, dahili ekip notlarına veya diğer değerlendiricilerin yorumlarına ihtiyaçları olmayabilir. Erişimi role göre sınırlayın ve hassas alanları standart değerlendirme görünümünün dışında tutun.

Puan değerlerini, tanımları veya geçer puanın anlamını puanlama başladıktan sonra değiştirmeyin. Ekip bir ölçütün belirsiz olduğunu fark ederse sorunu kaydedin ve ölçütleri sonraki dönem için düzeltin. Ciddi bir hata değişiklik gerektiriyorsa dönemi durdurun, tüm değerlendiricileri bilgilendirin ve daha önce gönderilen puanların nasıl ele alınacağını belgeleyin.

Onaydan önce her atanmış değerlendiricinin puan gönderdiğini veya çekimserlik kaydettiğini, ekibin puanları kullanmadan önce çıkar çatışmalarını çözdüğünü ve onaylayanın nihai kararı, tutarı ve koşulları kaydettiğini doğrulayın. Mektubun onaylanan kayıtla, başvuru sahibi adı ve proje başlığı dahil, eşleştiğini de kontrol edin.

Onay ayrıntıları e-postalarda veya toplantı notlarında kaldığı sürece karar mektupları göndermeyin. Nihai kayıt kararı kimin, ne zaman onayladığını ve hangi bütçe veya başvuru sürümünü incelediğini göstermelidir. Bir komite koşullu olarak 7.500 ABD dolarını onayladıysa mektup önceki taslağı değil, bu tutarı ve koşulu belirtmelidir.

Karar mektuplarını göndermeden önce kayıtları kontrol edin

Karar mektupları son dakika elektronik tablo düzenlemesini değil, eksiksiz bir kaydı yansıtmalıdır. Mektupları yazmadan önce program yöneticisi karar toplantısı notlarını hibe değerlendirme portalındaki kayıtlarla karşılaştırmalıdır.

Her başvurunun bir ekip sorumlusu ve mevcut bir durumu olmalıdır: değerlendirmede, onaylandı, reddedildi veya bilgi bekleniyor. Sorumlusu belirtilmemiş onaylı bir başvuruda ödeme kurulumu veya başvuru sahibi takibi aksayabilir.

Notları mektuba dönüştürmeden önce çıkar çatışması olmayanlar dahil her değerlendiricinin bildirim yaptığını kontrol edin. Geciken atamaları inceleyin ve ekibin değerlendiriciyi değiştirip değiştirmediğini, son tarihi uzatıp uzatmadığını veya tamamlanmamış değerlendirmeyi dışarıda bırakıp bırakmadığını kaydedin. Puanlarla yazılı notları nihai kararla karşılaştırın, ardından onaylanan her tutarı, koşulu ve ödeme tarihini mektupla eşleştirin.

Çıkar çatışması kayıtları sonucu değiştirmemiş olsa bile önemlidir. Bir değerlendirici kenara çekildiyse bu kaydı başvuruyla birlikte saklayın ve başka bir uygun değerlendiricinin değerlendirmeyi tamamladığından emin olun.

Kısmi ödülleri iki kez kontrol edin. Kurul 12.000 ABD doları talep edilen bir başvuru için 8.000 ABD doları önerebilir, ancak kopyalanmış bir taslak hâlâ tam tutarın onaylandığını gösterebilir. Ekip sorumlusu rakamı karar kaydıyla doğrulamalı, ardından başka bir ekip üyesi mektubu göndermeden önce okumalıdır.

Bu son inceleme yanlış kuruluş adı, güncel olmayan proje başlığı veya reddedilen başvuru sahibine gönderilen onay dili gibi hataları da yakalar. Birkaç dakika sürer ve daha sonra yapılacak zor düzeltmeleri önler.

Açık ve net karar mektupları gönderin

Karar mektubu onaylanan kayıtla tam olarak eşleşmelidir. Başvuru sahibi adını, proje adını, kararı, ödül tutarını, ödeme tarihini ve koşulları hibe değerlendirme portalından alın. Ekip bu ayrıntıları hafızadan yeniden yazmamalı veya eski bir e-postadan kopyalamamalıdır.

Ödüller, retler ve daha fazla bilgi talepleri için ayrı şablonlar kullanın. Her birinin farklı bir tonu ve sonraki adımı vardır. Reddedilen başvuru sahibi net bir yanıt almalıdır. Ödül alan başvuru sahibi pratik talimatlara ihtiyaç duyar. Kaydı eksik olan başvuru sahibi neyi ve ne zamana kadar göndermesi gerektiğini bilmelidir.

Ödül mektubunda onaylanan tutarı ve amacı sade bir dille belirtin. Raporlama son tarihlerini, başvuru sahibinin doğrulaması gereken ödeme ayrıntılarını ve koşulları ekleyin. «Fon sağlanabilir» gibi belirsiz ifadelerden kaçının. Karar onaylanmış, reddedilmiş veya daha fazla bilgi bekliyor olmalıdır.

Göndermeden önce bir ekip üyesi başvuru sahibi ve proje adlarını, ödül tutarını ve para birimini, son tarihleri, ödeme tarihlerini, koşulları, ekleri ve talimatları onaylanan kayıtla karşılaştırmalıdır.

Ret mektupları saygılı ve kısa olmalıdır. Başvuru sahibi başvurusu için teşekkür edin, vakfın bu dönemde teklifi finanse etmeyeceğini belirtin ve yeniden başvurup başvuramayacağını açıklayın. Ekip bireysel geri bildirim vermeyi kararlaştırmadıysa böyle bir söz vermeyin.

Daha fazla bilgi taleplerinde kesin bir son tarih ve eksik maddelerin basit bir listesi bulunmalıdır. Vakfın revize bütçeye ve kâr amacı gütmeyen kuruluş statüsü kanıtına ihtiyacı varsa her iki belgeyi de adlandırın ve başvuru sahibinin bunları nasıl göndereceğini açıklayın.

Gönderdikten sonra nihai mektubu ve ekleri başvuru kaydıyla birlikte saklayın. Gönderim tarihini, gönderen kişiyi ve kullanılan şablonu kaydedin. Ortak geçmiş, ekibin takip sorularını yanıtlamasına ve başvuru sahibi bir karara itiraz ederse eksiksiz bir dosya sunmasına yardımcı olur.

Vakfınız için sonraki adımı seçin

Her hibe sürecini aynı anda yeni bir portala taşımak yerine tek bir fonlama programıyla başlayın. Yönetilebilir sayıda başvurusu ve küçük bir değerlendirici grubu olan bir dönem seçin. Böylece ekip belirsiz soruları, eksik durum güncellemelerini veya değerlendiricilerin farklı yorumladığı ölçütleri fark edebilir.

Başvurular açılmadan önce tüm yolu kurun: form, uygunluk kontrolleri, değerlendirici atamaları, çıkar çatışması bildirimleri, puanlama, kurul notları, kararlar ve mektuplar. Başvuru sahipleri değerlendirici notlarını, değerlendiriciler de süreç izin verene kadar birbirlerinin puanlarını görmemelidir.

İlk dönemden sonra başvuru sahiplerinden, değerlendiricilerden ve ekipten somut geri bildirim isteyin. Başvuru sahipleri formun anlaşılır ve güncellemelerin yararlı olup olmadığını söyleyebilir. Değerlendiriciler bağlamı eksik soruları veya anlaşmazlığa yol açan ölçüt ifadelerini belirleyebilir. Ekip hâlâ hangi işlerde elektronik tabloya veya e-postaya ihtiyaç duyduğunu görebilir.

Geri bildirimleri kullanarak kararları etkilemeyen form alanlarını kaldırın, belirsiz puanlama açıklamalarını yeniden yazın, geciken değerlendirme ve onaylar için hatırlatmalar ekleyin, durumları veya mektupları kimin değiştirebileceğini netleştirin ve onaylanmış şablon dilini kaydedin.

İlk kurulumu kalıcı kabul etmeyin. Her ihtiyacı önceden tahmin etmeye çalışmak yerine gerçek kullanımın ardından süreci geliştirin.

Koder.ai ile oluşturulan özel bir portal başvuruları, değerlendirici atamalarını, çıkar çatışması bildirimlerini, puanları, kararları ve mektupları tek bir ortak çalışma alanında tutabilir. Ekipler iş akışlarını sade bir dille anlatabilir ve program değiştikçe portalı geliştirebilir. Koder.ai kaynak kodu dışa aktarmayı da destekler; böylece vakıf oluşturduğu uygulamanın kontrolünü elinde tutar.

Bir sonraki dönemi net sorumluluklarla, test edilmiş değerlendirici puanlama ölçütleriyle ve her kararın kaydıyla yürütün. Başvuru sahipleri daha tutarlı bir deneyim yaşar, ekip de son tarihe yaklaşırken daha az dağınık dosyayı birleştirmek zorunda kalır.