Politika onaylama uygulaması: çalışanlar için nasıl yapılandırılır?

Politika onaylarını takip etmek neden zorlaşır?

Bir şirkette 12 çalışan varken politika e-postası işe yarayabilir. İK bir PDF ekler, herkesten yanıt vermesini ister ve gelen yanıtları bir posta kutusunda saklar. Politikalar değiştiğinde, ekipler büyüdüğünde veya bir yöneticinin belirli bir çalışanın belirli bir belgeyi kabul ettiğine dair kanıta ihtiyacı olduğunda bu yöntem yetersiz kalır.

Paylaşılan klasörlerin de farklı bir sorunu vardır. Genellikle yalnızca en güncel dosyayı gösterir ve dosyayı kimin açtığını nadiren belirtir. Bir erişim günlüğü bile birinin politikayı okuduğunu, gerekli işlemi anladığını veya politikaya uyacağını onayladığını kanıtlayamaz.

Bir politika onaylama uygulaması üç bilgiyi birbirinden ayrı tutar: politikanın metni, sürümü ve her çalışanın yanıtı. İK uzaktan çalışma kuralını, harcama limitini veya güvenlik gerekliliğini güncellediğinde şirket eski sürümü saklayabilir, yenisini yayımlayabilir ve her çalışanın hangi sürümü onayladığını gösterebilir.

Kayıt şu pratik soruları yanıtlamalıdır:

• Politikayı hangi çalışanlar, ne zaman aldı?
• Her kişi hangi sürümü onayladı?
• Yanıtlarını ne zaman gönderdiler?
• Son tarihi kimler kaçırdı?
• Güncelleme yeni bir onay gerektirdi mi?

Okumak ve onaylamak farklı işlemlerdir. Okundu bilgisi, birinin e-postayı görüntülediğini gösterir, ancak «Bu politikayı okuduğumu ve anladığımı onaylıyorum» şeklinde bir beyan içermez. Resmî bir onay; çalışanın kimliğini, politikanın tam sürümünü, zaman damgasını ve yanıtı kaydetmelidir.

Bu yapı olmadığında İK, e-posta zincirlerini, elektronik tablo satırlarını ve «Davranış Kuralları son» ile «Davranış Kuralları son 2» gibi adlandırılmış dosyaları karşılaştırmak için saatler harcayabilir. Kayıt, altı ay önceki bir kanıt istendiğinde eksiksiz görünmeyebilir.

İyi tasarlanmış bir uygulama her politikaya sabit bir kayıt verir ve çalışanlara tek bir net görev sunar. Böylece yöneticiler tüm şirkete tekrar tekrar hatırlatma göndermek yerine yalnızca yanıt vermesi gereken kişilerle iletişime geçebilir.

İş akışını oluşturmadan önce rolleri belirleyin

Bir belge yüklenmeden önce izinleri belirleyin. Aksi hâlde bir yönetici tamamlanmamış bir politikayı yayımlayabilir veya iş gereği olmayan kişiler çalışan yanıtlarını görüntüleyebilir.

Çoğu ekibin beş role ihtiyacı vardır. Küçük bir şirkette bir kişi birden fazla rol üstlenebilir, ancak izinler ayrı tutulmalıdır.

• Politika sahibi politikayı yazar, günceller ve soruları yanıtlar.
• İnceleyen kişi taslağın doğruluğunu, hukuki ifadelerini ve anlaşılır dilini kontrol eder.
• Yayıncı onaylanmış sürümü hedeflenen çalışanlara sunar.
• Çalışan atanan politikayı okur ve onay gönderir.
• Yönetici erişimi, grupları, kayıtları ve dışa aktarımları yönetir.

Taslak düzenleme yetkisini politika sahibi ve inceleyen kişilerle sınırlayın. İnceleyen kişi taslağa yorum yapabilir veya onu onaylayabilir, ancak bu görevin parçası değilse yayımlamamalıdır. Yayıncı, yalnızca gerekli onay kaydedildikten sonra bir sürümü yayımlamalıdır. Bu ayrım, aceleyle hazırlanmış bir taslağın resmî politika hâline gelmesini önler.

Çalışan yanıtlarına erişim, politikanın kendisine erişimden daha sıkı olmalıdır. Yöneticilerin ekiplerinin tamamlanma durumunu görmesi gerekebilir. İK veya uyumluluk ekipleri adlara, tarihlere, yorumlara ve dışa aktarımlara ihtiyaç duyabilir. Çoğu çalışan yalnızca kendi yanıtlarını görmelidir.

