03 Şub 2026·7 dk
Kârlı Kalan Ajanslar İçin Sabit Kapsamlı Yapay Zeka MVP Teklifleri
Ajansların marjlarını koruyarak sabit kapsamlı Yapay Zeka MVP teklifleri satmayı öğrenin: net keşif, revizyon sınırları, fiyatlandırma ve teslim adımları.
Ajansların marjlarını koruyarak sabit kapsamlı Yapay Zeka MVP teklifleri satmayı öğrenin: net keşif, revizyon sınırları, fiyatlandırma ve teslim adımları.
Yapay Zeka geliştirme süresini hızla kısaltabilir. Ancak müşteri tereddüdünü, değişen öncelikleri veya belirsiz geri bildirimleri azaltmaz. Bu boşluk, hızlı projelerin yine de yavaş, düşük marjlı işe dönüşmesinin nedenidir.
Net bir fikir, geleneksel süreçlere göre çok daha hızlı bir MVP'ye dönüşebilir. Sorun şu ki hız, müşteri beklentilerini değiştirir. Değişiklikleri hızlı görürlerse, değişikliklerin sınırsız olması gerektiğini varsayarlar. Genellikle kârın sızmaya başladığı yer burasıdır.
Gevşek bir brief küçük bir MVP'yi kimsenin açıkça söylemediği bir özel yazılıma dönüştürür. Müşteri "basit bir portal" ile başlar, sonra roller, raporlar, faturalama, mobil görünümler ve yönetici araçları ister. Her istek küçük görünür; birlikte bakıldığında tek bir ücret içinde beş proje haline gelir.
Revizyonlar da sessiz bir marj katilidir. İlk tur genellikle gerçek sorunları düzeltir. Üçüncü veya dördüncü tura gelindiğinde geri bildirim genellikle işlevden çok tercihle ilgilidir. Ekibiniz ekranları, akışları ve mantığı sınırlı bir şekilde yeniden inşa etmeye devam ederse, Yapay Zeka ile kazanılan zaman yeniden çalışmayla yutulur.
Çoğu sabit teklif aynı yerlerde bozulur. Keşif notları genel kalır, başarı kriterleri yazılmaz, geri bildirim açık uçlu muamelesi görür ve teslim maddeleri ima edilir yerine listelenir.
Teslim, belirsiz kapsamın pahalı olduğu yerdir. Müşterinin ne aldığı açıkça yazılmamışsa, cilalanmış dokümantasyon, eğitim, dağıtım yardımı, kod temizliği ve lansman sonrası destek gibi şeyleri aynı işin parçası olarak bekleyebilirler. Yapı tamamlanmış olabilir, ama proje hâlâ bitmemiş gibi hissedilir.
Yaygın bir örnek şöyledir: bir ajans bir haftada bir MVP müşteri portalı teslim eder. Uygulama çalışır ama müşteri yönetici kuralları, markalı e-postalar ve ekipleri için bir yürütme bekliyordu. Bunların hiçbiri kapsam dahilinde değildi. Ajans ya hayır diyerek sürtüşme yaratır ya da evet diyerek marjı hediye eder.
Hızlı teslim ancak sınırlar net olduğunda işe yarar. Kapsam ne kadar sıkıysa, hızı kârlı tutmak o kadar kolaydır.
Sabit paket için en iyi MVP'ler tek bir küçük problemi tek bir net kullanıcı akışıyla çözenlerdir. Basit bir test yardımcı olabilir: müşteri ürünü bir cümleyle açıklayabiliyor mu? Örneğin "Bir kullanıcı bir talep gönderir, ekip inceler ve her iki taraf da durumu takip eder" gibi bir tanım genellikle uyar. Fikir çok fazla rol, çok sayıda istisna veya belirsiz iş kuralları gerektiriyorsa muhtemelen çok geniştir.
En güvenli MVP'ler bir ana eylem ve bir bariz sonuç içerir. Bir müşteri portalı, intake aracı, rezervasyon akışı, dahili onay uygulaması veya basit bir pano genellikle iyi çalışır çünkü insanların "bitti"nin ne olduğuna dair ortak bir fikri vardır. Bu, işi tahmin etmeyi ve onaylamayı kolaylaştırır.
İlk versiyonun amacı müşterinin ileride isteyebileceği her şeyi inşa etmek değildir. Amaç bir iş fikrini hızlıca test etmektir. Kullanıcı formu tamamlayacak mı? Personel zaman kazanacak mı? Müşteriler destek e-postalarını bırakıp self-servisi kullanacak mı?
Sabit bir teklif genellikle şu koşullarda iyi uyar:
Derin entegrasyonlar kârın genellikle kaybolduğu yerlerdir. MVP eski bir CRM, ERP, özel ödeme mantığı veya birkaç dış API'ye bağlıysa, küçük sürprizler hızla ekstra işe dönüşür. Sabit pakette genellikle formlar, bildirimler, dosya yükleme ve belki bir hafif entegrasyon sunmak daha güvenlidir.
Bir tasarım standardı da belirleyin. Her sayfada özel tasarım çalışması yerine tutarlı bileşenlerle temiz, kullanılabilir bir arayüz ve mobil uyumlu ekranlar sunun. Bu tür tekrarlanabilir yapı hızlı teslimatı pratik kılar.
Tekrarlanabilir bir keşif süreci, hızlı yapıların uzun, dağınık projelere dönüşmesini engeller. Her potansiyel müşteri aynı temel soruları yanıtlıyorsa, zayıf fikirleri erken fark eder, daha sıkı kapsam yazabilir ve marjınızı korursunuz.
Her potansiyel müşteri için tek bir intake formu ile başlayın. Formu insanların bitirebileceği kadar kısa, fakat size kullanılabilir gerçekler verecek kadar sıkı tutun. Amacınız her fikri toplamak değil, inşa etmeye değer en küçük versiyonu bulmaktır.
Müşteriden üç şeyi tanımlamasını isteyin:
Bu basit filtre birçok gereksiz ayrıntıyı ortadan kaldırır. "Müşterilerimiz için bir portal" belirsizdir. "Bir müşteri giriş yapar, bir belge yükler ve onay durumunu kontrol eder" ise kapsamlanabilir bir şeydir.
Özellikleri iki gruba ayırın: olmazsa olmazlar ve olsa iyi olur dedikleriniz. Katı olun. Bir özellik ilk kullanıcının ana problemi çözmesine yardımcı olmuyorsa, büyük olasılıkla ikinci faza aittir. Faydalı bir kural şudur: ürün birinci gün olmadan da çalışıyorsa, o özellik olmazsa olmaz değildir.
Başlangıçtan önce müşterinin sağlaması gerekenleri yazın. Bu genellikle marka varlıkları, metinler, örnek veri, yasal metinler, alan adı erişimi ve karar verebilecek kişileri içerir. Eksik girdiler, inşa süresinden daha sık projeleri geciktirir.
Koder.ai kullanıyorsanız, bu keşif notları doğrudan planlama moduna geçip inşanın başlangıç noktası haline gelebilir. Bu satıştan üretime devri çok daha temiz yapar.
İyi bir keşif çıktısı bir sayfaya sığmalıdır. MVP'yi açıklamak uzun bir çağrı ve devasa bir belge gerektiriyorsa, kapsam hâlâ çok gevşektir.
İyi bir kapsam, muallak bir vaat değil bitmiş ürünün resmi gibi okunur. Müşteri işe başlamadan önce "Evet, tam olarak bunu alıyorum" diyebilmelidir.
Bunu yapmanın en kolay yolu MVP'yi sade dille tanımlamaktır: hangi ekranları içerdiği, her ekranda kullanıcıların ne yapabileceği, nelerin dahil olmadığı ve sonunda müşterinin ne alacağı.
Dahil edilen ekranları ve her birindeki ana eylemi isimlendirerek başlayın. Somut olun.
"Temel müşteri portalı" demek yerine şöyle yazın:
Bu, müşteriye hayal edebileceği bir şey verir. Ayrıca sohbet, faturalama, gelişmiş izinler veya yerel mobil uygulamalar gibi gizli varsayımlara karşı ekibinizi korur.
Sonra kısa bir kapsam dışı notu ekleyin. Bu, dahil edilen iş kadar önemlidir. "Ödeme işlemleri, özel entegrasyonlar, çoklu dil desteği veya yerel mobil uygulamalar dahil değildir" gibi bir satır saatlerce sürebilecek tartışmaları önleyebilir.
Ayrıca "tamamlandı"nın ne anlama geldiğini tanımlayın. Tona değil işlevselliğe odaklanın. Bir ekran, üzerinde anlaşılmış akış çalıştığında, veriler doğru şekilde kaydedildiğinde ve düzen onaylanan yönle lansans için yeterince yakın olduğunda tamamlanmış sayılır.
Müşteriler aynı zamanda projeyi bitirdiğinizde ne alacaklarını bilmek ister. Basit ve spesifik tutun. İyi bir teslim şu maddeleri içerebilir: canlı MVP, kaynak kodu dışa aktarma, bir yürütme çağrısı, giriş bilgileri ve temel içeriğin nasıl düzenleneceğine dair kısa bir not.
Koder.ai üzerinde inşa ediyorsanız, dağıtım, barındırma, özel alan adı kurulumu, anlık görüntüler veya geri alma seçeneklerinin teklifin parçası olup olmadığını netleştirin. Platform bu seçenekleri destekler; ancak hangi seçeneklerin teklifinize dahil olduğunu müşteri bilmelidir.
Müşteri iki dakikada kapsamınızı okuyup bir cümleyle tekrar edebiliyorsa, muhtemelen yeterince nettir.
Hızlı yapılar, geri bildirim açık uçlu kaldığında para kaybeder. Sabit bir teklifin kârlı kalmasını istiyorsanız, revizyon kuralları ilk prompt, mockup veya inşa adımı başlamadan önce belirlenmelidir.
Basit bir kural iyi çalışır: faz başına bir veya iki inceleme turu izin verin; tüm proje boyunca sınırsız geri bildirim değil. Örneğin; wireframeler için bir tur, çalışan MVP için bir tur ve teslim öncesi son bir tur verebilirsiniz. Bu, kararları hareketli tutar ve eski tartışmaların geç açılmasını engeller.
Her revizyonu onaylı kapsamla ilişkilendirin. Müşteri giriş, hesap görünümü ve basit yönetici erişimi içeren bir portalı onayladıysa, buton metnini değiştirmek veya bir form alanını taşımak revizyondur. Ekip izinleri, faturalama veya mobil uygulama isteği ise yeni iştir.
Farkı yazılı olarak açık hale getirin:
Projeye başlamadan önce ekstra turların fiyatını belirleyin. Bu sabit bir ücret, saatlik oran veya yaygın değişiklikler için sabit bir eklenti olabilir. Önemli olan kimsenin şaşırmamasıdır.
Kısa bir örnek uygulamayı zorlaştırmadan uygulatır. Ekibiniz Koder.ai'de bir MVP inşa etti ve müşteri incelemeden sonra metin güncellemeleri istiyorsa bu revizyon limitine girer. Eğer ikinci bir kullanıcı tipi ve yeni bir onay iş akışı istiyorsa, bu bir değişiklik emrini gerektirir.
Açık sınırlar her iki tarafı da korur. Müşteri geri bildirimin nasıl işlediğini bilir ve ekibiniz küçük bir MVP'yi sonsuz bir yeniden yazıya dönüştürmeden hızla ilerleyebilir.
Hızlı bir proje, ilk çağrıdan teslimata kadar temiz bir yol gerekir. Kâr genellikle daha az gecikme, daha az sürpriz ve daha az yeniden işten gelir.
Keşifle başlayın ama dar tutun. Müşterinin bütün işini haritalamıyorsunuz; bir soru cevaplıyorsunuz: bu problem tek bir net kullanıcı akışı, tek bir hedef kitle ve kısa bir olmazsa olmaz özellik listesiyle küçük bir MVP ile çözülebilir mi?
Bundan sonra kısa bir kapsam ve tek bir sabit fiyat gönderin. Basit tutun: ne inşa edeceksiniz, ne inşa etmeyeceksiniz, neyin "tamam" sayılacağı ve kaç inceleme turu dahil. Müşteri bunu yazılı olarak kabul edemiyorsa, proje hazır değil demektir.
Sonra çekirdek akışı önce inşa edin. MVP bir müşteri portalıysa bu genellikle giriş, pano ve bir ana eylem (örneğin bir talep gönderme veya bir kaydı görüntüleme) anlamına gelir. Olsa iyi olur fikirleri bekleyebilir.
Çekirdek akış çalıştıktan sonra incelemeye geçin. Müşteriden orijinal kapsamı temel alarak test etmesini isteyin, haftalık sırasında ortaya çıkan her yeni fikre göre değil. İnceleme penceresini kısa ve spesifik yapın. Bozuk olanı düzeltin, net olmayanı iyileştirin ve sonra sürümü kilitleyin.
Teslim tamamlanmış hissettirmeli, acele edilmiş olmamalı. Müşteriye temel gereçleri tek bir paket halinde verin:
Bu son adım şimdi marjınızı korur ve sonraki ücretli fazı satmayı kolaylaştırır.
Hızlı inşa süresi marjınızı iyileştirmeli, sizi daha az ücret almaya zorlamamalıdır. Bir MVP'nin fiyatı yalnızca üretim zamanını değil; müşteri gecikmelerini, belirsiz geri bildirimleri, testleri, küçük düzeltmeleri ve beklenenden uzun sürebilecek görevlerin riskini de karşılamalıdır.
İyi bir kural riske göre fiyatlandırmaktır, sadece saate göre değil. Bir projenin 12 saat süreceğini düşünüyorsanız, yalnızca o 12 saati fiyatlamayın. QA, proje yönetimi ve normal temizleme için alan bırakın. Hız, müşterinin satın aldığı değerin bir parçasıdır.
Küçük bir pay, bir projeyi ücretsiz işe dönüşmekten korur. Birçok ajans teste ve yeniden çalışmaya %15-30 arasında bir ek koyar; özellikle uygulama giriş, formlar, ödemeler veya dış araçlar içeriyorsa. Bu tampon genellikle sorunsuz bir iş ile stresli bir iş arasındaki farktır.
Basit bir fiyat yapısı genellikle en iyisidir:
Bu, teklifi anlaşılmasını kolay tutar ve ana kapsamı genişletmeden anlaşma boyutunu büyütmenize alan verir.
Örneğin bir ajans giriş, pano ve tek bir iş akışını içeren bir müşteri portalı MVP'sini sabit ücretle satabilir. Müşteri sonra Stripe bağlantısı, özel marka tasarımı veya yönetici raporlaması isterse bunlar sürpriz görevler yerine ücretli eklentiler olur.
Hızlı bir platformla (Koder.ai gibi) inşa etseniz bile aynı disiplin geçerlidir. Daha hızlı üretim inceleme süresini, testi veya müşteri iletişimini ortadan kaldırmaz.
Her projeden sonra tahmini gerçek saatlerle karşılaştırın. Zamanın nereye gittiğini takip edin: keşif, inşa, revizyonlar, düzeltmeler ve teslim. Birkaç projeden sonra fiyatlama hataları belirginleşir.
Küçük bir ajans, hukuk, muhasebe veya danışmanlık firması için 2 haftalık bir müşteri portalı MVP'si satabilir; ihtiyaç tek bir temiz yerde müşteri güncellemeleri almaktır. Vaad basittir: hızlıca kullanılabilir bir ilk sürüm, neyin dahil olduğuna dair net bir sınırla.
Bu, sabit teklifin satılmasını kolaylaştırır. Müşteri "iki haftada ne sığarsa" satın almıyor; tanımlanmış bir sonucu satın alıyor.
Keşif sırasında ajans briefi sıkı tutar. Her fikri toplamak yerine inşayı giriş, pano ve birkaç formla sınırlar. Bu, müşteriye çalışan bir portal verirken projeyi özel yazılım planına dönüştürmez.
Tipik bir kapsam şunları içerebilir:
Geri kalan her şey sonraya bırakılır: ödemeler, karmaşık izinler, sohbet, derin raporlama ve üçüncü taraf entegrasyonları. Bu istekler not edilir ama birinci sürüm zamanında kalması için ikinci faz fikirleri olarak etiketlenir.
Demo sonrası teklif iki revizyon turu içerebilir. Ajans bunları net tanımlamıştır. Birinci tur içerik düzenlemeleri, küçük düzen değişiklikleri ve form alanı güncellemelerini kapsar. İkinci tur son ciladır. Yeni özellikler revizyon sayılmaz.
Teslim de aynı şekilde nettir. Müşteri kaynak dosyalarını, kısa lansman notlarını ve inşa sırasında ortaya çıkan sonraki faz önerilerini alır. MVP Koder.ai'de inşa edilmişse teslim ayrıca dışa aktarılmış kodu ve onaylı sürümün bir anlık görüntüsünü içerebilir.
Bu yapı projeyi müşteri için hızlı, ajans için kârlı kılar.
Sabit kapsamlı bir projede para kaybetmenin en hızlı yolu her küçük müşteri talebini zararsız görmekten geçer. Bir ekstra alan, bir kullanıcı rolü, yeni bir pano kartı — her biri kendi başına küçük görünür. Bir araya geldiklerinde temiz bir MVP'yi hiç fiyatlamadığınız özel işe dönüştürürler.
Sabit teklif ancak ekip neyin dahil olduğunu ve neyin dahil olmadığını güvenle söyleyebildiğinde çalışır. Müşteri kapsamı yazılı onaylamadan önce inşaya başlandığında bu çok daha zor olur. Keşif notları hâlâ belirsizse, inşa aşaması pahalı varsayım işine dönüşür.
Tekrarlayan olarak görülen birkaç sorun şunlardır:
Hata düzeltme sorunu özellikle maliyetlidir. Giriş butonu çalışmıyorsa bu bir düzeltmedir. Müşteri şimdi sosyal giriş istiyorsa bu yeni bir özelliktir. Ekipler bu çizgiyi bulanıklaştırdığında revizyon turları genişler ve marjlar kaybolur.
Entegrasyonlar başka bir tuzaktır. Müşteri bir CRM, ödeme aracı veya dahili veritabanı bağlanmasını küçük bir eklenti sanabilir. Uygulamada entegrasyonlar genellikle ekstra eşleme, hata yönetimi, izinler ve lansman sonrası destek gerektirir. Bu, zaten standartlaştırılmamışsa sabit paket için nadiren iyi bir uyumdur.
Teslim adımı birçok ajansın kâr geri vermesine neden olur. Kısa bir yazılı kontrol listesi yardımcı olur: ne teslim edildi, hangi kimlik bilgileri paylaşıldı, ne destek olarak sayılır ve ne yeni bir teklif gerektirir. İnşa hızı önemli, ama net sınırlar daha da önemlidir.
Sabit teklif, temel maddeler öneri çıkmadan önce netleştiğinde çalışır. Müşteri hâlâ problem, kullanıcı veya istedikleri sonuç konusunda belirsizse, proje ücretli tahmine dönüşür.
O üç noktayı sade bir dille yazın: bu kim için, hangi acıyı çözüyor ve ilk versiyonda başarı nasıl görünür. Müşteri bu özete katılamıyorsa, kapsam hazır değildir.
Paketi sunmadan önce birkaç şeyi kontrol edin:
Son madde çoğu ajansın kabul ettiğinden daha önemlidir. Hızlı inşa araçları teslim süresini kısaltabilir, ama inceleme döngülerini, müşteri gecikmelerini veya beklenmedik düzeltmeleri ortadan kaldırmaz. Kârınız bir adım kaydığında yok oluyorsa, teklif çok sıkı fiyatlanmıştır.
Basit bir stres testi yardımcı olur. Müşteri bir ekstra gözden geçirme çağrısı ister, metin iki gün gecikir ve son QA beklediğinizden yarım gün fazla sürer diye hayal edin. Eğer proje hâlâ mantıklıysa, paket muhtemelen sağlıklıdır.
Zaten teslim etmiş olduğunuz bir MVP ile başlayın. Açık hedefi, az sürprizi ve bir cümlede anlatılabilecek sonucu olan bir projeyi seçin. Bu genellikle özel işi tekrar edilebilir sabit bir teklife dönüştürmenin en kolay yoludur.
Her şeyi bir anda paketlemeye çalışmayın. Önce bir müşteri türü seçin: yerel hizmet işletmeleri, koçlar, küçük SaaS ekipleri veya dahili operasyon araçları gibi. Dar bir hedef kitle keşfi hızlandırır, kapsamı açıklamayı kolaylaştırır ve fiyatlamayı daha az riskli kılar.
İlk paketiniz sadece dört soruya cevap vermeli:
Sonra tekrarladığınız parçaları saklayın. Kısa bir keşif formu, kapsam şablonu, revizyon politikası ve teslim kontrol listesini tek bir yerde tutun. Amaç süreci gösterişli hale getirmek değil; aynı belgeleri her seferinde yeniden yazmayı bırakmaktır.
Küçük bir pilot en güvenli testtir. Teklifi bir müşteriye satın, teslim edin ve nerede süre kaybedildiğini not edin. Belki içerik geç geldi. Belki onaylar beklenenden uzun sürdü. Belki müşteri teslimat sırasında daha fazla yardıma ihtiyaç duydu. Bu boşluklar tekrar satmadan önce neyi sıkılaştırmanız gerektiğini gösterir.
Koder.ai kullanıyorsanız, birkaç yerleşik özellik teklifi disiplinli tutmaya yardımcı olabilir. Planlama modu işe başlamadan önce faydalıdır, anlık görüntüler büyük revizyonlardan önce işe yarar ve kaynak kodu dışa aktarımı teslimatı temizler; müşteri daha sonra kendi ekibini devralmak isterse bu işe yarar.
İlk pilot sonrası şablonlarınızı hemen güncelleyin. Bir temiz, tekrarlanabilir teklif beş belirsiz olandan daha değerlidir. Dar tutun, bitiş çizgisini belirgin hale getirin ve gerçek müşteri teslimine dayanmadan paketi geliştirmeyin.
Küçük bir ürün, bir ana kullanıcı, bir net akış ve belirgin bir sonuç olan MVP'ler iyi uyum sağlar. Müşteri portalları, intake form uygulamaları, rezervasyon akışları veya basit panolar genellikle çok rolü, uç durumları veya belirsiz kuralları olan ürünlerden daha kolay kapsamlandırılabilir ve onaylanabilir.
Sınırı işe başlamadan önce belirleyin, inceleme sırasında değil. Dahil edilen ekranları, ana işlemleri, revizyon limitini ve kapsam dışı maddeleri sade bir dille yazın; ardından yeni talepleri orijinal ücrete eklemek yerine ücretli bir değişiklik olarak ele alın.
Her faz için genellikle bir veya iki tur yeterlidir. Bu, müşterinin gerçek sorunları düzeltmesine olanak tanırken projeyi sonsuz tercih değişikliklerine dönüşmekten korur.
Bitmiş ürünü müşterinin hayal edebileceği şekilde tanımlayın. Ekranları adlandırın, her birinin ne yaptığını açıklayın, “tamamlanmış” ne demek olduğunu tanımlayın ve gizli varsayımların ücretsiz işe dönüşmemesi için nelerin dahil olmadığını belirtin.
MVP'nin bir legacy CRM, ERP, özel ödeme akışı veya birkaç dış API'ye bağımlı olduğu durumlarda dikkatli olun. Entegrasyonlar genellikle kurulum sorunları, test gereksinimleri ve lansman sonrası destek gerektirir; bunlar sabit fiyat için öngörmesi zor riskler taşır.
Teslim kısa ve spesifik olmalıdır. Çoğu müşteri canlı MVP'yi, erişim bilgilerini, dahilse kaynak kodu veya dışa aktarma erişimini ve temel içerik veya yönetici görevlerini nasıl düzenleyeceklerine dair basit bir yürütmeyi bekler.
Risk için fiyatlandırın, sadece geliştirme süresi için değil. Test, proje yönetimi, normal temizlik ve küçük gecikmeler için alan bırakın; çünkü hızlı teslim hızının QA veya müşteri iletişimini ortadan kaldırmadığını unutmayın.
Evet, ancak net süreç kurallarıyla kullanıldığında. Koder.ai keşif notlarını planlama moduna taşıma, büyük değişikliklerden önce anlık görüntüler alma ve teslimatı kaynak kodu dışa aktarımıyla temizlemede yardımcı olabilir; hangi seçeneklerin pakete dahil olduğunu müşterinin bilmesi gerekir.
Hata, üzerinde anlaşılmış özelliğin tanımlandığı şekilde çalışmamasıdır. Yeni özellik, orijinal anlaşmanın parçası olmayan ekstra bir şey ekler; örneğin ek roller, ödeme mantığı veya yeni bir iş akışı.
Başarılı bir şekilde daha önce teslim ettiğiniz bir MVP ile başlayın. Tek bir müşteri tipi için dar bir paketleyin, pilot bir müşteriyle test edin ve projenin nerede süre kaybettiğini not ederek kapsamı, revizyon politikasını ve teslim notlarını sıkılaştırın.