Sözleşme onay iş akışı: sürümleri yönetin, redlineleri ilgili kişiye iletin ve taslaktan imzaya kadar e-postalar veya bağlam kaybolmadan durumu takip edin.
Sözleşmeler en sık satış ve hukuk arasındaki devralma anında tıkanır. Satış, müşteriyle ivmeyi korumaya çalışır. Hukuk ise riski azaltıp maddelerin tutarlı kalmasını sağlamaya çalışır. Ortak bir sözleşme onay iş akışı yoksa devralma tahmin oyununa dönüşür: bir sonraki adım kimin, ne değişti ve “onay” ne anlama geliyor.
Gerçek zarar nadiren pazarlık sürecinin kendisidir. Asıl kaybolan şey yoldadır: son sürüm, bir redline'ın tam sözcükleri, bir maddenin neden kabul edildiği ve kararı kimin verdiği. O geçmiş e-posta dizilerinde ve “v7-final-FINAL” gibi dosya adlarında dağıldığında ekipler zamanını tekrar okuma, yeniden gönderme ve daha önce verilmiş kararları tekrar tartışmakla harcar.
Birkaç belirti hızlıca ortaya çıkar:
İyi bir ortak akış en iyi haliyle sıkıcı görünür. Geçerli durumu, geçerli sürümü ve bir sonraki gerekli eylemi kontrol etmek için tek bir yer vardır. Herkes 10 saniyede üç soruyu cevaplayabilmelidir: Hangi aşamadayız? Şu an kim sorumlu? İmza ne engelliyor?
Müşteri standart ödeme koşullarınızda istisna isterse satış yeni bir eki iletmemeli ve ummalı ki hukuk değişen tek cümleyi fark eder. Bu talep açık bir görev oluşturmali, redlineleri doğru gözden geçirene yönlendirmeli ve kararı kaydetmelidir. Birçok ekip her iki tarafın da aynı kayıttan çalışması için basit bir dahili araç kullanır.
Bir sözleşme onay iş akışı, herkes iki şeyi bildiğinde en iyi şekilde çalışır: neyi sahipleniyorlar ve neyi değiştirmeye yetkileri var. Roller bulanıksa sürpriz düzenlemeler, kaybolan redlineler ve gerçekten gerçekleşmemiş onaylar ortaya çıkar.
Başlangıç olarak temel rolleri ve süreç içindeki “yetki seviyelerini” isimlendirin. Düzenleme onaylamaktan farklıdır, ikisi de imzalamadan başkadır.
Çoğu ekip benzer bir sahibi kümesiyle sonuçlanır:
Bir kuralı açıkça koyun: yalnızca hukuk hukuki dili düzenler. Satış değişiklik önerebilir (yorumlarda veya bir intake formunda), ama maddeleri doğrudan yeniden yazmamalıdır. Benzer şekilde hukuk, satışla yeniden iletişime geçmeden fiyatlandırmayı veya kapsamı değiştirmemelidir.
Hukuki inceleme, satış eksiksiz bir paket sunduğunda daha hızlı ilerler: müşteri tüzel adı, anlaşma tutarı ve süresi, ürün kapsamı, fiyatlandırma ve indirim, SLA beklentileri, özel güvenlik gereksinimleri ve herhangi bir “zorunlu” müşteri maddesi. Temel bilgilerin eksik olması, bir sözleşmenin geri dönmesinin en yaygın nedenidir.
Yanıt süreleri ve yükseltme yollarında anlaşın. Örneğin, hukuk standart kağıt için 1 iş günü, standart dışı koşullar için 3 iş gününde yanıt verir. Saat sınırı dolarsa yükseltme yolu açık olmalıdır (hukuk lideri, sonra satış yöneticisi, sonra imza yetkilisi).
Bir sözleşme onay iş akışı aracında bunu kurduğunuzda, sorumlulukları izinlere eşleyin ki süreç kuralları otomatik uygulasın. Ekipler bazen bu tür dahili uygulamaları AppMaster (appmaster.io) içinde kurar; orada rolleri, izinleri ve onayları elle kodlamadan ayarlayabilirsiniz.
Bir sözleşme onay iş akışı, herkesin saniyeler içinde şu soruyu cevaplayabildiğinde en iyi şekilde çalışır: “Bu sözleşme şu an hangi durumda ve sonra ne oluyor?” Modeli basit tutun ve her durumun tek bir net anlamı olsun.
İşte kullanabileceğiniz pratik bir durum akışı:
| Status | Enter when | Exit when |
|---|---|---|
| Draft | Satış ilk sürümü oluşturur (şablon veya müşteri kağıdı) | İncelemek için yeterince tamamlandığında (tüm ana alanlar doldurulmuş) |
| In legal review | Satış hukuka gönderir (bağlam ile) | Hukuk işe başlar veya eksik bilgi ister |
| Redlines received | Hukuk düzenlemeleri veya yorumları geri gönderir | Satış neyi kabul edeceğine, reddedeceğine veya karşı teklif yapacağına karar verir |
| In negotiation | Redlineler müşteriyle değiş tokuş ediliyor | Şartlar yakınsar ve iç onay hazırdır |
| Approved | Gerekli onaylayanlar nihai şartlar üzerinde imza atar | Nihai belge imzaya hazırlanır |
| Ready to sign | İmzalanacak kopya kilitlenmiş ve doğru | Tüm taraflar imzalar |
| Signed | İmzalar tamamlanmıştır | Belge depolanır ve erişim ayarlanır |
| Archived | Anlaşma kapandı, kaybedildi veya yerini başka belge aldı | (Bitiş durumu) |
Giriş ve çıkış kurallarını iş akışının içinde görünür yapın, sadece “halk bilgisi” olarak bırakmayın. Örneğin, “Approved” fiyat, süre uzunluğu, sorumluluk ve veri şartlarının iç kontrollerinizden geçtiği anlamına gelmelidir; sadece “hukuk baktı” anlamında olmamalıdır.
Ayrıca gecikmelerin yorumlarda gizlenmemesi için birkaç gerçeklik durumu ekleyin:
Bunu bir araçta uyguluyorsanız, durumu izin verilen tek değerleri olan bir alan olarak modelleyin ve Blocked veya Paused durumuna geçerken bir gerekçe zorunlu kılın. Bu küçük koruma “gizemli takılı” sözleşmeleri önler ve satış ile hukuku hizalı tutar.
Eğer insanlar hangi belgenin geçerli olduğunu söyleyemiyorsa, iş akışı hızla bozulur. En basit çözüm bir tek gerçek kaynağı seçmek ve her şeyi diğer her şeyi kopya olarak görmek. Bu kaynak, en son dosyanın, durumun ve yorumların yaşadığı bir sözleşme kaydı olabilir.
Bir kural tartışılmaz olmalı: aynı anda sadece bir “Current” sürüm vardır. Yeni bir revizyon oluşturulduğunda önceki arşivlenir ve kilitlenir. İnsanlar yine görüntüleyebilir ama düzenleyemez veya yeniden gönderemez.
Dosyalar e-postayla gönderilse veya indirilsin, tutarlı bir adlandırma kuralı yardımcı olur. Tahmin edilebilir tutun:
Müşteri redlineleri genellikle karışıklığın başladığı yerdir. Her revizyon için iki dosya tutun: değişiklikleri gösteren bir redlined kopya ve şu ana kadar kabul edilen aynı değişiklikleri yansıtan temiz bir kopya. Satış temiz şartları hızlıca okuyabilir, hukuk tam olarak neyin değiştiğini görebilir.
Her revizyonda insanlara yönelik kısa bir değişiklik notu ekleyin. Bir cümle yeterlidir: “Müşteri talebiyle sorumluluk limiti 12 aya düşürüldü.” Bu, tekrar tartışmaları önler ve birisi devraldığında el değiştirmeyi kolaylaştırır.
Örnek: Satış “Acme MSA v01 2026-01-25 Clean” gönderir. Müşteri düzenlemeleri “Acme MSA v02 2026-01-27 Redline” olarak geri gönderir ve hukuk “Acme MSA v02 2026-01-27 Clean” ile bir değişiklik notu üretir. Oradan v03 yalnızca yeni bir şey değişirse başlar.
Hukuki inceleme, yarım bir e-posta ve üç “son” ekiyle başlarsa daha yavaş ilerler. Bir şeyi hukuka göndermeden önce her seferinde aynı girdileri toplayın. Bu geri dönüşleri azaltır ve onay iş akışınızı öngörülebilir kılar.
Risk ve dili etkileyen anlaşma temel bilgileriyle başlayın:
Sonra aslında belgeleri tek bir inceleme paketine ekleyin: ana anlaşma artı tüm ekler, sergiler, sipariş formları ve eğer varsa müşterinin redlineleri. Paketi durum ve sürüm geçmişiyle aynı sözleşme kaydına bağlayın.
Daha sonra hukukun bir kelime bile okumadan önce hangi onayların gerektiğini açık yapın. Basit tetikleyiciler tanımlayın ki satış neyin ekstra onay gerektireceğini bilsin:
Son olarak, hukuka bilinen ve onaylı iyi dil kullanma yeri verin. Küçük bir onaylı madde kütüphanesi bile her seferinde aynı paragrafları yeniden yazmayı azaltır.
Örnek: Otomatik yenilemeli ve sınırsız sorumluluk talebinde bulunan yıllık 45k$ tutarında bir anlaşma, tam redline dosyası, yenileme detayları ve finans ile liderlik onayı gereksinimiyle birlikte sunulmalıdır. Hukuk böylece kararlar üzerinde odaklanır, kazıma işinde değil.
İyi bir sözleşme onay iş akışı öngörülebilirdir. Herkes bir sonraki adımın ne olduğunu, kimin sahip olduğunu ve “tamam”ın ne demek olduğunu bilmelidir.
Satış doğru şablonu kullanarak taslağı başlatır ve gerekli anlaşma detaylarını (hesap adı, fiyatlandırma, süre, başlangıç tarihi, ürünler ve istenen kapanış tarihi) doldurur. Eksik bir şey varsa sözleşme ilerlememelidir.
Hukuk görmeden önce birkaç otomatik kontrol çalıştırın. Basit tutun ki insanlar bunlara güvensin:
Eğer taslak kontrolleri geçerse, net bir istekle hukuka yönlendirin, örneğin “sadece incele” vs “redlineleri onayla”, ve müşterinin ne istediğine dair kısa bir not ekleyin.
Hukuk redline'ları inceleyip geri gönderir. Satış müşteriyle müzakere eder, ama müşteriyle her temas yeni bir revizyon olarak izlenmelidir. Kararların e-postada kaybolmaması için yorumları tek bir yerde tutun.
Tekrarlanabilir bir revizyon deseni yardımcı olur:
Müşteri kabul ettiğinde, nihai sürümü iç onaylara (finans, güvenlik, yönetim imza yetkilisi) gönderin, eşiklerinize göre. İmza yetkilisi dağınık bir diziyi değil, nihai şartları ve onay geçmişini incelemelidir.
Sonra sözleşmeyi imzaya taşıyın (e-imza veya manuel). İmzalandıktan sonra kaydı kilitleyin, icra edilmiş kopyayı depolayın ve raporlamanın doğru kalması için Signed olarak işaretleyin.
Onay iş akışı, onayın en yüksek sesli olana göre verilmediği zaman daha iyi çalışır. Satışın yolu tahmin edebilmesi ve hukukun riske odaklanabilmesi için basit kuralları yazılı hale getirin.
Hatırlanması kolay küçük bir eşik seti ile başlayın. Bunları anlaşma büyüklüğüne, riske ve politika değişikliklerine bağlayın, kişisel tercihlere değil. Genel kural: hukuk dili onaylar, finans paranın nasıl hareket ettiğini etkileyen değişiklikleri onaylar ve güvenlik/BT veri ile sistemi etkileyen değişiklikleri onaylar.
Onay gerektiren tetikleyicileri tanımlayın, örneğin:
İstisnalar zaman kaybına yol açar. Acil anlaşmaları, müşteri kağıtlarını ve standart dışı maddeleri önceden nasıl ele alacağınızı karar verin. Hızlandırılmış bir yol verebilirsiniz, fakat daha sıkı yükseltme ve yazılı bir risk notu şart koşun. Hız hesabızlığa yol açmamalıdır.
“Koşullarla onaylandı”nın ne demek olduğunu tanımlayın. Bu belirsiz bir onay olmamalıdır. Bu, sözleşmenin sadece belirli koşullar yerine gelirse ilerleyebileceği anlamına gelir ve izlenmelidir; örneğin "müşteri DPA ekini kabul eder" veya "finans peşin fatura programını doğrular" gibi. Her koşulu bir sahip ve bitiş tarihi ile birlikte görev olarak depolayın.
İşlerin tıkanmaması için net yükseltme tetikleyicileri koyun:
İnsanlar ne olduğunu ve neden olduğunu göremezse, onay iş akışı yan sohbetlere, ekran görüntülerine ve dosyaların yeniden gönderilmesine dönüşür. Çözüm basittir: kararları sözleşmenin yaşadığı yerde yakalayın.
Bir denetim izi üç soruyu cevaplamalıdır: ne değişti, bunu kim yaptı ve ne zaman yaptı. Durum geçişlerini (Draft → In legal review), onayları veya redleri ve "redlines yüklendi" ya da "müşteriye gönderildi" gibi ana eylemleri kaydedin. Otomatik olsun ki yoğun günlerde atlanmasın.
Yorumlar faydalıdır ama yalnızca kararları kaydediyorlarsa. “Neden”i açıklamak için kullanın, önemli maddeleri gizlemek için değil. Yenileme tarihi, indirim veya sorumluluk limiti önemliyse, bunları yapılandırılmış alanlarda (veya kısa bir özet alanında) saklayın ki aranabilir ve raporlanabilir olsun.
Okunabilirliği koruyan basit bir yorum kural seti:
Bildiriler yalnızca eylem gerektiğinde yüksek sesli olsun: sözleşme el değiştirince, redline geldiğinde, onay istendiğinde veya bir son tarih risk altındayken. Diğer her şey günlük özet olabilir (örneğin, “Satışta bekleyen 3 sözleşme” veya “Hukukta bekleyen 2”). Çok fazla uyarı insanları görmezden gelmeye alıştırır.
Son olarak, ilgili öğeleri kayda ekleyin: önemli e-postalar, görüşme notları ve pazarlık noktaları. Yeni biri anlaşmanın ortasına katıldığında beş dakikada geçmişi anlamalıdır.
Bir satış temsilcisi orta ölçekli $85k ARR tutarında bir anlaşma kapatıyor. Müşteri %12 indirim istiyor ve sorumluluk limitini 12 aylık ücretlerden 24 aya çıkarmak istiyor. Bu, satış, hukuk ve müşterinin aynı belgeye dokunduğu yaygın bir durumdur.
Ekip, net durumlar ve geçerli dosyayı izleyen tek bir yer olan basit bir onay iş akışı kullanıyor.
Bu sözleşme şöyle ilerler:
Zor an: Approved olarak işaretlendikten sonra müşteri “küçük” bir redline (fesih bildiriminde tweak) gönderir. Kural nettir: herhangi bir yeni redline incelemeyi yeniden açar. Satış v05 (onaydan sonra müşteri redline'ı) yükler ve durum tekrar In legal review olur; önceki onay kaydedilir ama artık güncel değildir.
İmzalanacak nihai sürümü doğrulamak için ekip bir dosyayı Final for Signature olarak kilitler, sürüm kimliğini not eder (örneğin v06) ve imza paketi tam olarak bu dosyayı kullanmalıdır. İmzalı kopya herhangi bir tutarsızlıkla gelirse durum Blocked (veya kullandığınız etiket Exception ise o) olarak değişir ve takım bunu countersign etmeden önce çözer.
Onay iş akışını en hızlı tıkayan yol işi akışın dışına kaçırmaktır. Redlineler e-posta dizilerinde kalırsa birisi bir değişikliği kaçırır, yanlış mesaja cevap verir veya güncel olmayan bir eki iletir. İyi niyetle bile “sadece e-posta” düzenlemeleri görünmez işler ve belirsiz kararlar yaratır.
Diğer yaygın engelleyici, hukuki incelemeyi eksik bilgilerle başlatmaktır. Ana anlaşma detayları sohbet, CRM notları ve bir taslak PDF arasında dağınıksa hukuk dedektiflik yapar. Bu geri dönüşleri artırır ve satış, hukukun “yavaş” olduğunu hisseder.
Çoğu ekipte tekrar eden birkaç suçlu görünür:
Aşırı karmaşık durumlar özellikle sinsidir. Durum listesi insanların gerçekte aldığı adımlardan uzunsa, bu bir tahmin oyununa dönüşür. Etiketleri basit ve eylem odaklı tutun ve her durumun açık bir sonraki adımı olduğundan emin olun.
Son olarak sahiplenmeyen devralmalara dikkat edin. Örnek: Satış saat 18:00'de revize edilmiş bir taslak gönderir, “güncellendi” diye işaretler ve hukukun alacağını varsayar. Hukuk satışın hala eksik bilgi topladığını düşünür. Müşteri güncelleme isteyene kadar hiçbir şey olmaz.
Araçlar yalnızca temel kuralları uygularsa yardımcı olur: tek bir geçerli sürüm, gönderimden önce zorunlu alanlar ve görünür bir sonraki sahip.
Bir sözleşme onay iş akışı, herhangi birinin saniyeler içinde dört soruyu cevaplayabildiğinde işler: hangi sürüm geçerli, kimin sahip olduğu, sonra ne olacağı ve “tamam” sayılacak şey nedir.
Müşteriye herhangi bir şey göndermeden önce hızlı bir doğruluk kontrolü yapın. Fiyatların, indirimlerin ve ödeme koşullarının teklif ile eşleştiğini onaylayın. Tarihleri (başlangıç, yenileme, bildirim süreleri) tekrar kontrol edin ve her referans verilen ekin dahil edildiğinden emin olun (sipariş formu, DPA, SOW, güvenlik eki).
Bir sözleşmeyi Signed olarak işaretlemeden önce, nihai icra edilmiş PDF'iniz olduğundan emin olun (taslak ekran görüntüsü değil). İmza sayfasının eksiksiz olduğundan, isimlerin imzalayanlarla eşleştiğinden ve gerekli baş harflerin bulunduğundan emin olun. Bunu kararlaştırılmış kayıt sistemine depolayın ve depolama yerini anlaşma kaydında yakalayın ki sonra bulunması kolay olsun.
Durum adlarınızı ve çıkış kriterlerinizi tanımlayın, satışın eksiksiz bir paket göndermesini sağlayacak tek bir intake formu oluşturun ve onay eşiklerini (süre, indirim yüzdesi, sorumluluk limitleri) yazılı hale getirin. Ardından hafif bir dahili iş akışı uygulaması oluşturun: bir sözleşme tablosu, durum alanları, "geçerli sahibi" ataması ve gönderimler için zorunlu bir kontrol listesi içersin.
Kod yazmadan üretim hazır uygulamalar üretebilen bir no-code seçeneği isterseniz, AppMaster (appmaster.io) dahili iş akışları için sıkça kullanılır: veriyi modelleyebilir, onayları kurabilir ve satış, hukuk ve finans arasında görevleri kodsuz yönlendirebilirsiniz.
Why do sales and legal need a shared contract approval workflow?Tek bir ortak kayıt kullanın: geçerli durumu, geçerli dosyayı ve geçerli sahibi gösteren bir yerde. Her iki ekip de “hangi aşamada, kim sahip, imzayı ne engelliyor” sorularını e-postada kaybolmadan cevaplayabildiğinde, el değiştirmeler gecikmeye dönüşmez.
What’s the most important rule to set between sales and legal?"Düzenleme", "onaylama" ve "imzalama" farklı eylemler ve her birinin riski farklıdır. Eğer satış hukuki maddeleri doğrudan düzenleyebiliyorsa ya da hukuk fiyat/ kapsam üzerinde değişiklik yapıyorsa, sürpriz değişiklikler, yeniden açılan tartışmalar ve aslında hiçbir anlam ifade etmeyen onaylar ortaya çıkar.
What information should sales submit before legal review starts?En azından müşteri tüzel adı, anlaşma tutarı, süre, fiyat/indirim bilgisi, başlangıç tarihi, yenileme/sona erme detayları ve müşterinin talep ettiği özel maddeleri yakalayın. Bu temel bilgiler eksikse, hukuki inceleme soru-cevap döngüsüne dönüşür, gerçek bir inceleme olmaz.
What statuses should a simple contract workflow include?Durumları az ve katı tutun; her bir durum yalnızca bir şeyi ifade etsin. Pratik bir varsayılan: Draft, In legal review, In negotiation, Approved, Ready to sign, Signed ve gecikmelerin saklanmaması için Blocked veya Waiting on customer gibi açık bir işaretleme yolu.
What does “Approved” need to mean so people stop arguing about it?“Approved”ı şu şekilde ele alın: “tüm gerekli iç onaylayanlar bu tam sürümü ve bu tam maddeleri onayladı.” Onaydan sonra herhangi bir değişiklik olursa incelemeyi yeniden açın ve nedenini kaydedin; aksi halde kimsenin gerçekten onaylamadığı bir şeyi imzalamış olursunuz.
How do we stop the “which file is final?” problem?Tek bir bilgi kaynağı seçin ve "aynı anda sadece bir Current sürüm" kuralını uygulayın. Müşteriyle paylaşılan her gönderim yeni bir sürüm oluşturmalı ve eski sürümler görüntülenebilir ama düzenlenemez veya yeniden gönderilemez hale gelmelidir.
Should we keep both clean and redlined copies?Her revizyon için iki dosya oluşturun: değişiklikleri gösteren bir redlined kopya ve aynı kabul edilmiş durumu yansıtan temiz (clean) kopya, böylece hukuk dışındakiler hızlıca temiz metni okuyabilir. Bir cümlelik değişiklik notu ekleyin ki gelecekte aynı madde yeniden tartışılmasın.
How do we set approval thresholds without slowing every deal?Risk ve para ile ilişkilendirilmiş basit tetikleyiciler kullanın, kişisel tercihlere göre değil. Hukuk dil değişikliklerini onaylamalı, finans ödeme ve fatura istisnalarını onaylamalı, liderlik ise örneğin sınırsız sorumluluk gibi yüksek riskli maddeleri onaylamalıdır.
What should an audit trail capture for contract approvals?Olayları otomatik olarak kaydedin: durum değişleri, sürüm yüklemeleri, onaylar/reddetmeler ve kim, ne zaman yaptı. Yorumlar kararların "nedenini" açıklamalı, ama kilit müzakere edilmiş maddeler de yapılandırılmış alanlarda tutulmalı ki sonradan aranabilir olsun.
Can we build a simple internal tool for this without custom coding?Evet—temel kuralları uyguluyorsa: gönderimden önce zorunlu alanlar, rol tabanlı izinler, izin verilen değerleri olan tek bir durum alanı ve açık "geçerli sahip". AppMaster (appmaster.io) gibi araçlar ekiplerin onayları yönlendirmesine, sürümleri takip etmesine ve satış, hukuk, finansın aynı kayıttan çalışmasına yardımcı olmak için kullanılır.
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.