Örneğin uzaktan çalışma politikası sahibi, ev ofisi ekipmanı ödeneğini günceller. İK metni inceler, bir insan ve kültür yöneticisi 3. sürümü yayımlar ve çalışanlar politikayı okuduklarını onaylar. Bir denetim gerektiğinde yönetici tamamlanma kaydını dışa aktarabilir.

AppMaster bu izinleri kullanıcı rolleri, çalışan grupları ve politika düzenleme, yayınlama ve yanıt raporlaması için ayrı ekranlarla modelleyebilir. Her kişiye ihtiyaç duyduğu en az izinle başlayın, ardından gerçek bir iş gerektirdiğinde erişimi genişletin.

Açık bir politika ve sürüm kaydı oluşturun

Her politikanın güvenilir tek bir kaydı olmalıdır. «El kitabı_son_sürüm_v3» gibi dosya adlarından kaçının. Bu adlar bir çalışanın, yöneticinin veya denetçinin belirli bir tarihte hangi belgenin geçerli olduğunu doğrulamasını zorlaştırır.

Politika kaydında anlaşılır bir başlık, kategori, sahip, yürürlük tarihi ve ekli belge bulundurun. Kategoriler iş yeri davranışı, güvenlik, yan haklar ve uzaktan çalışma olabilir. Sahip, soruları yanıtlayabilecek ve değişiklikleri onaylayabilecek belirli bir kişi veya ekip olmalıdır.

Yayımlanan her politikaya 1.0, 1.1 veya 2.0 gibi açık bir sürüm numarası verin. Basit bir kural işe yarar: küçük metin değişikliklerinde bir sonraki alt sürümü, çalışanların görevlerini veya kuralları değiştiren durumlarda yeni bir ana sürümü kullanın. Karmaşık bir numaralandırma sisteminden çok tutarlılık önemlidir.

Taslakları yayımlanmış politikalardan ayırın

Çalışanlar yalnızca onaylanmış politikaları görmelidir. Taslakları ayrı bir durumda tutun. Politika sahibi bu alanda belgeyi düzenleyebilir, tarihleri kontrol edebilir ve geri bildirim isteyebilir. Bir taslak, yayımlanmış sürümün yerini doğrudan almamalıdır.

Sahip bir güncellemeyi yayımladığında yeni bir sürüm kaydı oluşturun ve önceki sürümü koruyun. Önceki sürüm kullanımdan kaldırılabilir, ancak geçmişte yer almaya devam etmelidir. Böylece şirket, bir çalışanın onay gönderdiği sırada tam olarak ne okuduğunu gösterebilir.

Her yeni sürüm için kısa bir değişiklik notu ekleyin. Örneğin: «2.0 sürümü uzaktan çalışma onay sürecini değiştirir. Çalışanlar kendi eyaletleri dışında çalışmadan önce onay istemelidir.» Bu not, çalışanların neden yeni bir istek aldığını anlamasına ve yöneticilerin kimin tamamlaması gerektiğine karar vermesine yardımcı olur.

Her onay yalnızca politika başlığına değil, tek bir politika sürümüne bağlanmalıdır. Politika birkaç kez değiştiğinde geçmişin anlaşılır kalmasını sağlayan ayrıntı budur.

Basit bir onay ve yayınlama süreci kullanın

Politika sahibi; başlık, anlaşılır dilde içerik, sürüm numarası ve önerilen yürürlük tarihiyle bir taslak oluşturur. Taslak inceleme aşamasındayken düzenlenebilir.

Ardından taslağı onaylaması gereken kişilere gönderin. Bu kişiler İK, departman yöneticisi, hukuk danışmanı veya operasyon yöneticisi olabilir. Süreci doğrudan tutun: her inceleyen kişi taslağı onaylayabilir, reddedebilir veya yorumla birlikte geri gönderebilir. Taslak geri gönderilirse sahibi günceller ve yeniden sunar.

Sabit bir sürüm yayımlayın

Onaydan sonra politikayı belirlenmiş bir çalışan grubuna yayımlayın. Yürürlük tarihini dikkatle seçin. Çalışanların yeni bir seyahat politikasını yaklaşan seyahatleri etkilemeden önce okuması gerekirken, acil bir güvenlik güncellemesinin aynı gün yürürlüğe girmesi gerekebilir.

