Teklif al

CRM · Kadıköy

Kadıköy markaları için CRM

Kadıköy'de klinik, stüdyo, kafe ve küçük perakende yan yana duruyor. İşiniz tek bir randevu defterinden dönüyorsa o defter saati gösteriyor, saatin arkasındaki taahhüdü göstermiyor: müşteri haftalara yayılan çok adımlı bir işin neresinde, bu takvimden okunmuyor. Bu ilçenin işletme dokusuna en yakın işimiz, bir diş kliniği için geliştirdiğimiz CRM. Orada plan ile takvim iki ayrı kayıt; işin sırası planın üstünde duruyor, takvim yalnız o sıranın ne zaman yapılacağını söylüyor.

CRM — Kadıköy

Kadıköy'ün randevuyla çalışan hizmet dokusunda asıl soru sıranın nerede durduğu. Plan diş bazında kuruluyor: hangi dişe hangi işlem yapılacaksa haftalara yayılan sıralı seanslara bölünüyor. Randevu boş bir saat değil; hangi seansın karşılığı olduğunu kendi üstünde taşıyor. Bu yüzden adım değiştiğinde ya da araya yeni bir seans girdiğinde takvim de kayıyor, geride sahipsiz bir randevu kalmıyor. Fatura ayrı bir deftere yazılmıyor: uygulanan işlem zaten hasta kaydında durduğu için faturalanan ile yapılan aynı yerden okunuyor. Süreci Laravel yürütüyor; hasta, plan ve fatura kayıtlarını MySQL tutuyor.

  • Plan diş bazında kuruluyor ve sıralı seanslara bölünüyor; randevu yazılmamışken bile tek başına ayakta duran bir kayıt.
  • Randevu, ait olduğu seansı adıyla taşıyor; adım değişince ya da araya seans girince sonraki randevular planla birlikte kayıyor, plandan kopmuş boş kayıt oluşmuyor.
  • Fatura ikinci bir defterde tutulmuyor; faturalanan ile uygulanan tedavi aynı hasta kaydından okunuyor, rapor da o kaydı başka bir açıdan okuyor.

Neden Algoriel

  • Randevu, plan ve fatura ayrı ayrı

    Diş kliniği CRM'inde tedavi planı diş bazında tutuluyor; randevu planın adımına bağlı, plan kayınca takvim de kayıyor.

  • Talep tipi baştan ayrılır

    Diotek'te keşif randevusu ile servis çağrısı iki ayrı akış; ikisi aynı formdan geçmiyor.

  • İkinci belge açılmıyor

    Tahlil.com'da değerler giriliyor, uzman yorumu aynı kaydın üstüne yazılıyor; sonuç tek yerde duruyor.

  • Geçmiş cihazın altında

    AlgoKlima'da servis geçmişi kişiye değil cihaza bağlı; cihaz el değiştirse de geçmişi onunla kalıyor.

Ne inşa ediyoruz

CRM
  • Adım adım ilerleyen hizmet planı

    Çok seanslı bir tedavi ya da bakım programı, randevulardan ayrı bir plan olarak tutulur. Diş kliniği CRM'inde plan diş bazında kuruluyor ve haftalara yayılan seanslara bölünüyor.

  • Plana bağlı randevular

    Her randevu planın bir adımına bağlanır. Plan değiştiğinde ya da araya yeni bir seans girdiğinde takvim de buna göre güncellenir.

  • Paket ve üyelik hakları

    Paketle satılan derslerde ya da hizmetlerde kalan hak müşterinin kartında görünür. Pilatesco'da rezervasyon yapıldığında paketten bir ders düşüyor; iptal ile gelmeme farklı kurallarla işliyor.

  • Cihaz bazında servis geçmişi

    Servis verdiğiniz cihazların garanti, bakım ve arıza geçmişi kişiye değil cihaza bağlı tutulur. AlgoKlima'da aynı adresteki üç klimanın dosyası birbirine karışmıyor.

  • Sahibi değişse de korunan geçmiş

    Cihaz başka birine geçtiğinde geçmişi cihazla birlikte kalır; yeni müşterinin kartına baştan yazılmaz.

  • Yapılan iş ile fatura aynı yerde

    Yapılan işlem müşterinin kaydında durduğu için faturalanan ile uygulanan aynı yerden okunur ve bilgiler iki kez girilmez.

Buna benzer çalışmalar

CRM · Vaka çalışması

Bir diş kliniğinin CRM'i — plan diş bazında, randevu ait olduğu seansa bağlı

Klinik çok seanslı tedaviyi genel amaçlı bir randevu yazılımıyla yürütüyordu: yazılım saati tutuyor, planı tutmuyordu. Hastanın tedavinin neresinde olduğu tahmine, faturalanan işlem ayrı bir deftere, ay sonu tablosu ikisinin elle birleştirilmesine kalıyordu. Kurduğumuz düzende sıra tek yerde: tedavi planı diş bazında kuruluyor ve sıralı seanslara bölünüyor, her randevu planın hangi seansına karşılık geldiğini gösteriyor, fatura ile rapor hasta kaydından türüyor. Yazılım Laravel üstünde çalışıyor, kayıtlar MySQL'de; klinik için ayrı bir yığın seçilmedi.

Vaka çalışmasını okuyun →

Kadıköy ekipleriyle uzaktan çalışmak

Ofisimiz yok; bu şehirdeki işleri de uzaktan yürütüyoruz ve yerinde destek vermiyoruz. Ne yapıldığı ve neden öyle yapıldığı yazılı duruyor. Ortaklıkla geliştirdiğimiz işler proje sayfalarında işaretli.

  • İlk sürüm çalışan bir parçayla çıkar, ek yetenekler sonra eklenir.
  • Bildiğimiz müşterilerimizin tamamı Türkiye'de.
  • Kararlar yazılı duruyor, ilerleme çalışan ekranlardan görünüyor.

Sık sorulan sorular

  • Kadıköy'de ofisiniz ya da yerinde destek veren bir ekibiniz var mı?

    Fiziksel ofisimiz yok, tamamen uzaktan çalışıyoruz. İlk iş kod değil metin: plandan randevuya, randevudan faturaya giden zinciri birlikte yazıya geçiriyoruz. Geliştirme bundan sonra başlıyor.

  • Hazır bir randevu yazılımı bize yetmez mi?

    Randevu defteri ile kişi listesi işinizi çeviriyorsa yeter; bunu satış kaygısı olmadan söyleriz. Sınır, randevunun çok seanslı planın hangi adımına ait olduğunu bilmesi gerektiği yerde başlıyor.

  • Tedavi planı ortasında değişirse takvimdeki randevular ne oluyor?

    Randevu plandaki seansa bağlı olduğu için değişiklik takvime kendiliğinden yansıyor. Araya seans girdiğinde sonrakiler kayıyor; karşılığı kalmamış bir randevu geride durmuyor.

  • Bu düzen yalnız diş kliniklerine mi uygun?

    Mekanizma diş hekimliğine değil, çok adımlı plana bağlı. Sıra planın üstünde durdukça takvim aynı yerden besleniyor. Sektöre göre değişen randevu akışları için AlgoRandevu'yu şu an inşa ediyoruz; bitmiş bir ürün değil.

Müşteri takibinizi tek sisteme toplamak ister misiniz?