
SocialRadar360 — zincir marka itibar takip sistemi
Çok şubeli markaların müşteri yorumlarını şube şube okuyup operasyon müdürünün yarın harekete geçebileceği bulgulara çeviren sistem. Kaç şikayet geldiğini değil, sebebini ve bunun o şubenin mi yoksa markanın tamamının mı sorunu olduğunu söyler.
Zincir marka itibar takip sistemi
- 01İşi alarm üretmek değil, alarm bastırmak
- 02Tek olay, tek bildirim
- 03Şube sorunu mu, marka sorunu mu
- 04Kriz patladıktan sonra değil, ivmelenirken
- 05Ucuz model eler, pahalı model düşünür
- 06Türkçenin kendi tuzakları
Merkez şubesinimüşterinin gözünden görmüyor.
Otuz şubeli bir zincirde merkez, şubelerini müşterinin gördüğü yerden görmez. Google puanı yılların ortalamasıdır ve bir şubenin son üç haftada çöktüğünü gizler. Şikayet ise şube müdürünün merkeze ilettiği kadardır — kimse kendini şikayet etmez.
Yorumları okumak da çözüm değil. Otuz şube, ayda yüzlerce yorum: kimsenin oturup okuyacağı bir hacim değil. Okunsa bile ortaya çıkan şey bir duygu grafiğidir ve “bu ay olumsuz yorumlar %12 arttı” cümlesi bir yöneticiye ne yapacağını söylemez.
Asıl mesele ayrımdır. Bir şubede servis yavaşlıyorsa o şubenin vardiya sorunudur; otuz şubenin yirmisinde fiyat şikayeti varsa şube müdürünü sıkıştırmak işe yaramaz, sorun fiyatlamadadır. SocialRadar360 bu ayrımı yapmak, sebebi yazmak ve krizi patlamadan önce haber vermek için kuruldu.
Herkes yalnızca kendi işini görür
Marka sahibi
Birkaç günde bir kısa özet alır; kritik alarm bu takvimi beklemez. Kaç bildirim alacağını, hangi seviyeden itibaren uyarılacağını ve hangi saatlerde rahatsız edilmeyeceğini kendisi belirler.
Operasyon müdürü
Şube karnesini, her şubenin bulgularını, kök sebep hipotezini ve önerilen aksiyonu görür. Marka geneli sorunlar ayrı başlıkta durur — şube müdürüne yüklenmesin diye.
Ajans / hesap yöneticisi
Tek hesap altında birden çok markayı yönetir. Markalar birbirinin verisini görmez; hangi kullanıcının hangi satıra erişeceği arayüzde değil, veritabanı politikasında tanımlıdır.
Portal kullanıcısı
Veriyi okur, değiştiremez. Yazma yetkisi toplama ve analiz işçilerindedir; kullanıcıdan gelen tek yazma işlemi bir alarmı görüldü olarak kapatmaktır.
Bildirim yorgunluğuna göreverilmiş kararlar
- 01
İşi alarm üretmek değil, alarm bastırmak
Bir yöneticiye giden üç gereksiz bildirim kanalın sessize alınmasıyla biter; kimse iptal etmez, sadece okumayı bırakır. Motor bu yüzden üç kapı koyuyor: aynı sorun için açık alarm varken ikincisi açılmaz, güveni %70'in altındaki bulgu alarma değil haftalık rapora düşer, haftalık bütçe (en fazla 2 kritik, 5 uyarı) dolduğunda kalanlar ertelenir. Bütçe önce en yüksek güvenli bulguya harcanır.
- 02
Tek olay, tek bildirim
Bir hijyen olayı aynı gün hem puanı düşürür, hem olumsuz yorumu artırır, hem hacmi yükseltir. Bunları ayrı ayrı göndermek tek olay için dört bildirim demektir — bildirim yorgunluğunun tam olarak doğduğu yer. Korele sinyaller tek alarma iniyor: en güçlü sinyal başlık oluyor, kalanlar altına kanıt olarak taşınıyor ve birbirlerini doğruladıkları için güven puanını yükseltiyorlar.
- 03
Şube sorunu mu, marka sorunu mu
Raporun en değerli kısmı bu ayrım ve tek şubeye bakarak yapılamaz. Bir konu şubelerin yarısından fazlasında çıkıyorsa marka geneli sayılıyor ve şube alarmı doğurmuyor; dörtte bir ile yarı arasındaysa küme olarak işaretleniyor — bölgesel bir sebebi olabilir. Şirket şubeleri ile franchise şubelerin ortalaması ayrı tutuluyor, aradaki fark franchise standardizasyonunun göstergesi.
- 04
Kriz patladıktan sonra değil, ivmelenirken
Mutlak eşik otuz şubeli bir zincirde işe yaramaz; her şubenin normali farklıdır. Her şube kendi son 28 gününe göre ölçülüyor ve 2,5 standart sapmayı geçen hareket anomali sayılıyor. Bu katman model çağırmıyor, saniyeler sürüyor — pahalı analiz yalnızca burada tetiklenen şubeler için çalışıyor. Olumsuz yorumun hızı ve ivmesi ayrıca hesaplanıyor: yönetici “kriz var” değil, “ne kadar hızlı büyüyor” bilgisiyle karar veriyor. Hijyen, yabancı madde ve gıda güvenliği bu hesabın dışında: tek yorum bile en yüksek ciddiyeti alıyor, geçmişi beklenmiyor.
- 05
Ucuz model eler, pahalı model düşünür
Yorumların önemli bölümü spam, mükerrer ya da sinyal taşımayan kısa metindir; hepsini modele göndermek hem pahalıdır hem de analizi bozar, model gürültüde boğulur. Önce desenle spam ve kısa metin eleniyor, sonra SimHash ile aynı metnin varyasyonları tek temsilciye iniyor — silinmiyor, sayaç olarak taşınıyor, çünkü tekrarın kendisi sinyaldir. Kalanı ucuz model partiler hâlinde ayıklıyor; kök neden analizi yalnızca eşiği geçen şubeler için pahalı modele gidiyor ve markanın bağlam metni her çağrıda önbellekten okunuyor.
- 06
Türkçenin kendi tuzakları
“Harika hizmet, tebrikler” olumsuz olabilir; ironi bu pazarda yaygın ve kelimeye değil bağlama bakmak gerekiyor. Yıldız ile metin çeliştiğinde metin esas alınıyor: beş yıldızlı bir yorum ciddi bir operasyon uyarısı taşıyabilir, bir yıldızlı bir yorum sadece fiyat şikayeti olabilir. Argo ciddiyeti azaltmıyor. Konu etiketleri de sabit bir listeden seçiliyor, model kendi etiketini uyduramıyor — “servis yavaş” ile “bekleme süresi” ayrı iki başlık olursa şubeler arası karşılaştırma imkânsız hale gelir.
- 07
Her bulgunun altında müşterinin cümlesi var
“31 şikayet var” bir bulgu değil; “servis hızı şikayetleri üç haftadır artıyor, muhtemel sebep vardiya yapısı” bir bulgu. Her bulgu kök sebep hipotezi, yarın uygulanabilir bir aksiyon ve yorumdan birebir alıntılarla geliyor. Rapor sadece kötü haber de taşımıyor: ismen övülen personel ve ortalamanın belirgin üstündeki örnek şubeler ayrıca yazılıyor — iyi pratiğin yayılması için merkezin bunları bilmesi gerekiyor.
- 08
Yanıt taslağı yazılır, asla otomatik yayınlanmaz
Kriz anında markanın kendi ses tonuyla bir yanıt taslağı üretiliyor. Taslakla birlikte hangi varsayımlara dayandığı ve yayından önce doğrulanması gereken noktalar da listeleniyor. Taslak insan onayı olmadan hiçbir yere gitmiyor — yanlış bir özür, sessizlikten daha pahalıya mal olur.
- 09
Rapor yöneticinin okuduğu yere gider
Yönetici portala girmez. WhatsApp'ta işletmenin başlattığı mesaj onaylı şablon olmak zorunda ve serbest metin gönderilemiyor; bu yüzden şablona kısa uyarı ile detay bağlantısı sığdırılıyor, yönetici cevap yazdığında açılan 24 saatlik pencerede konuşma serbestçe sürüyor. Slack ve e-posta serbest metin. Gönderilen her mesajın okundu bilgisi kayda düşüyor — ürünün tek gerçek başarı metriği yöneticinin bunu okuyup okumadığı.
- 10
Toplama sustuğunda haber verilir
En kötü senaryo kriz olması değil; kriz varken toplamanın altı saattir kırık olması ve kimsenin fark etmemesidir. Her kaynağın son başarılı toplama zamanı tutuluyor ve bir kaynak 12 saattir sessizse operasyona alarm gidiyor. Toplama sonucu ayrıca doğrulanıyor: boş dönen bir çalıştırma başarı sayılmıyor, çünkü sessiz başarısızlık en tehlikeli hatadır.
Çalıştığı yerler
- Web portal
- Slack
- E-posta
Teknoloji
- Next.js
- React
- TypeScript
- PostgreSQL + RLS
- Supabase
- Claude (Haiku + Opus)
- Playwright
Pilot markaarıyoruz.
Analiz hattı, alarm motoru ve zincir raporu yazıldı; sırada bunu gerçek bir markada, gerçek yorumlarla çalıştırmak var. Kaç şubeniz olduğunu ve müşteri yorumlarını şu an kimin takip ettiğini anlatın — pilotu birlikte kuralım, çıkan ilk raporu birlikte okuyalım.