Yayımlandığında sürümü kilitleyin. Çalışanlar metni okuyabilir, ancak hiç kimse metni, atanan grubu veya sürüm numarasını değiştirememelidir. Metin değişirse yeni bir taslak oluşturun ve yeni bir sürüm yayımlayın. Böylece her çalışanın onayı, gördüğü tam metne bağlanır.

Yayımlanmış kayıtta politika başlığı ve sürümü, politika sahibi, onaylayanlar, yayınlanma ve yürürlük tarihleri, atanan çalışan grubu ve sabit politika metni veya ekli belge yer almalıdır.

Politikaları silmeden kullanımdan kaldırın

Daha yeni bir sürüm eskisinin yerini aldığında eski politikayı kullanımdan kaldırılmış olarak işaretleyin. Güncel atama ekranlarından kaldırın, ancak belgeyi, onayları, yürürlük tarihlerini ve tamamlanmış onayları koruyun.

İK, uzaktan çalışma politikası 2.0'ı 2.1 sürümüyle değiştirirse 2.1'e atanan çalışanların yeni metni onaylaması gerekir. Ekip yine de 2.0 sürümünü açabilmeli, kimin ne zaman kabul ettiğini görebilmelidir. Eski kaydı silmek sonraki uyumluluk kontrollerini gereksiz yere zorlaştırır.

Çalışanların onay vermesini kolaylaştırın

Çalışanlar genel bir politika başlığı değil, onaylamaları gereken tam belgeyi görmelidir. Ekranın üst kısmına politika adını, sürüm numarasını, yürürlük tarihini ve yanıt son tarihini koyun.

İşlemi doğrudan tutun. Çalışan belgeyi okuduktan sonra «Bu politikayı okuduğumu ve anladığımı onaylıyorum» gibi bir ifadeyi seçebilir. Onayın amacı bu değilse çalışanların her ayrıntıyı kabul ettiğini söyleyen ifadeler kullanmayın.

Uygulama şirketin zaten sahip olduğu bilgileri kullanmalıdır. Çalışanın adını hesabından alabilir, ardından tarihi, saati, politika sürümünü ve durumu kaydedebilir. «Onaylandı», «beklemede» ve «gecikmiş» gibi basit durumlar yöneticilere çalışan politika onayları hakkında yararlı bir görünüm sunar.

Bir onay ekranı gönderimden önce hataları önleyebilir. Ekranda şunlar gösterilebilir:

• Uzaktan Çalışma Politikası, 3.0 sürümü
• Yürürlük tarihi: 1 Haziran 2025
• Yanıt son tarihi: 15 Haziran 2025
• Durum: 10.42'de onaylandı

Açıklamanın yararlı olacağı durumlarda yorum veya soru için isteğe bağlı bir alan ekleyin. Bir çalışan «Seyahat kuralı gelecek ayki müşteri ziyaretinde geçerli mi?» diye sorabilir. Soruyu politika sahibine gönderin, ancak şirket önce yanıt alınmasını gerektirmiyorsa onay işlemini engellemeyin.

Hassas politikalar için onay düğmesi kullanılabilir hâle gelmeden önce çalışanların belgeyi açmasını zorunlu tutun, ardından gönderim sırasında onay metnini yeniden gösterin. Böylece kısa görevi yorucu bir forma dönüştürmeden makul bir erişim kaydı oluşturursunuz.

AppMaster bu akışı bir politika kaydı, çalışan hesap verileri, bir onay formu ve her yanıtı doğru politika sürümüne kaydeden iş kurallarıyla oluşturabilir.

Politikaları doğru çalışanlara gönderin

Çalışanlar yalnızca işleriyle ilgili politikaları almalıdır. Her belgeyi herkese atamak karmaşa yaratır, yanıt oranlarını düşürür ve kayıtların incelenmesini zorlaştırır.

Atamalar için çalışan dizinini kullanın. Her çalışan kaydında departman, konum, görev, yönetici, işe başlama tarihi ve istihdam durumu gibi pratik alanlar bulunmalıdır. Böylece İK veya operasyon ekipleri her seferinde yeni bir liste oluşturmadan hedef kitleyi seçebilir.

Güncellenen bir depo güvenliği politikası depo çalışanlarına ve onların yöneticilerine gönderilebilir. Satış komisyonu politikası yalnızca satış ekibine gönderilebilir. Her istek politika adını, sürüm numarasını, son tarihi ve çalışanların yapması gereken işlemi belirtmelidir.

