Keşif randevusu bir mekân için tarih ister; servis talebi ise zaten monte edilmiş bir cihaza ya da yürüyen bir plana bağlanır. Bir talebin hangi tip olduğu formdaki açılır menüde değil, kaydın hangi varlığa bağlandığında kararlaştırılır. Diotek’te keşfi bitiren şey mekânın görülmesi, servis talebini kapatan şey cihazın çalışması; tek bir durum alanı iki ayrı bitişi adlandıramaz.
Talep tek kapıdan girince sıra telefonda çözülür
Diotek klima ve havalandırma işi yapıyor. Firmaya ulaşan talep tek tip değil: biri satış öncesi keşif, diğeri montaj sonrası bakım ya da arıza. Eskiden ikisi de aynı telefon hattından geliyordu. Hangi talebin ne olduğu ancak konuşarak anlaşılıyor, sınıflama işi hattın öbür ucundaki kişiye kalıyordu.
Bu düzenin bedeli sezon başında ortaya çıkıyor. Isıtma ya da soğutma ihtiyacı aynı haftalarda yoğunlaştığında iki talep tipi üst üste biniyor. Hat meşgulken siteye gelen ziyaretçi tekrar aramıyor, kayboluyor. Site o sırada akışın dışında duran bir vitrin olduğu için talebi tutacak bir yeri de yok.
Kaybın nedeni personelin yavaşlığı değil. Talep girişinin tek bir kanala, üstelik senkron bir kanala bağlanmış olması. Telefon, iki tarafın aynı anda müsait olmasını şart koşar. O şart sağlanmadığı her an talep hiç kaydedilmemiş sayılır. Yeni kurulumda talep girişi telefon hattına bağlı değil; mesai dışında gelen keşif ve servis talepleri de yazılı kayda düşüyor. Kayıt yazılı olduğu için de kimin ne zaman ne istediği sonradan konuşmaya bağlı kalmıyor.
Yazılı kayıt operasyona ikinci bir şey daha veriyor: sıra. Telefonla gelen taleplerde geliş sırası kimsede durmaz, çünkü bir kısmı hiç ulaşmamıştır. Yazılı kayıtta her talebin ne zaman geldiği kaydın kendi üzerindedir. Ekip günü kuyruğa bakarak açıyor. Bu, iki tipi ayırmadan önce çözülmesi gereken adım; ayrım ancak taleplerin hepsi kayda düştüğünde anlam kazanıyor.
Ayrı akış her işte gerekmiyor. Talep hacmi düşükse ve gelen her istek aynı tipteyse, ayrı akış kurmanın taşıdığı bir şey yoktur. Yalnız iletişim formu gereken bir tanıtım sitesinde ikinci bir kuyruk açmak, boş bir kutu daha eklemek olur. Ayrımı gerektiren şey talep sayısı değil, taleplerin birbirine benzememesi.
Keşif randevusu bir servis çağrısı gibi davranamaz
Klima işinde cihaz kapasitesi mekâna bağlıdır. Odanın hacmi, yalıtımı ve cephesi hangi cihazın yeteceğini belirler; firma teklif vermeden önce yeri yerinde görmek zorundadır. Bu yüzden keşif randevusu mekânı merkeze alır. Ziyaretçi cihaz seçmeden önce bir yer için tarih ister. Talebin içinde bir ürün kodu yoktur, bir adres ve bir zaman aralığı vardır.
Servis talebi ise tersinden kurulur. Ortada zaten monte edilmiş bir cihaz vardır; talep o cihaza bağlanır. Montaj sonrası bakım ve arıza bildirimi siteden açılıyor ve keşif kuyruğuna karışmadan kendi akışında operasyona düşüyor. İki kuyruk ayrı olduğu için sezon başında biri şiştiğinde diğeri yavaşlamıyor.
Diotek’in klima ve havalandırma sitesinde bu iki akışı baştan iki ayrı akış olarak kurduk. Sonradan forma eklenen bir “talep tipi” açılır menüsü değil: keşif kaydı adres ve tarih ister, servis kaydı cihazı ister.
İki akışın ayrı olmasının bir nedeni daha var: bitiş tanımları farklı. Keşif randevusu, mekân görülüp kapasite belirlendiğinde tamamlanır; ardından sıra teklife gelir. Servis talebi ise cihaz çalışır hâle geldiğinde kapanır. İki tipin tek kuyrukta durması, iki farklı “tamamlandı” tanımını tek bir durum alanına sığdırmak demek olurdu. Alan tek olduğunda da durum adları ikisine birden uyacak kadar genelleşir ve hiçbirini tarif etmez.
Alternatifi de düşündük: tek form, üstüne bir tip alanı. Ucuz görünen yol bu. Ama tek form kurulduğunda iki talebin zorunlu alanları birleşir. Keşif için adres zorunludur, cihaz zorunlu değildir; servis için tam tersi. Tek formda ikisini de zorunlu yapamazsınız, ikisini de isteğe bağlı bırakırsanız kayıt eksik açılır. Eksik kayıt da operasyonu yine telefona geri gönderir. Ayrımı alan seviyesine indirmek, ayrımı ortadan kaldırmaz; onu doğrulama katmanının çözemeyeceği bir yere taşır.
Saati tutmak, planı tutmak değildir
Diş tedavisi tek randevuda bitmez. Plan diş bazında kurulur: hangi dişe hangi işlemin yapılacağı belirlenir ve iş sıralı seanslara bölünür. Seanslar haftalara yayılır, arada değişir. Yani tedavi planı randevudan bağımsız, kendi başına duran bir kayıttır.
Randevunun tedavi planının belirli bir adımına bağlandığı diş kliniği CRM’inde takvim planın ikinci bir kopyası değil, planın zaman üzerindeki izdüşümü. Adım değiştiğinde ya da araya seans eklendiğinde takvim de buna göre kayıyor. Randevu boşta kalan bir kayıt olmuyor, çünkü işaret ettiği bir adım her zaman var.
Klinik daha önce genel amaçlı bir randevu yazılımı kullanıyordu. O yazılım saati tutuyor, tedavi planının hangi adımında olunduğunu tutmuyordu. Hastanın planın neresinde olduğu takvimden çıkarılmaya çalışılıyordu: geçmiş randevulara bakılıyor, aradaki iptaller hatırlanmaya çalışılıyor, kalan seans sayısı kafadan hesaplanıyordu. Bu okuma her seferinde yeniden yapıldığı için de iki kişi aynı hastaya baktığında iki farklı cevap çıkabiliyordu.
Ayrımı taşıyan şey burada bir ekran değil, bir bağ. Randevu kaydı hangi plan adımına ait olduğunu kendi üzerinde tutuyor. Bağ kayıtta durduğu için plan değişikliği takvime kendiliğinden yansıyor; kimsenin randevuları elle taşıması gerekmiyor.
Bağın ikinci faydası raporlamada görünüyor. Plan kendi başına bir kayıt olduğu için kaç adımın tamamlandığı, kaçının beklediği ve hangi seansın ertelendiği plandan okunuyor; takvimi tarayıp saymak gerekmiyor. Klinik yöneticisi hastanın planın neresinde olduğunu tek ekrandan görüyor.
Tek seansta biten işlerde — tek muayene, tek görüşme, tek ölçüm — randevuyu bir plan adımına bağlamak yapay bir katman ekler. Plan tek adımdan oluşuyorsa plan kaydı zaten randevunun kendisidir. Ayrımı gerektiren şey, işin adımlarının birbirine sıra bağıyla bağlı olması.
Rezervasyon, iptal ve gelmeme aynı işlemin üç yüzü değildir
Pilates salonunda müşteri ders başına ödemez, paket satın alır. Bu tek cümle randevu kaydının anlamını değiştirir: rezervasyon artık yalnız takvimde yer kaplayan bir blok değil, bir bakiyeye işleyen bir harekettir.
Rezervasyon, iptal ve gelmemenin üç ayrı kayıt olarak tutulduğu Pilatesco sisteminde rezervasyon takvime yazılırken paketten bir ders hakkı düşüyor. Bakiye müşteri kaydının üzerinde duruyor, ayrı bir deftere yazılmıyor. İptal, gelmeme ve tamamlanan ders bakiyeye farklı işliyor; hangi durumun hakkı geri verdiği kuralda tanımlı, konuşmada belirlenmiyor.
İptal ile gelmeme takvimde aynı görünür: saat boş kalmıştır. Ama bakiye açısından ikisi aynı şey değildir. Biri hakkı geri verebilir, diğeri veremez; hangisinin hangisi olduğu işletmenin kendi kuralıdır. Bu kural yazılımda tanımlı değilse her vaka mesajlaşmayla çözülür ve aynı soruya iki müşteriye iki farklı cevap verilir.
Bakiyenin müşteri kaydında durması küçük bir ayrıntı gibi görünür ama sorumluluğu yer değiştirir. Bakiye ayrı bir deftere yazıldığında, deftere kimin ne zaman dokunduğu takvimden görünmez; rezervasyon ile bakiye arasındaki bağ kişinin disiplinine kalır. Bakiye müşteri kaydında olduğunda ise her rezervasyon bakiyeyi kendiliğinden hareket ettirir ve kalan hak sorusu bir hatırlama işi olmaktan çıkar.
Kapasite tarafında da benzer bir ayrım var. Bir saat diliminde kaç kişinin ders alabileceğini eğitmen, ekipman ve saat birlikte belirliyor. Bireysel seans ile grup dersi aynı takvimde duruyor ama her biri kendi kapasite kuralıyla açılıyor. Takvim ortak, kural ayrı.
Son olarak iki zamanlama tek kayıtta buluşuyor. Fatura paket satıldığı anda kesiliyor; kullanım ise haftalara yayılan takvimden okunuyor. Satış bir ana, kullanım bir aralığa aittir. İkisi ayrı yerlerde tutulsaydı, ay sonunda satılan ile kullanılanın eşleşmesi elle yapılırdı.
Üç işte ayrımı taşıyan kayıt neydi
Üç iş de aynı soruyu farklı bir varlık üzerinde cevaplıyor: bu talep neye bağlanıyor? Cevap mekân, kurulu cihaz, plan adımı ya da paket bakiyesi olabilir. Ayrımı taşıyan şey her seferinde bu bağ. Aşağıdaki tabloda üç işin ayrımı nerede tuttuğu ve tutmasaydı ne olacağı yan yana duruyor.
| Hangi iki tip ayrıldı | Ayrımı hangi kayıt taşıyor | Ayrılmasaydı ne olurdu |
|---|---|---|
| Satış öncesi keşif randevusu × montaj sonrası servis talebi | Keşif kaydı mekânı ve tarihi, servis kaydı kurulu cihazı merkeze alıyor; iki talep kendi akışında operasyona düşüyor | Sezon başında iki talep aynı hatta üst üste biner, ne olduğu telefonda konuşarak ayıklanır, hat meşgulken ziyaretçi kaybolurdu |
| Randevu × tedavi planı | Randevu, diş bazında seanslara bölünmüş planın belirli bir adımına bağlanan kayıt; plan değişince takvim kayıyor | Yazılım yalnız saati tutar; hastanın planın neresinde olduğu takvimden çıkarılmaya çalışılır, randevu boşta kalan kayıt olurdu |
| Rezervasyon × iptal/gelmeme | Müşteri kaydı üzerinde duran paket bakiyesi; iptal, gelmeme ve tamamlanan dersin bakiyeye nasıl işlediği kuralda tanımlı | Kalan ders hakkı defterde takip edilir, iptalin hakkı geri verip vermediği mesajlaşma üzerinden cevaplanırdı |
Çalışan bir sistemde ayrım görünmez olur; üçüncü sütun onun olmadığı hâli tarif ediyor.
Ayrım forma değil veri modeline yazılır
İki ayrı akış iki ayrı sistem demek değil. Diotek’te keşif ve servis akışları tanıtım sayfalarıyla birlikte aynı tek Laravel uygulamasında duruyor; talep kaydı ile içerik aynı MySQL şeması üzerinde. Ayrım şemada taşındığı için tek uygulama iki kuyruğu ayrışmış hâlde üretebiliyor.
Bunun pratik karşılığı şu: yeni bir sunucu, yeni bir panel ya da ikinci bir yönetim arayüzü gerekmedi. Gereken şey, iki talep tipinin farklı alanlara ve farklı doğrulama kurallarına sahip iki kayıt olarak tanımlanmasıydı. Inertia sayfa geçişini istemcide yapıyor, yönlendirme ve form doğrulaması Laravel’de kalıyor. İki akışın doğrulama kuralları tek yerde durduğu için tip ayrımı istemci koduna sızmıyor; tarayıcıda çalışan kodun hangi alanın hangi tipte zorunlu olduğunu bilmesi gerekmiyor.
Sezon yükünü de aynı kod tabanı karşılıyor. Redis önbelleği sezon başı trafiğini taşıyor; tanıtım sayfaları tekrar tekrar veritabanına inmiyor, talep formları ise her seferinde canlı doğrulamadan geçiyor. Okuma ile yazmanın farklı davranması, iki akışın ayrı sistemlere bölünmesini gerektirmiyor.
Bu ayrımın bir de ölçüm tarafı var. İki tip tek kayıt olduğunda “kaç keşif geldi, kaç servis açıldı” sorusu ancak metin alanları okunarak cevaplanır. Kayıt tipleri ayrı olduğunda aynı soru şemanın kendisinden çıkar; rapor almak için sonradan bir sınıflama katmanı kurmak gerekmez.
Aynı ilke faturalama tarafında da işliyor. Diş kliniği CRM’inde fatura kendi defterinde durmuyor: yapılan işlem hasta kaydında olduğu için faturalanan ile uygulanan tedavi aynı yerden okunuyor. Ayrım ve bütünlük aynı şemada birlikte duruyor — plan, randevu ve fatura ayrı kayıtlar ama aynı hastanın etrafında.
Talep kaydını müşteriye, kurulu cihaza ya da bir plana bağlayan yapıları CRM çalışmalarımızda hep bu sırayla kuruyoruz: önce talebin neye bağlandığını yazıyoruz, ekranı sonra çiziyoruz. Ters sıra denendiğinde ekran güzel çıkıyor, kayıt eksik kalıyor.
Ayrımın kendisi yapılandırılabilir olabilir mi
Buraya kadarki üç iş, ayrımı bizim tanımladığımız işler. Peki ayrımı işletmenin kendisi tanımlayabilir mi? Şu an geliştirdiğimiz AlgoRandevu’da çalıştığımız soru bu.
Randevunun süresini ve arka arkaya diziliş aralığını sektöre gömmek yerine ürün ayarı olarak bırakıyoruz; kural değişince kod değişmesin istiyoruz. Klinikte, salonda ve atölyede randevunun süresi de aralarındaki boşluk da farklı. Bunu koda gömen bir ürün her yeni işletme için yeni bir sürüm gerektirir.
Üzerinde çalıştığımız kurguda randevu kişiye, odaya ya da ekipmana bağlanabiliyor. İşletme kendi kaynağını seçiyor; sektör başına ayrı kurgu yazmıyoruz. Ürünü AlgoKlima ve AlgoCar ile aynı Laravel ve Inertia zemini üzerine kuruyoruz. Randevu kayıtlarını MySQL’de tutuyoruz, önbelleği Redis’te kuruyoruz. Yani yapılandırılabilirlik yeni bir yığın gerektirmiyor, bir tanım katmanı gerektiriyor. Ürün şu an inşa aşamasında.
Diotek’teki gibi iki tipin merkezindeki varlık kökten farklıysa — bir yanda mekân, öbür yanda kurulu cihaz — ayrımı bir ayara indirmek yerine iki akışı açıkça kurmak hâlâ doğru karar olabilir. Ayarlanabilirlik, birbirine benzeyen kuralların değişkenliğini karşılar. Birbirine benzemeyen varlıkları tek şablonun altına sokmaz. Bu yüzden ayarlanabilir randevu tanımı, ayrı akış kurma kararının yerine geçmiyor; onun gerekmediği durumları daraltıyor.
İşinizde ayrı akış gerektiğini gösteren işaretler
Bu yazıdaki üç iş de aynı belirtilerle başladı. Kendi işinizde şunlardan birini görüyorsanız, ayrımı taşıyacak kayıt henüz kurulmamış demektir.
Gelen talebin ne olduğu ancak konuşarak anlaşılıyorsa, sınıflama işi kayda değil telefondaki kişiye kalmıştır. Diotek’te durum tam olarak buydu; talep yazılı kayda düşmediği sürece de değişmiyordu.
Yazılım saati tutuyor ama işin hangi adımında olunduğunu tutmuyorsa, randevu bir plan adımına bağlanmıyor demektir. Diş kliniğinde bunun sonucu, aynı hastanın durumunun iki kişiye iki farklı görünmesiydi.
İptalin hak geri verip vermediği mesajlaşma üzerinden cevaplanıyorsa, iptal ile gelmeme aynı işlem sayılıyor demektir. Pilatesco’da kuralın yazılıma taşınması, bu soruyu her seferinde yeniden tartışmaktan çıkardı.
İşletme kendi işleyişini yazılıma uydurmak zorunda kalıyorsa, randevu tanımı sektöre gömülmüş demektir.
Bu dördü aynı yere çıkıyor: bir bilgi sistemde tutulmuyorsa insanda tutuluyor. İnsanda tutulan bilgi de tatilde, yoğunlukta ve devirde kayboluyor. Randevuyu, planı ve faturayı tek uygulamada ayrı kayıtlar olarak taşıyan yönetim yazılımları işlerimizde ilk yazdığımız şey ekran değil, bu bağlar oluyor.
