Teklif al

CRM · Ankara

Ankara markaları için CRM

Çukurambar ve Eskişehir yolu hattındaki merkez ofislerde ilk temas santralden geçiyorsa, gelen istek bir kişinin notunda başlıyor. Arayan anlatıyor, karşı taraf bir not alıyor, notun hangi birime gideceğine akşam biri karar veriyor. Ankara CRM yazılımı için ilk soru bu: ayıklama işini kim yapıyor. Diotek'te ayıklama diye bir adım yok. Talep hangi akıştan girdiyse operasyona o akışla ulaşıyor, sıra da bu yüzden karışmıyor. Mesai dışında yazılan talep bile kendi akışında yazılı kalıyor.

CRM — Ankara

Bu şehirde ağırlık yönetim katmanında: bir genel müdürlük, altında birkaç birim, hepsinin ortak kapısı tek bir kurumsal site. Kapı ortak olunca gelen her şey de aynı yere düşüyor ve ayrımı yapan kişi zincirin en yorgun halkası oluyor. Bu çalışma biçimine en yakın işimiz Diotek. Örtüşmediği yeri açık yazalım: Diotek klima ve havalandırma işi için yazıldı; çok birimli bir kurumun onay basamakları ve iç talep yönlendirme kuralları için gösterecek işimiz yok. Taşınan şey sektör değil, sınıflandırmanın hangi anda yapıldığı. Altta Laravel işi yürütüyor, kayıtlar MySQL'de, önbellek Redis'te; arayüzü Inertia ile Tailwind taşıyor.

  • Keşif randevusu ile servis talebi iki ayrı akış olarak açılıyor; aynı listeye düşmedikleri için sırayı kimse elle ayıklamıyor.
  • Talep girişi telefon hattına bağlı değil; mesai bitince gelen istek de kendi akışında yazılı kayda düşüyor, ertesi sabah hatırlanmayı beklemiyor.
  • Talep kaydı ile tanıtım içeriği aynı MySQL şemasında duruyor; sayfa güncellemesi ile talep akışı iki ayrı sistemin bakımına bölünmüyor.

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ı

Diotek — talep giriş anında ayrılıyor, operasyon ayıklama yapmıyor

Klima ve havalandırma işinde siteye iki farklı talep geliyor: satış öncesi keşif randevusu ve montaj sonrası servis. İkisini baştan ayrı akış olarak kurduk. Ziyaretçi cihaz seçmeden önce mekân için bir tarih isteyebiliyor ve bu istek servis kuyruğuna karışmadan kendi akışında operasyona düşüyor. Montaj sonrası bakım ve arıza talebi ise kurulu cihazı merkeze alarak siteden açılıyor; kayıt yazılı kalıyor, telefon notuna bağlı olmuyor. Tanıtım sayfaları ve talep ekranları tek Laravel uygulamasında duruyor: Inertia sayfa geçişini istemcide yapıyor, yönlendirme ve doğrulama Laravel'de kalıyor, sezon başı yükünü Redis karşılıyor.

Vaka çalışmasını okuyun →

Ankara 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

  • Merkezimiz Ankara'da; sizinle nasıl çalışacağız?

    Fiziksel ofisimiz yok, tamamen uzaktan çalışıyoruz. İlk çıktı kod değil metin: siteye kaç farklı talep tipinin geldiğini ve her birinin hangi birimde karşılık bulduğunu birlikte yazıya geçiriyoruz. Geliştirme o listeden sonra başlıyor.

  • Talepleri zaten tek iletişim formundan alıyoruz. Sorun nerede?

    Tek formda sorun formun kendisi değil, ayrımın nereye ertelendiği. Form her şeyi aynı kutuya bıraktığında sınıflandırmayı bir kişi elle yapıyor ve o kişi izne çıktığında sıra duruyor. Ayrım giriş anında yapıldığında böyle bir bağımlılık doğmuyor.

  • Hazır bir CRM bu ayrımı yapamaz mı?

    Etiket ekleyerek yapar, bunu açıkça söyleriz. Fark şurada: etiket kayıt oluştuktan sonra takılan bir sıfat, akış ise kaydın hangi kurallarla açıldığı. Talep tipi hangi alanların zorunlu olduğunu da belirliyorsa etiket yetmiyor.

  • Diotek klima işi, bizimki değil. Bu bize ne söylüyor?

    Sektörü olduğu gibi söylüyoruz; taşınan şey klima değil kaydın kurulma biçimi. Bir tarafta randevu isteyen, öbür tarafta kurulu bir cihaz için çağrı açan var. Bu ikisi hangi kurumda olursa olsun aynı kuyruğu paylaşamıyor.

Müşteri takibinizi tek sisteme toplamak ister misiniz?