Grupları kullanın ve istisnalara izin verin

Atama kurallarını çalışanların zaten anladığı gruplar üzerine kurun. İlk iş akışı için departman ve konum çoğu zaman yeterlidir. Politika yöneticiler, sürücüler veya müşteri verileriyle ilgilenen çalışanlar gibi belirli görevler için geçerliyse görev alanını ekleyin.

Belirli çalışanlara atama yapılmasına da izin verin. Bu özellik, geçici görev üstlenen, ekipler arasında çalışan veya bir olaydan sonra politikayı yeniden incelemesi gereken kişiler için yararlıdır. Bir yönetici yayınlamadan önce kişileri ekleyebilmeli veya çıkarabilmeli, uygulama da bu kararı kaydetmelidir.

Atama ayarlarında departman, konum, görev ve belirli çalışan filtreleri; alıcı ön izlemesi; izinli veya artık aktif olmayan çalışanları dışarıda bırakma seçeneği ve her politika sürümü için son kitlenin kaydedilmiş hâli bulunmalıdır.

Teslimatı onaydan ayrı takip edin

Çalışan politika onayı takibi yalnızca imzalandı durumundan ibaret değildir. Uygulamanın isteği ne zaman oluşturduğunu, çalışanın ne zaman bildirim aldığını ve politikayı ne zaman açtığını, onayladığını veya reddettiğini kaydedin. E-posta teslimi başarısız olursa bunu kaydedin ve yöneticinin isteği yeniden gönderebilmesini sağlayın.

Yeni işe başlayanlar için özel bir işlem gerekir. Gerekli politikaları işe başlama tarihinden itibaren veya işe alım grubu aracılığıyla atayın. Bir çalışan müşteri hizmetlerinden finansa geçtiğinde dizin güncellemesi yeni görev için politikaların incelenmesini tetikleyebilir. Uygulama finans politikalarını atarken önceki onayları koruyabilir.

AppMaster'da dizin, politika ve atama kayıtları birbiriyle ilişkili veri modellerinde tutulabilir. Görsel bir iş süreci, İK bir sürüm yayımladığında veya çalışanın ekibi değiştiğinde atamalar oluşturabilir.

Herkese spam göndermeden yanıt vermeyenleri hatırlatın

Hatırlatıcılar kayıtların tamamlanmasını destekler, ancak fazla mesaj insanların bunları görmezden gelmesine yol açar. Bir politikayı yayımlarken ilk hatırlatma tarihini belirleyin. Uygun bir program, son tarihten birkaç gün önce bir hatırlatma ve çalışan hâlâ yanıt vermediyse son tarihte bir hatırlatma göndermektir.

Herhangi bir şey göndermeden önce kişinin durumunu kontrol edin. Güncel sürümü kabul eden çalışanlara takip mesajı gönderilmemeli, yanıt gönderildiği anda tüm bekleyen hatırlatıcılar durmalıdır.

Politikanın adını, sürümünü ve son tarihini belirten doğrudan bir mesaj kullanın. Yalnızca küçük bir grubun yapması gereken işler varken geniş duyurular göndermeyin. Uzaktan çalışma politikasını pazartesi günü tamamlayan bir çalışan, henüz başlamamış bir iş arkadaşıyla aynı cuma hatırlatmasını almamalıdır.

Ölçülü bir eskalasyon yolu belirleyin

Son tarihten sonra gecikmiş görevi çalışana gönderin, ardından takibi yapacak kişiyi bilgilendirin. Birçok şirkette bu kişi çalışanın yöneticisi veya bir İK sorumlusudur. Bu kişiye politika, son tarih ve mevcut durum için basit bir görünüm sunun.

Kısa bir program genellikle işe yarar:

• İlk hatırlatmayı son tarihten 5 ila 7 gün önce gönderin.
• Son hatırlatmayı son tarih günü gönderin.
• Son tarihten sonra yöneticiyi veya İK sorumlusunu bilgilendirin.
• Görev gecikmiş olarak kalırsa başka bir takip mesajı gönderin.

Her politika için aynı programı kullanmayın. Zorunlu bir güvenlik kuralı, küçük bir el kitabı güncellemesine göre daha hızlı bir eskalasyon gerektirebilir. Hatırlatma zamanını ve eskalasyon sorumlusunu her politika kaydında belirleyin.

