Uygun paketi randevuya bağlama

Bir danışanın hesabında birden fazla paket bulunuyorsa, randevuya paket bağlamak yalnızca bakiyeden bir seans düşmek değildir. Seçilen paket o hizmeti, şubeyi ve randevu tarihini kapsamalı; yeterli serbest hakkı bulunmalı; geçerlilik koşulu karşılanmalıdır. Yanlış paket seçilirse danışan doğru hizmeti almış olsa bile hakkı yanlış yerde azalır ve daha sonra iade veya düzeltme gerekir. Bu nedenle önce uygunluk kurallarını yazılı hale getirin, sonra otomatik seçim ya da görevli seçimi tasarlayın.

Kurgusal örnek: Eylül’ün 6 seanslık klinik pilates paketi 20 Aralık’ta bitiyor. Ayrıca 4 seans manuel terapi paketi 31 Ocak’a kadar geçerli. 18 Aralık’taki pilates randevusuna yalnız ilk paket uygundur. Hesapta toplam 10 hak görünmesi bu randevu için karar ölçütü değildir. Randevu 22 Aralık’a alınırsa ilk paketin süresi geçmiş olabilir; taşınan randevuda sistemin hangi tarihe göre uygunluk denetlediği politika ve ürün davranışında açık olmalıdır.

Seçim adımlarını şu sırayla tanımlayın: hizmet türü eşleşiyor mu; şube veya uzman kısıtı var mı; randevu tarihine göre paket aktif mi; hak kullanılabilir mi, yoksa başka randevuya ayrılmış mı; dondurma veya ödeme istisnası var mı; birden fazla paket uygunsa öncelik nedir? “Önce en eski biten” kuralı yararlı olabilir, fakat sadece aynı hizmet ve şartlar için eşdeğer paketler arasında uygulanmalıdır. Kuralın gerekçesini kullanıcıya gösterin ve elle farklı paket seçme yetkisini rol/politikayla sınırlayın.

Randevu kaydında paket kimliğini ve ilgili hakkın rezervasyon/tüketim durumunu saklayın. Kurum randevu oluştururken hakkı rezerve ediyor, seans gerçekleşince tüketiyorsa iki olayın tarihini ayırın. İptal, geç iptal, gelmeme ve uzman iptali için hangi hareketin oluşacağını önceden kararlaştırın. Aynı randevunun tekrar kaydedilmesi iki kez hak ayırmamalı; eşzamanlı olarak son hakkı iki kullanıcı seçerse sistem birini reddetmeli veya açık bir çakışma çözümü sunmalıdır. PostgreSQL transaction ve satır kilitleme belgeleri, eşzamanlı güncellemelerde tutarlılık için teknik yapı taşlarını açıklar; klinik politikası belirlemez (transactions, explicit locking).

Karşı örnek: Sadece danışanın toplam hakkını kontrol edip paketi randevuya bağlamak, başka hizmette kullanılabilen hakları yanlış tüketebilir. Randevu tarihi değişince eski paket ilişkisini sessizce bırakmak da iki pakette aynı seans için hak ayırabilir. Her değişiklikte önceki ve yeni paket, randevu zamanı ve nedeni görünür olmalıdır.

Kabul testi için tek uygun paket, iki eşdeğer paket, yanlış hizmet, süresi dolmuş paket, dondurulmuş paket, rezerve edilmiş son hak ve aynı anda iki kullanıcı vakalarını deneyin. Her birinde gösterilen seçenek, bakiye ve hareket kaydı beklenen sonuçla eşleşmelidir. Danışana randevu teyidinde hangi paketin kullanılacağını ve iptal politikasını sade biçimde açıklayın. klinik kullandığı sürümde bu davranışı doğrulamalıdır.

Taşıma ve hata senaryoları

Randevu değiştiğinde yalnız takvim saatini güncellemek yeterli olmayabilir. Yeni tarih, paketin geçerlilik aralığının dışına çıkıyorsa kullanıcıya açık bir karar verin: başka uygun paket seçmek, kliniğe danışmak veya randevuyu farklı tarihe almak. Paketin bitiş tarihi randevu alma anına mı yoksa hizmetin gerçekleştiği güne mi göre kontrol ediliyor, bunu kuralda belirtin. Takvimdeki saat dilimi ve şubenin yerel tarihi özellikle gece yarısına yakın randevularda önem taşır; arayüzde görülen gün ile veritabanı zamanı farklıysa uygunluk hatası görülebilir.

Beklenen sonuçları tabloya dökün. Örneğin “randevu oluşturuldu” satırında paket kimliği, hizmet kimliği, rezervasyon miktarı ve bakiye; “iptal edildi” satırında geri bırakılan rezervasyon ve gerekiyorsa geç iptal hareketi; “randevu taşındı” satırında eski bağlantının kapatılması ve yeni tarihin uygunluğu bulunmalı. Bir destek görevlisi test hesabıyla bu akışı yürütüp her adımda danışan görünümünü ve hareket geçmişini karşılaştırabilir. Hata çıktığında düzeltmeyi doğrudan toplam bakiyeye sayı yazarak yapmak yerine, ilgili randevu ve hareket kimliği üzerinden inceleyin.

Sahada uygulama

Küçük bir pilotla başlayın: bir şube, iki hizmet ve birkaç deneme danışanı seçin. Önce test senaryolarını personelle yürütün, sonra bir hafta boyunca paket seçimiyle ilgili destek kayıtlarını sayın. Tekrarlanan karışıklık görürseniz, daha fazla kullanıcı eğitimi vermek yerine hizmet adlarını veya seçim ekranındaki açıklamayı düzeltin. Pilot sonucunda hangi kuralın değiştiğini ve kimin onayladığını kaydedin; böylece sonraki şubede aynı hatayı yeniden keşfetmezsiniz.