Dahili Onay Akışları için Web Uygulaması Nasıl Oluşturulur (Kod Yazmadan)

Bir dahili onay web uygulamasının yapması gerekenler

Dahili bir onay web uygulaması, bir isteği “birisi bir şeye ihtiyaç duyuyor” durumundan “bir karar verildi—ve sonra kanıtlayabiliriz” durumuna taşımak için kullanılan bir sistemdir. En iyi uygulamalar, süreç ekipten ekibe değişse bile birkaç temel işi tutarlı şekilde yapar.

Desteklenmesi gereken temel akış

Çoğu dahili onay akışı şunları içerir:

• Talep gönderimi: baştan doğru bilgileri (ve ekleri) yakalayan bir form
• İnceleme: bir veya daha fazla kişi bilgiyi doğrular, sorular sorar veya değişiklik talep eder
• Onay / red: isteğe bağlı bir gerekçe ve sonraki adımlar ile net bir karar
• Kayıt tutma: isteği, kararı, zaman damgalarını ve yorumları tek bir yerde saklama

Gerçek dünyadan yaygın örnekler

Aynı deseni birçok süreçte görürsünüz:

• Satın alma talepleri (bütçe sahibi → finans → yönetici)
• İçerik onayı (taslak → hukuk → marka → yayın)
• Erişim talepleri (çalışan → yönetici → IT)
• Politika istisnaları (talep eden → uyumluluk → liderlik)

Neden no-code sıklıkla yeterli olur

No-code araçlar genellikle hızlı gönderim, haftalık yineleme ve süreci yöneten ekipte sahiplik bırakma imkanı verir. Formlar, yönlendirme kuralları, bildirimler ve panolar geliştirici kuyruğunu beklemeden oluşturulabilir.

Ne zaman mühendislik yardımı istenmeli

Çok dallı koşullu yönlendirme, sıkı veri konumlama gereksinimleri, özel SSO kısıtları veya ara katman ve hata yönetimi gerektiren karmaşık entegrasyonlar gibi uç vakalar varsa mühendisleri dahil edin. Birçok kuruluşta no-code UI'yi karşılayabilirken mühendislik eksikleri doldurur.

Eğer "tam özel"e yakın ama tam bir inşa taahhüdü istemiyorsanız, sohbetle iş akışını tanımlayıp uygulamayı (genelde ön yüzde React, arka uçta Go + PostgreSQL) üreten ve kaynak kodu dışa aktarma, dağıtım/barındırma, anlık görüntüler ve geri alma gibi seçenekler sunan Koder.ai gibi bir vibe-coding platformu arada durabilir—onay süreciniz basit başlayıp zamanla sertleşmesi gerektiğinde faydalıdır.

Bir süreci seçin ve çıktıyı tanımlayın

Bir oluşturucu açmadan önce öncelikle bir dahili onay akışını seçin. Amaç, değeri hızlıca kanıtlamak ve sonra aynı deseni diğer onay akışları için yeniden kullanmaktır.

“Yüksek sıkıntı, düşük karmaşıklık” ile başlayın

İyi bir ilk aday genellikle şunlara sahiptir:

• E-posta veya sohbet içinde bolca gidip gelen yazışma
• Sonunda net bir “evet/hayır” kararı
• Küçük sayıda onaycı (1–3) ve tekrarlanabilir adımlar

Örnekler: bir eşiğin altındaki satın alma talepleri, izin onayları, belirli bir şablon için içerik/hukuk incelemesi veya temel tedarikçi kabulü.

Tetikleyiciyi tanımlayın (süreci ne başlatır)

Formdan-onaya sürecinizde "gönderim"in ne anlama geldiğini netleştirin:

• Kim gönderiyor: bir talep sahibi, bir yönetici veya paylaşılan bir ekip posta kutusu mu?
• Gerekli veriler: kararı vermek için hangi alanlar zorunlu (tutar, maliyet merkezi, satıcı adı, son tarih, gerekçe)?
• Ekler: hangi dosyalar bekleniyor (fiyat teklifi, sözleşme taslağı, ekran görüntüsü)?