AppMaster'da görsel bir iş süreci, alıcıları onay durumuna göre filtreleyebilir, mesajları zamanlayabilir ve biri yanıt verdiğinde görevi güncelleyebilir.

Denetim geçmişini anlaşılır tutun

Bir denetim görünümü, onlarca çalışan kaydını açmadan dört soruyu yanıtlamalıdır: politikayı kim aldı, kim onayladı, kimin işlem yapması gerekiyor ve son tarihi kim kaçırdı? Her politika sürümünün üst kısmında atanan, onaylanan, bekleyen ve gecikmiş toplamlarını gösterin.

Sayıları ilk atama listesine göre hesaplayın. 3.0 sürümünü 80 kişi aldıysa, beş kişi daha sonra başka bir ekibe geçse bile 80 atandı olarak gösterin. Bu, yayınlanma tarihindeki kaydın doğruluğunu korur.

Kayıtları bulmayı kolaylaştırın

Filtreler geçmişin karmaşık bir tabloya dönüşmesini önler. Yöneticilerin çalışan politika onaylarını politika adı ve sürümüne, ekip veya departmana, onay durumuna, atama veya onay tarihine ve çalışana göre filtrelemesine izin verin.

Her çalışan kaydında açık bir zaman çizelgesi bulunmalıdır: uygulamanın politikayı ne zaman atadığı, bu olay izleniyorsa çalışanın ne zaman açtığı, ne zaman onayladığı ve tam olarak hangi sürümü kabul ettiği gösterilmelidir. Atama ve onay sırasında çalışanın görevini veya ekibini ve onayladığı ifadeyi kaydedin.

Bir revizyon yayımladığınızda eski bir onayı asla üzerine yazarak değiştirmeyin. 2.0 sürümü yeni bir atama ve son tarih oluşturur. 1.0 sürümü ilk metni, alıcıları ve onaylarıyla geçmişte kalır. Bir çalışanın her iki sürümü de kabul etmesi normaldir.

Kayıtları bağlamıyla dışa aktarın

İç inceleme için yalnızca adlardan oluşan bir liste yerine tarihli bir rapor dışa aktarın. Politika başlığını, sürümünü, yayınlanma tarihini, son tarihi, çalışan bilgilerini, durumu, onay zamanını ve raporun oluşturulma tarihini ekleyin.

AppMaster ile oluşturulan bir uygulama politika kayıtlarını, atamaları, hatırlatıcıları ve onayları bağlantılı veri tablolarında saklayabilir. Yöneticiler tek bir çalışanın geçmişini inceleyebilir veya elektronik tabloları elle birleştirmeden bir politika sürümünün tüm kaydını dışa aktarabilir.

Örnek: uzaktan çalışma politikasını güncelleme

İK, ev ofisi ekipmanı için geri ödeme kurallarını değiştirir. Mevcut uzaktan çalışma politikasında zaten 146 onay bulunduğundan, politikayı yerinde düzenlemek kaydı belirsizleştirir. Kendi yürürlük tarihi, onay durumu ve yayınlanma tarihi olan 2. sürümü oluşturun.

Değişikliği anlaşılır bir dille açıklayın. Örneğin politika, çalışanların belirli bir tutarın üzerindeki ekipman alımlarından önce yönetici onayı alması ve makbuzları 30 gün içinde göndermesi gerektiğini söyleyebilir. Politikanın tamamını erişilebilir tutun, ancak çalışanların iki uzun belgeyi karşılaştırmak zorunda kalmaması için kısa bir özet ekleyin.

2. sürümü yeni kurallardan etkilenen kişilere atayın: tamamen uzaktan ve hibrit çalışanlar, yöneticileri ve talepleri inceleyen finans çalışanları. Tamamen ofiste çalışanların gereksiz bir görev almasına gerek yoktur.

3. sürüm ilk alıcıları ve onaylarıyla olduğu gibi kalır. 2. sürüm yeni bir döngü başlatır. 1. sürümü kabul eden bir çalışanın 2. sürümü de onaylaması gerekir, çünkü masraf koşulları değişmiştir.

