Etiler Web Yazılım Rehberi: Randevu, CRM ve Portal

Randevu alan bir hizmet işletmesinde web yazılım projesi yalnızca takvim ekranından ibaret değildir. Müşterinin uygun zamanı seçmesi, ekibin kapasiteyi yönetmesi, CRM kaydının güncel kalması, bildirimlerin doğru kişiye ulaşması ve portalda yalnız yetkili verinin görünmesi aynı işletim modelinin parçalarıdır. Bu parçalar birbirinden kopuk tasarlanırsa çift kayıt, yanlış bildirim, kapasite aşımı ve manuel takip oluşur.

Bu rehber Etiler, Nisbetiye ve Akatlar çevresindeki hizmet işletmelerini bir proje senaryosu olarak ele alır; Kumsal Ajans’ın bölgede ofisi veya ölçülmüş yerel sonucu olduğu iddia edilmez. Amaç, randevu–CRM–bildirim–portal kapsamını özellik isimleriyle değil veri sahipliği, durum geçişi, yetki ve kabul kanıtıyla yazabilmenizdir.

Önce sistemi değil işletim kuralını modelleyin

“Online randevu, CRM ve müşteri portalı istiyoruz” cümlesi teklif için yeterli değildir. Hangi hizmetlerin randevuya açık olduğu, süre ve hazırlık zamanları, çalışan veya kaynak kapasitesi, iptal sınırı, bekleme listesi, ödeme gereksinimi ve tekrar randevu koşulu belgelenmelidir. Yazılım bu kuralları uygulayabilir; tanımlanmamış operasyonu kendiliğinden düzeltemez.

Her kural için karar sahibi belirleyin. Örneğin kapasiteyi operasyon, müşteri verisini iş birimi, erişim politikasını güvenlik sorumlusu, bildirim metnini marka veya hukuk ekibi onaylayabilir. Teklifte “müşteri isterse yapılır” yerine bu bağımlılıkların kimden, hangi tarihte ve hangi formatta alınacağı yazılmalıdır.

Randevudan portala yedi durumlu işlem zinciri

Kumsal Ajans’ın bu içerik için oluşturduğu zincir, tek bir müşteri talebinin sistemler arasında hangi durumda bulunduğunu görünür kılar. Her geçişin tetikleyicisi, sorumlusu, yan etkisi ve geri alma koşulu olmalıdır.

1. Talep: Kullanıcı hizmeti, iletişim tercihini ve gerekli ilk bilgileri iletir.
2. Uygunluk: Sistem kapasite, hizmet kuralı ve gerekirse ekip değerlendirmesini uygular.
3. Rezervasyon: Seçilen zaman belirli süreyle tutulur ve tekil işlem kimliği oluşturulur.
4. Onay: Müşteri ve ekip aynı durum bilgisini görür; gerekli bildirimler kayda bağlanır.
5. Hizmet: Yetkili ekip gerçekleşme, erteleme veya gelmeme sonucunu işler.
6. Takip: Belge, görev, ödeme veya sonraki randevu müşteriye yetkisi dahilinde sunulur.
7. Kapanış: İşlem sonucu, saklama kuralı ve raporlama verisi tamamlanır.

Randevu durumlarını ve geçişlerini açık yazın

Asgari durumlar taslak, beklemede, onaylandı, iptal edildi, ertelendi, tamamlandı ve gelmedi olabilir; ancak gerçek adlar işletmenize göre seçilmelidir. Hangi rolün hangi geçişi yapabileceğini, geçişin takvimi ne zaman serbest bırakacağını ve hangi bildirimi üreteceğini ayrı tabloda gösterin. Aynı butona art arda basılması veya bağlantının yeniden denenmesi çift rezervasyon oluşturmamalıdır.

Takvim yalnız uygun saatleri göstermemeli; süre, hazırlık ve temizlik aralığı, paralel kaynak, çalışan izinleri, şube veya oda kapasitesi ve saat dilimi gibi kuralları birlikte değerlendirmelidir. Harici takvim kullanılıyorsa senkronizasyon yönü, gecikme toleransı, çakışma çözümü ve bağlantı kesintisindeki davranış kabul senaryosuna eklenmelidir.

CRM için tek kaynak ve eşleştirme kuralı belirleyin

“CRM entegrasyonu” ifadesi hangi sistemin müşteri kaydının ana kaynağı olduğunu söylemez. Telefon, e-posta veya müşteri numarasıyla eşleştirme; ortak kullanılan iletişim bilgileri; mükerrer kayıt birleştirme; eski verinin taşınması ve silme taleplerinin diğer sistemlere yansıması tanımlanmalıdır. Web yazılımı yeni kayıt açmadan önce eşleşme sonucunu güvenli biçimde değerlendirmeli, belirsiz durumda otomatik birleştirme yapmamalıdır.

KVKK’nın temel ilkeleri kişisel verilerin belirli, açık ve meşru amaçlarla; amaçla bağlantılı, sınırlı ve ölçülü işlenmesini ve gerekli süre kadar tutulmasını öngörür (KVKK temel ilkeler). Bu nedenle form alanı, CRM alanı, portal görünümü, saklama süresi ve erişim rolü aynı veri envanterinde ilişkilendirilmelidir. Hukuki dayanak ve metinler yetkili uzman tarafından doğrulanmalıdır.