Eğer onaycılar sık sık aynı eksik ayrıntıyı soruyorsa, v1'de bunu zorunlu yapın.

Paydaşları ve karar noktalarını listeleyin

İlgili her kişiyi (veya rolü) ve kararların nerede verildiğini yazın: inceleyenler, onaycılar, finans, hukuk ve tatiller için vekiller. Ayrıca “düzenleme için geri gönder” veya “daha fazla bilgi iste” gibi kenar kararları da not edin; bunlar çoğu takip işlemini yönlendirir.

Başarı kriterlerini belirleyin (başarılı olduğunu nasıl anlarsınız)

2–3 ölçülebilir sonuç seçin:

• Daha kısa çevrim süresi (ör. 5 günden 2'ye inmesi)
• Daha az takip ("Güncelleme var mı?" mesajlarının azalması)
• Net durum görünürlüğü (talep sahipleri en güncel durumu kendileri görebilsin)

Başlangıç, bitiş ve başarı metrikleri tanımlandığında geri kalan otomasyon seçimleri çok daha kolay olur.

Oluşturmadan önce onay yolunu haritalayın

Bir oluşturucuya dokunmadan önce tek sayfada onay yolunu haritalayın. Bu, isteklerin takılı kaldığı, yanlış kişiye yönlendirildiği veya açık bir sonu olmadan dolaştığı “neredeyse çalışıyor” iş akışlarını önler.

Basit adımlar olarak yazın

Altyapıya yüksek sesle okuyabileceğiniz basit bir omurga ile başlayın:

Gönder → İncele → Onay/Ret → Kapat

Her adım için kim yapıyor (rol veya ekip), ne görmeleri gerekiyor ve ne karara bağlayabileceklerini belirtin. Bir adımı bir cümlede tanımlayamıyorsanız, genellikle gizlenmiş birden fazla eylem vardır ve bunlar ayrılmalıdır.

Seriyal mi paralel mi karar verin

İncelemelerin nasıl gerçekleşeceğini netleştirin:

• Seri: birbiri ardına (Talep eden → Yönetici → Finans). Sıra önemliyse en iyisi.
• Paralel: birden fazla inceleyici aynı anda (Güvenlik + Hukuk). Hız önemliyse en iyisi.

Paralel akışların bir "tamam" kuralı olmalıdır: hepsi onaylamalı, herhangi biri onaylayabilir, veya çoğunluk. Bunu şimdi seçin—sonradan değiştirmek genellikle yeniden inşa gerektirir.

Reddetme davranışını tanımlayın

Bir reddetme şunlardan biri olabilir:

• Düzenle ve yeniden gönder: istek gönderene yorumlarla geri döner, geçmiş tutulur.
• Durdur: istek reddedilmiş olarak kapanır; yeni bir deneme yeni bir istek başlatır.

Uyum ve raporlama için hangisinin doğru olduğunu seçin. "Düzenle ve yeniden gönder" yaygındır, ama yine de orijinal kararı kaydedin.

Gerçek hayatta olan istisnaları ekleyin

Mutlu olmayan yolları baştan haritalayın:

• Acil yol: ekstra görünürlük veya daha az adımla hızlı yol
• Ofis dışı: yedek onaycı veya vekalet kuralı
• Zaman aşımı: hatırlatmalar, eskalasyon veya X gün sonra otomatik yeniden atama

Bunları önce kağıtta yakalarsanız, yapılandırma tahmine dayalı olmaktan çıkar.

Kaydedeceğiniz veriyi ve nasıl saklayacağınızı tasarlayın

No-code onay uygulaması, veri modeli basit, tutarlı ve sonra raporlaması kolay olduğunda en iyi çalışır. Ekranları oluşturmadan önce hangi kayıtları saklayacağınızı ve bunların nasıl ilişkileneceğini kararlaştırın.

Küçük bir çekirdek veri modeliyle başlayın

Çoğu dahili onay akışı için ihtiyaçların %90'ını birkaç tablo (veya koleksiyon) ile karşılayabilirsiniz:

• Talep: onaylanan ana öğe (satın alma, politika istisnası, seyahat, işe alım vb.)
• Kişi: talep sahibi ve onaycılar (genellikle dizinden çekilir)
• Departman: yönlendirme, bütçeleme veya raporlama için kullanılır
• Onay kararı: her adımın sonucu (kim karar verdi, ne karar verildi, ne zaman)
• Yorumlar: talebe bağlı tartışma notları (bazen belirli bir karara bağlı)

Talep'i tek gerçek kaynağınız olarak tutun. Diğer her şey ona işaret etmelidir.

Zorunlu vs isteğe bağlı alanlar (v1'i minimal tutun)

Yönlendirme ve karar vermek için gerekli en önemli alanları belirleyin. Tipik zorunlu alanlar:

• Talep başlığı/özet
• Talep sahibi (Kişi)
• Departman
• Tutar / etki (ilgiliyse)
• Gerektiği tarih
• Gerekçe

Diğer her şey opsiyonel başlayabilir; onaycıların gerçekten ne istediğini gördükçe alan ekleyebilirsiniz.

Ekler ve saklama beklentileri

Hangi belgelerin saklanması gerektiğini (teklifler, sözleşmeler, ekran görüntüleri) ve ne kadar süreyle saklanacağını baştan kararlaştırın.

• Ekler karar için kanıtsa, Talep ile birlikte saklayın.
• Bir saklama kuralı belirleyin (örn. operasyonel istekler için 12–24 ay, finans/hukuk gerekiyorsa daha uzun).
• Kullanıcıların gönderim sonrası ekleri silip değiştirebilme durumunu netleştirin.

Durumları standartlaştırın

Herkesin ilerlemeyi aynı şekilde yorumlaması için küçük, net bir durum seti kullanın:

Taslak → Gönderildi → İncelemede → Onaylandı / Reddedildi → Tamamlandı

Erken aşamada çok fazla özel durum icat etmeyin. Tutarlı bir durum alanı filtreleme, hatırlatmalar ve raporlamayı çok kolaylaştırır.

Kullanıcı dostu formlar ve sayfalar oluşturun

İyi bir onay uygulaması kullanılabilirlikte kazanır veya kaybeder. Eğer insanlar talep göndermekten kaçınıyor ya da bir sonraki adımın ne olduğunu anlayamıyorsa e-postaya geri dönerler.

Gerçekte ihtiyaç duyacağınız temel ekranlar

Çoğu dahili onay akışı küçük bir sayfa setiyle karşılanır:

• Talep formu: yeni talepin oluşturulduğu yer
• Talep detayı: talebi okumak, durumu görmek ve eylemde bulunmak için tek yer
• Onaycı gelen kutusu: bana ait bekleyen öğelerin kuyruğu
• Yönetici ayarları: kategoriler, eşikler, şablonlar ve yönlendirme girdileri

Gezintiyi basit tutun: "Yeni talep", "İsteklerim", "Onayım gerekenler" ve "Ayarlar" (yöneticiler için).

Daha az soran ama daha iyi veri yakalayan formlar

Minimum zorunlu alanlarla başlayın, sonra koşullu alanlar kullanarak formu kısa tutun. Örneğin: "Satın alma türü = Yeni tedarikçi" ise yalnızca "Tedarikçi detayları" göster veya bir politika kutucuğu işaretlenmemişse "İstisna gerekçesi" göster.

No-code araçlar burada parlıyor: bölüm göster/gizle mantığını, tutarlara veya departmana göre kod yazmadan uygulayabilirsiniz.

Durum ve sonraki adımı açık gösterin

Her talep kaydında gösterin:

• Mevcut durum (ör. Taslak → Gönderildi → Yönetici incelemesi → Finans incelemesi → Onaylandı/Reddedildi)
• Şu anda kimde olduğu
• Sonraki adım ne olacak (ek onay eşikleri dahil)

Basit bir ilerleme göstergesi ve “Bekleyen: <isim/rol>” satırı çoğu "Güncelleme var mı?" mesajını ortadan kaldırır.

Yönlendirme ve doğrulama ile gidip gelmeyi azaltın

Zor alanların altında kısa yardımcı metinler ve örnekler ekleyin ("İmzalı teklifi ekleyin (PDF)", "4102-Operasyon gibi maliyet merkezi kullanın"). Doğrulamalarla önlenebilir hataları engelleyin: belirli talep türleri için zorunlu ekler, tutar aralıkları ve net hata mesajları.

Amaç daha az açıklayıcı soru, daha hızlı kararlar ve raporlama için daha temiz kayıtlardır.

Roller, izinler ve yönlendirme kurallarını ayarlayın

Eğer onay uygulamanız bir bina ise roller ve izinler kilitler ve anahtarlardır. Yönlendirme kuralları ise isteklerin doğru masaya ulaşmasını sağlayan işaretlerdir—manüel kovalama olmadan.

Temel rolleri tanımlayın (ve tutarlı tutun)

Tekrar kullanılacak küçük bir rol setiyle başlayın:

• Talep sahibi: talebi oluşturur ve gönderir
• İnceleyen: tamamlığa bakar; geri gönderme yapabilir
• Onaycı: bir adım için kararı verir (yönetici, bölüm başkanı, bütçe sahibi)
• Finans / İK: maliyet, uyum veya kişisel kurallar için uzman onaycılar
• Yönetici: iş akışını, alanları ve erişimi yönetir; tipik olarak onaycı değildir

Her rolün ne yapabileceğini açık dilde yazın before buildera dokunmadan önce.

Aşama başına izinler ekleyin (görme, yorum, düzenleme, onay)

Herkes her şeyi görebildiğinde veya düzenleyebildiğinde onaylar bozulur. Her aşamada izinleri tanımlayın:

• Kim talebi ve ekleri görebilir?
• Kim yorum yapabilir (ve yorumlar talep sahibine görünür mü)?
• Kim alanları düzenleyebilir (genellikle gönderene kadar; inceleme sırasında sınırlı düzenleme)
• Kim onaylayabilir/reddedebilir, ve isteyebilirler mi değişiklik?

Pratik bir varsayılan: gönderildikten sonra ana alanları kilitleyin ve yalnızca "geri gönder" ile düzenlemeye izin verin.

Ekip tabanlı yönlendirme kullanın ki istekler org şemasını izlesin

İsimleri sabit kodlamak ölçeklemez. Tercih edilen yönlendirme kuralları:

• İlk onay talep sahibinin yöneticisi tarafından verilsin
• Tutar eşiğini aşarsa bölüm bütçe sahibi'ne yönlendirilsin
• GL kodu veya harcama türü gerektiriyorsa Finans eklensin
• İnsan kaynaklarıyla ilgiliyse İK eklensin

Böylece insanlar katıldığında, ayrıldığında veya takım değiştirdiğinde akış doğru kalır.

Tıkanmaları önlemek için vekalet ve yedek planlayın

Onaylar genellikle izinler veya yoğun gelen kutuları nedeniyle tıkanır. Şunları ekleyin:

• Vekalet (onaycı belirli tarih aralığı için bir vekil atayabilir)
• Yedek onaycılar (X gün içinde işlem olmazsa alternatife yönlendir)
• Eskalasyon kuralları (zaman aşımından sonra onaycının yöneticisini bilgilendir)

Bu kurallar kontrolü kaybetmeden işlemi korur.

Görevleri, bildirimleri ve hatırlatmaları otomatikleştirin

Otomasyon basit bir formu güvenilir bir onay iş akışına dönüştürür. Amaç: bir talep durum değiştirdiğinde bir sonraki kişinin doğru görevi anında alması—manüel takip veya link kopyalama olmadan.

Durum değişikliklerinde yönlendirmeyi otomatikleştirin

Şu gibi kurallar kurun: Taslak → Gönderildi → Yönetici İncelemesi → Finans İncelemesi → Onaylandı/Reddedildi. Her durum değişikliği otomatik olarak:

• Talebi sonraki onaycıya veya ekip kuyruğuna atamalı
• Sahipliği güncellemeli (kimin “topu” aldığı)
• Alanları kilitleyip açmalı (ör. talep sahibi gönderim sonrası tutarı düzenleyemesin)

Yönlendirme kurallarını okunabilir tutun. İstisnalara ihtiyacınız varsa (ör. "Tutar > $5,000 ise CFO onayı ekle"), bunları veri alanlarına bağlı açık koşullar olarak tanımlayın.

İnsanların gerçekten fark edeceği bildirimler ekleyin

En az iki tür mesaj gönderin:

• "İncelemeniz gerekiyor": talep başlığı, tutar/tür, son tarih ve onay sayfasına doğrudan bir bağlantı içerir
• "Karar verildi": talep sahibi ve izleyicileri bilgilendirir; karar, onaycı adı ve yorumları içerir

Şirketin zaten kontrol ettiği kanalları kullanın—e-posta artı varsa Slack/Teams. Mesajları kısa ve tutarlı tutun ki gürültü gibi hissettirmesin.

Son tarihten sonra hatırlatmalar ve eskalasyon

Onaylar sorumluluk olmadığında takılır. Şunları ekleyin:

• Son tarihten X saat/gün önce bir hatırlatma
• Son tarihten sonra ikinci bir hatırlatma
• N gün içinde işlem olmazsa yedek onaycıya veya yöneticisine eskalasyon

Eskalasyonları öngörülebilir (ve görünür) yapın ki onaycılar sisteme güven duyabilsin.

Çoğaltmaları ve eksik onayları önleyecek koruyucular

Otomasyon yaygın hata modlarını da durdurmalı:

• Ana alanları kontrol ederek çoğaltılmış talepleri engelleyin (ör. satıcı + fatura numarası)
• Gönderim öncesi zorunlu alanları gerektirin
• Durum değişikliklerini yalnızca Onay/Red gibi butonlarla yapmaya izin verin (serbest metin düzenlemeye izin vermeyin)

Bu koruyucular yeniden işi azaltır ve her isteğin aynı yolu izlemesini sağlar.

Görünürlük için panolar ve takip ekleyin

Bir onay uygulaması, herkes bekleyeni, takılı kalanı ve yapılmış olanı görebildiğinde işler—ve etrafta soru sormaya gerek kalmaz. Panolar "Bu talep nerede?" sorusunu self-servis cevaba çevirir.

Bir onay gelen kutusu ile başlayın

İnceleyicilerin her gün güvenebileceği tek bir yer oluşturun. Gelen kutusu görünümü şunları içermeli:

• Bana atanan öğeler (öncelik ve mevcut adım ile)
• Yakında verilecekler (SLA veya gereken tarih bazlı)
• Gecikenler (vurgulanmış, eskalasyon kuralları ayrı yerde ele alınır)

Her satırı eyleme dönüştürülebilir tutun: talep sahibi, departman, tutar/tür, gönderilme tarihi, son tarih ve tek tıkla onay/red.

Gerçek sorulara uygun arama ve filtreler ekleyin

Çoğu takip öngörülebilir: "Bu ay Satış'tan bekleyen tüm talepleri göster" veya "Geçen Salı gönderdiğim PO'yu bul". Filtreler oluşturun:

• Talep sahibi (ve/veya talep sahibinin takımı)
• Departman veya maliyet merkezi
• Durum (taslak, gönderildi, incelemede, onaylandı, reddedildi, iptal)
• Tarih aralığı (gönderilen, güncellenen, gereken)

Araç destekliyorsa kaydedilmiş görünümler ekleyin: "Ekibimin bekleyenleri" veya "Finans kuyruğu" gibi.

Döngü süresi ve darboğazları takip edin—gizli detayları ifşa etmeden

Panolar her alanı göstermeye gerek duymadan faydalı olabilir. Operasyonel metriklere odaklanın:

• Ortalama ilk yanıta kadar geçen süre
• Ortalama toplam çevrim süresi
• Hangi adımda takılmış istekler (örn. "Yönetici onayı")
• Hacim trendleri (haftalık/aylık)

Agregelenmiş sayılar ve süreler kullanın ki yöneticiler yavaş adımları görsün ama gizli içeriğe erişmesin.

Dışa aktarma ve raporlamayı erken planlayın

Henüz bir BI aracı kullanmıyorsanız bile raporlamayı kolay yapın:

• Filtrelenmiş listeler için CSV dışa aktarımı (ör. "Geçen çeyrekte onaylananlar")
• Finans veya uyum için basit bir "raporlama" tablosu/görünümü
• Varsa zamanlanmış raporlar paylaşılan bir posta kutusuna gönderilsin

Bu, anlık talepleri azaltır ve zaman içinde iş akışının iyileştiğini kanıtlamanızı sağlar.

İlk günden itibaren denetim izleri ve yönetişim ekleyin

Onaylar harcamayı, riski veya müşteri taahhüdünü etkiliyorsa kanıta ihtiyacınız vardır—sadece son durum olarak "Onaylandı" değil. Yönetişim, insanların zaten buna bağlı hale gelmeden önce eklemek en kolay (ve en ucuz) halidir.

Gerçek soruları cevaplayan bir denetim izi oluşturun

Uygulama kim ne yaptı ve ne zaman netçe kaydetmelidir. En azından kaydedin:

• Durum değişiklikleri (Gönderildi → Onaylandı/Reddedildi → İptal)
• Onaycıların eklediği yorumlar
• Alan düzenlemeleri (ne değişti, eski/yeni değer)
• Yeniden atamalar veya vekalet (kimin adına onay verildi)

Denetim kaydını yöneticiler ve inceleyiciler görebilir, ama varsayılan olarak herkese açmayın.

Onay ve red notlarını anlamlı kılın

Bağlamı olmayan onaylar sonra karışıklık yaratır. Onay için opsiyonel bir yorum, reddetme için ise zorunlu bir "reddetme nedeni" ekleyin. Bu, belirsiz "Reddedildi" sonuçlarını engeller ve yeniden gönderimleri hızlandırır çünkü talep sahibi neyi düzeltmesi gerektiğini bilir.

Pratik bir desen:

• Reddetme bir neden gerektirir (açılır menü + serbest metin)
• Neden bildirimlere dahil edilir ve kayda yazılır
• Yeniden gönderim yeni bir versiyon oluşturur ve geçmiş korunur

Veri erişim kontrolleri: minimum ayrıcalık prensibi

Kullanıcıların yalnızca ihtiyaç duyduklarını görmesini sağlayın:

• Talep sahipleri kendi taleplerini görür
• Onaycılar kendilerine atanan talepleri (ve opsiyonel olarak takımlarını) görür
• Finans/Hukuk belirli kategorileri görebilir
• Yöneticiler ayarları yönetir ve tüm geçmişe erişir

Aracınız satır seviyesinde izin destekliyorsa kullanın; desteklemiyorsa hassas iş akışlarını ayrı uygulamalarda tutun.

Temel uyum: saklama, silme ve erişim incelemeleri

Kayıtları ne kadar süre saklayacağınızı (örn. 1–7 yıl politika gereksinimine göre), silmelerin nasıl çalışacağını (soft-delete sıklıkla daha güvenli) ve kimlerin erişimi üç aylık olarak gözden geçireceğini erken kararlaştırın. Bu kuralları kısa bir dahili sayfada belgeleyin ve uygulamadan bağlantı verin (örneğin: /help/approvals).