Yeni kurallar yürürlüğe girmeden yedi gün önce gibi bir son tarih belirleyin. İK politikayı yayımladığında ilk bildirimi gönderin, ardından yalnızca onayı tamamlamayan çalışanlara hatırlatın. Yöneticiler yalnızca kendi ekiplerini görmeli, İK ise 2. sürümü filtreleyerek kimin onayladığını, politikayı kimin açmadığını veya son tarihi kimin kaçırdığını inceleyebilmelidir.

Kaydı zayıflatan hatalar

Yayımlanmış bir politikanın arkasındaki dosyayı değiştirmeyin. Harcama limiti veya iletişim kişisi gibi küçük bir değişiklikte bile yeni sürüm oluşturun. 1.2 sürümünü kabul eden biri 1.3 sürümünü otomatik olarak kabul etmiş sayılmaz.

E-postanın açılması yararlı bir teslimat bilgisidir, ancak onay değildir. İnsanlar bir mesajı yanlışlıkla açabilir veya politikayı okumadan ön izleyebilir. Çalışanlardan «Onaylıyorum» seçeneğini işaretlemek gibi net bir işlem yapmalarını isteyin ve yanıt zamanını politika sürümüyle birlikte saklayın.

Her hatırlatmadan önce güncel durumu kontrol edin. Çalışan onayı tamamladığında onu hatırlatma grubundan çıkarın. Fazladan mesajlar çalışanları rahatsız eder ve sürecin kötü yönetildiği izlenimini yaratır.

Erişim kuralları da önemlidir. Küçük bir politika ekibine politika metnini oluşturma ve düzenleme izni verin. Yöneticilerin ekiplerinin tamamlanma durumunu görmesi gerekebilir, ancak yayımlanmış bir belgeyi veya çalışan yanıtını değiştirememelidir.

Eski çalışanlar geçmiş raporlarda yer almaya devam etmelidir. İşten ayrıldıklarında onay kayıtlarını silmeyin. İstihdam durumlarını sona ermiş olarak işaretleyin, gerektiğinde kişisel verilere erişimi sınırlayın ve çalıştıkları döneme ait onayı saklayın.

Küçük bir iş akışıyla başlayın

Güncellenmiş bir uzaktan çalışma kuralı veya kabul edilebilir kullanım politikası gibi çalışanların zaten onaylaması gereken tek bir politikayla başlayın. Önce küçük bir grubu, örneğin 20 çalışanlı tek bir departmanı davet edin. Sınırlı bir başlangıç, uygulama şirket genelinde resmî kayıt hâline gelmeden önce eksikleri ortaya çıkarır.

Ekibinizin saklaması gereken bilgileri kaydedin: politika başlığı, sürüm, yayınlanma tarihi, yürürlük tarihi, çalışan ataması, son tarih, yanıt tarihi ve onay durumu. Taslak, Onaylandı, Gönderildi, Onaylandı, Gecikmiş ve Arşivlendi gibi anlaşılır durumlar kullanın.

Sürecin her iki tarafını da test edin. Atanan bir çalışan yayımlanmış sürümü okuyabilmeli ve onay gönderebilmelidir. Uygulama atama tarihini, yanıt tarihini ve politika sürümünü birlikte kaydetmelidir. Hatırlatma yalnızca yanıt vermemiş test çalışanına ulaşmalı, 2. sürüm yayımlandığında da 1. sürümün tüm yanıtları korunmalıdır.

AppMaster ile ayrı politika, sürüm, çalışan, atama ve onay kayıtları kullanarak kodsuz bir şirket içi uygulama oluşturabilirsiniz. Politikaları atayan, yanıtları kaydeden ve yalnızca yanıt vermemiş çalışanlara hatırlatma gönderen bir iş süreci oluşturun. Ardından her grubun gerçekleştirdiği görevlere göre basit çalışan ve yönetici ekranları hazırlayın.

İlk politika döngüsünden sonra yöneticilere gerçekten hangi raporları ve durum görünümlerini kullandıklarını sorun. Departmana göre gecikmiş sayıları, bir denetim için dışa aktarım veya çalışanın izinden dönmesinin ardından bildirimi yeniden gönderme seçeneğine ihtiyaç duyabilirler. Bu işlevleri gerçek kullanım ihtiyaç gösterdiğinde ekleyin.

İlk küçük iş akışı uygulamaya net bir yapı kazandırır: tek bir yayımlanmış sürüm, belirlenmiş bir kitle, kaydedilmiş onaylar ve anlaşılır bir geçmiş. Bu kayıt güvenilir biçimde çalıştıktan sonra kapsamı genişletin.