E-pin Scriptini Kurdun Ama Operasyonu Hâlâ Kafandan Yürütüyorsun: Büyüyen Bayilerin Kimseye Söylemediği Prosedür Sistemi

Çoğu işletme sahibi şunu sanır: doğru e-pin scriptini kurduğu gün operasyon kendi kendine yürür. Panel açılır, ürünler girilir, ödeme geçidi bağlanır ve iş "otomatik" hale gelir. Oysa sahada gördüğümüz tablo çok farklı. Aynı e-pin satış yazılımını kullanan iki bayiden biri ayda 400 sipariş taşırken diğeri 4.000 siparişte bile sakin kalıyor. Aradaki fark yazılımın sürümü değil; ikincisinin her tekrar eden işi yazılı bir prosedüre bağlamış olması.

Burada acı gerçek şu: senin işletmendeki bilgi büyük ölçüde senin kafanda duruyor. Hangi tedarikçiden kaç dakikada kod geldiğini, hangi müşterinin iade istediğinde ne yapılacağını, stok kritik seviyeye düştüğünde kimin arandığını sadece sen biliyorsun. Bu, küçükken hız avantajıdır; büyürken tavan olur. Bir dijital ürün satış scripti sana altyapı verir ama karar ağacını vermez. Prosedür tam olarak o karar ağacının dışarı çıkarılmış, yazıya dökülmüş ve panele gömülmüş halidir.

Neden "iyi yazılım" tek başına kaosu çözmüyor?

Yazılım, kararların uygulandığı yerdir; kararların üretildiği yer değil. Panelin sipariş durumunu "beklemede"den "tamamlandı"ya çevirmesi teknik bir işlem. Ama o siparişin neden beklemede kaldığını, kaç dakika sonra kimin devralacağını, müşteriye hangi mesajın gideceğini belirleyen şey prosedürdür. Pinova gibi lisanslı bir e-pin yazılımı sana durum alanları, rol yetkileri, log kayıtları ve otomatik bildirim kancaları sunar. Bunları doldurmadığın sürece elinde boş bir iskelet kalır.

Kaosun gerçek sebebi genelde tek bir şeydir: aynı işin iki farklı kişi tarafından iki farklı biçimde yapılması. Bir gün müşteriye "kodu yeniliyoruz" denir, başka gün "iade açtık" denir. Müşteri aynı sorunda iki farklı cevap alınca güven kaybolur. Prosedür, cevabı standartlaştırır.

Prosedür yazmak bürokrasi mi, yoksa hız mı getiriyor?

Prosedür kelimesi kulağa ağır geliyor ama pratikte bir sayfayı geçmez. İyi bir prosedürün üç bileşeni var: tetikleyici olay, sırayla yapılacak adımlar ve bitiş kriteri. "Sipariş 10 dakikadır beklemede" bir tetikleyici. "Tedarikçi stoğunu kontrol et, yoksa alternatif havuza geç, müşteriye şablon mesajı gönder" adımlar. "Sipariş tamamlandı veya iade edildi" bitiş kriteri. Bu kadar.

Bürokrasi, prosedürün kâğıtta kalmasıdır. Hız ise prosedürün panele gömülmesidir. Bir adımı dijital ürün satış yazılımının içinde otomatik hale getirebiliyorsan, o adım artık kimsenin hatırlamasına ihtiyaç duymaz. Prosedürün asıl amacı insan hafızasını devreden çıkarmaktır.

Hangi işleri önce prosedüre bağlamalısın?

Her şeyi aynı anda yazmaya çalışan herkes vazgeçiyor. Doğru sıra şudur: önce sık tekrarlanan ve hata maliyeti yüksek olan işler. Teslimat akışı birinci sırada, çünkü hem her siparişte yaşanır hem de hata müşteriyi doğrudan kaybettirir. İkinci sırada ödeme uyuşmazlıkları var; burada yapılan hata parayla ölçülür. Üçüncü sırada tedarik ve fiyatlama geliyor.

Şunu bir ölçüt olarak kullan: bir işi ayda beşten fazla yapıyorsan ve her seferinde biraz farklı yapıyorsan, o iş prosedür adayıdır. Ayda bir yapılan işler için prosedür yazmak zaman kaybı olur.

Prosedürü panele nasıl gömersin?

Yazılı metin iyi bir başlangıç ama son durak değil. Hedef, prosedürün büyük kısmının epin yazılım tarafında zorunlu hale gelmesidir. Bunu üç kaldıraçla yaparsın. Birincisi durum alanları: sipariş sadece tanımlı durumlar arasında geçiş yapabiliyorsa kimse ara adım atlayamaz. İkincisi rol yetkileri: iade açma yetkisi sadece belirli rolde olduğunda karar tek kanaldan akar. Üçüncüsü loglar: kim ne zaman ne yaptı sorusunun cevabı panelde duruyorsa tartışma biter.

Şablon mesajlar da çoğu kişinin atladığı bir kaldıraçtır. Destek tarafında en sık yazılan on cevabı şablona çevirdiğinde hem süre kısalır hem de dil tutarlı olur. Bu, prosedürün müşteriye bakan yüzüdür.

Prosedürün işlediğini nasıl doğrularsın?

Yazdığın şeyin uygulandığını varsayma. Haftada bir, rastgele beş siparişi baştan sona geriye doğru oku. Log kayıtları prosedürdeki sırayı takip ediyor mu? Atlanan adım var mı? Eğer aynı adım sürekli atlanıyorsa iki ihtimal var: adım gereksizdir ya da yapılması fazla zahmetlidir. Her ikisinde de çözüm prosedürü sadeleştirmektir, personeli sıkıştırmak değil.

İkinci doğrulama yöntemi devir testidir. Bir günlük işi, prosedür dokümanını okuyan yeni birine bırak. Sana kaç kez soru soruyorsa prosedürün o kadar boşluğu var. Bu test acıtır ama en dürüst geri bildirimi verir.

Prosedür seni işine mahkûm mu eder, özgür mü bırakır?

En sık duyduğumuz itiraz: "Ben zaten her şeyi biliyorum, yazmaya gerek yok." Doğru, sen biliyorsun. Sorun şu ki bildiğin şey satılabilir bir varlık değil. Prosedüre bağlanmamış bir işletme, sahibi tatile çıktığında duran işletmedir. Bağlanmış olan ise devredilebilir, ölçeklenebilir ve değerlenebilir bir yapı olur. Prosedür, işletmeni sana bağımlı olmaktan kurtaran tek araçtır.

Bunun yazılım tarafı hazır beklemektedir. Rol bazlı yetkiler, durum makineleri, log altyapısı ve otomatik bildirimler özellikler sayfasında tek tek duruyor. Senin yapman gereken, kafandaki karar ağacını bu araçlara yerleştirmek.

Prosedür yazmak masa başı işi gibi görünür ama karşılığını ilk yoğun günde alırsın. İşleyişi gözünle görmek istiyorsan canlı demo üzerinden durum akışlarını, rol yetkilerini ve log ekranlarını kurcala; kendi karar ağacını nereye yerleştireceğini oradaki ekranlara bakarken çok daha net göreceksin.