Bildirimleri kanal değil olay üzerinden tasarlayın

E-posta, SMS veya uygulama bildirimi seçmek tek başına kapsam değildir. Hangi olayın hangi alıcıya, hangi dille, ne kadar gecikmeyle ve kaç kez bildirim üreteceğini belirleyin. Randevu oluşturma, değişiklik, hatırlatma, iptal, başarısız ödeme ve portal görevi farklı şablon ve sorumlular gerektirir.

Gönderim başarısız olduğunda yeniden deneme sayısı, alternatif kanal ve ekibin göreceği uyarı tanımlanmalıdır. Bildirimin “gönderildi” olması teslim veya okuma anlamına gelmez; sağlayıcı yanıtı, uygulama durumu ve müşteri kaydı birbirinden ayrılmalıdır. Pazarlama mesajlarıyla işlem bildirimlerini aynı izin ve tercih mantığına bağlamayın.

Müşteri portalında yetkiyi her istekte doğrulayın

Portal, müşterinin yalnız kendisine ait randevu, belge, görev ve mesajları görmesini sağlamalıdır. OWASP yetkilendirme rehberi en az ayrıcalık, varsayılan ret ve her istekte izin kontrolünü önerir (OWASP Authorization Cheat Sheet). Bu nedenle yalnız ekranda buton gizlemek yeterli değildir; sunucu her nesne ve işlem için kullanıcı–kayıt ilişkisini doğrulamalıdır.

Rol matrisi müşteri, müşteri temsilcisi, uzman, operasyon yöneticisi ve sistem yöneticisi gibi gerçek sorumlulukları kapsamalıdır. Görme, ekleme, değiştirme, onaylama, dışa aktarma ve silme izinlerini ayrı yazın. Hesap kapatma, çalışan ayrılığı, yetki değişikliği ve ortak müşteri hesabı senaryolarını test edin.

Loglama ve hata yönetimini teslimat sayın

İşletim ekibi “Randevu neden oluşmadı?” sorusuna yalnız kullanıcı ekranıyla cevap veremez. OWASP uygulama loglarının olayın ne zaman, nerede, kim tarafından ve ne sonuçla gerçekleştiğini analiz etmeye yetecek bağlam taşımasını önerir; logların kendisi de yetkisiz erişim ve değiştirmeye karşı korunmalıdır (OWASP Logging Cheat Sheet).

Teklifte işlem kimliği, kritik durum değişiklikleri, entegrasyon yanıtı, hata sınıfı, uyarı eşiği ve log saklama sorumlusu yer almalıdır. Parola, tam ödeme bilgisi veya gereksiz kişisel veri loga yazılmamalıdır. Teknik log, işletim geçmişi ve yasal kayıt ihtiyacı ayrı veri kümeleri olarak ele alınmalıdır.

Kesinti ve geri dönüş senaryolarını baştan kabul edin

CRM, SMS sağlayıcısı veya takvim geçici olarak çalışmadığında kullanıcının talebi kaybolmamalıdır. Kuyruklama, kontrollü yeniden deneme, manuel iş listesi ve sorumlu ekibe uyarı seçeneklerinden uygun olanı belirleyin. Bağlantı geri geldiğinde aynı işlemin iki kez uygulanmaması ve güncel durumun eski veriyle ezilmemesi için senaryo testi yazın.

Yedekleme yalnız dosya alınması değildir. Geri yükleme süresi, son kabul edilebilir veri kaybı, şifreleme, erişim, test periyodu ve sonuç kaydı teklifin parçası olmalıdır. Sağlayıcı değişiminde müşteri, randevu, belge, izin ve işlem geçmişinin hangi formatta dışa aktarılacağı belirtilmelidir.

Teklif karşılaştırma ve kabul kontrolü

• İş kuralları ve randevu durum geçişleri
• Veri sözlüğü, tekil kayıt ve mükerrer eşleştirme modeli
• Rol–nesne–işlem bazlı yetki matrisi
• Bildirim olayları, şablon sahipleri ve başarısızlık davranışı
• Entegrasyon, kuyruk, yeniden deneme ve mutabakat senaryoları
• Log, uyarı, destek ve olay müdahale sorumluluğu
• Taşıma, yedekleme, dışa aktarma, dokümantasyon ve eğitim planı

Bu kalemleri demo ekranı yerine çalışan kabul senaryolarıyla doğrulayın. Hazır ürün ile projeye özel geliştirme kararını hazır altyapı ve projeye özel web yazılım rehberiyle değerlendirebilir; uygulama kapsamını Kumsal Ajans web yazılım hizmeti üzerinden inceleyebilirsiniz.

Başarılı sonuç; çok sayıda özellik değil, müşterinin tekil kayıtta ilerlediği, ekibin istisnaları yönetebildiği, erişimlerin sınırlandığı ve sistem değişiminde verinin teslim edilebildiği bir işletim altyapısıdır.