# WEGS Müşteri Operasyonları Yönetim Paneli ## Sistem Dokümantasyonu · v2 > **Bu doküman kime yazıldı?** Projeyi hiç bilmeyen bir insana veya bir yapay zeka modeline. Hiçbir ön bilgi varsayılmaz; kavramlar ilk geçtikleri yerde tanımlanır. Amaç, okuyanın sistemi analiz edebilecek, boşluk bulabilecek ve öneri getirebilecek kadar anlamasıdır. > > **Sürüm notu:** v1'den farkı, veri modelinin üç katmanlı yeni yapıya geçmesi (Müşteri → Firma → Workspace), kimlik/faturalama kurgusunun eklenmesi ve menünün 22 maddeye çıkmasıdır. Değişen kararlar §12'de gerekçeleriyle işaretlidir. > > **Doküman tarihi:** 07.08.2026 --- ## İçindekiler 1. [Proje bir bakışta](#1-proje-bir-bakışta) 2. [İş bağlamı: WEGS ne yapıyor?](#2-iş-bağlamı-wegs-ne-yapıyor) 3. [Kavram sözlüğü](#3-kavram-sözlüğü) 4. [Veri modeli ve hiyerarşi](#4-veri-modeli-ve-hiyerarşi) 5. [Kimlik ve faturalama modeli](#5-kimlik-ve-faturalama-modeli) 6. [Kanal modeli: Bayi, Alt Bayi, SMMM](#6-kanal-modeli-bayi-alt-bayi-smmm) 7. [Menü haritası](#7-menü-haritası) 8. [Ana iş akışları](#8-ana-iş-akışları) 9. [Durum kümeleri ve geçiş kuralları](#9-durum-kümeleri-ve-geçiş-kuralları) 10. [Skorlar ve KPI sistemi](#10-skorlar-ve-kpi-sistemi) 11. [Roller ve yetki matrisi](#11-roller-ve-yetki-matrisi) 12. [Karar kütüğü](#12-karar-kütüğü) 13. [Değişmez tasarım kuralları](#13-değişmez-tasarım-kuralları) 14. [Tasarım sistemi](#14-tasarım-sistemi) 15. [Component envanteri](#15-component-envanteri) 16. [Çalışma disiplini](#16-çalışma-disiplini) 17. [Mevcut durum](#17-mevcut-durum) 18. [Açık konular](#18-açık-konular) 19. [Analiz eden yapay zekaya brief](#19-analiz-eden-yapay-zekaya-brief) --- ## 1. Proje bir bakışta | | | |---|---| | **Ürün** | WEGS Müşteri Operasyonları Yönetim Paneli | | **Türü** | Dahili operasyon merkezi (CRM + ERP + operasyon yönetimi karışımı) | | **Kim kullanacak?** | Yalnızca WEGS çalışanları: satış, müşteri başarı, destek, finans, teknik, yönetim + yetkili kanal ortakları (bayi/SMMM, kısıtlı görünürlükle) | | **Kim kullanmayacak?** | Son müşteriler. Panel müşteriye asla açılmaz. | | **Şu anki aşama** | Tasarım (mockup). Çalışan uygulama, backend veya gerçek veri bağlantısı **yok**. | | **Sonraki aşama** | Onaylanan mockup'lardan hareketle, yapay zeka destekli geliştirme | | **Çıktı formatı** | Tarayıcıda açılan, tek dosyalık, bağımsız, tam responsive HTML mockup'lar | | **Dil** | Tüm arayüz ve tüm tartışma Türkçe. Sektör terimleri çevrilmez. | ### Çözülmek istenen problem Müşteri bilgisi bugün parçalı duruyor: satış görüşmelerinde, WhatsApp mesajlarında, destek kayıtlarında, lisans ekranlarında, finans takiplerinde ve teknik loglarda. Bu dağınıklık üç sonucu doğuruyor: - Hiçbir ekip müşteriyi bütün olarak göremiyor - Aynı müşteriye farklı ekipler farklı şey söylüyor - Riskler (churn, gecikmiş tahsilat, kopmuş entegrasyon) geç fark ediliyor ### Panelin vaadi Kayıt olan kullanıcıdan ödeme yapan müşteriye, lisans yenilemeden destek yönetimine kadar tüm yolculuğun **tek panelde** yönetilmesi. Panelin kalbi "360° kartı"dır: bir kaydın satış, finans, destek, teknik ve iletişim geçmişinin aynı ekranda toplanması. ### Satışa açık bir CRM'den farkı Bu bir CRM ürünü değil. Ürünün kendi altyapısına (workspace, lisans, kontör, entegrasyon, kullanım logu) doğrudan bağlı bir **iç operasyon paneli**. Genel amaçlı CRM'lerin bilmediği şeyleri bilir: hangi workspace'in entegrasyonu kaç saattir kopuk, hangi seat havuzu dolmuş, hangi lisans kaç gün sonra bitiyor. --- ## 2. İş bağlamı: WEGS ne yapıyor? WEGS, Türkiye pazarına **ön muhasebe + e-ticaret entegrasyonları** satan bir SaaS şirketidir. Ürün ailesi: WEGS Go, WEGS Commerce, WEGS Collect, WEGS CRM, WEGS Banking, WEGS B2B ve diğerleri. Müşteriler tipik olarak KOBİ ölçeğinde firmalardır: pazaryerlerinde satış yapan e-ticaret işletmeleri, kendi mağazası olan perakendeciler, franchise zincirleri, grup şirketleri ve mali müşavir yönlendirmesiyle gelen küçük firmalar. Bu bağlam üç şeyi zorunlu kılar: 1. **Muhasebe gerçekliği** — Bir firmanın vergi kimliği (VKN) tekil olmalı, faturası hukuka uygun kesilmeli, defter yapısı doğru kurgulanmalı. 2. **Teknik gerçeklik** — Pazaryeri, banka, e-Dönüşüm, kargo ve ERP entegrasyonları kopabilir; kopma müşteri memnuniyetini anında etkiler. 3. **Kanal gerçekliği** — Müşterilerin önemli bir kısmı doğrudan değil, bayi veya mali müşavir (SMMM) yönlendirmesiyle gelir. --- ## 3. Kavram sözlüğü Bu bölüm dokümanın geri kalanının anahtarıdır. Terimler **sabitlenmiştir**: aynı kavram her ekranda aynı kelimeyle karşılanır. ### 3.1 Temel nesneler | Terim | Anlamı | |---|---| | **Müşteri** | Ticari ilişkinin sahibi. Sözleşme, faturalama tercihi ve konsolide gelir bu seviyede durur. Tek bir firmadan da oluşabilir, birden fazla firmayı da kapsayabilir. | | **Firma** | Tüzel kişilik. Kendi vergi kimliği (VKN), unvanı, yetkilileri ve adresleri olan kayıt. Sistemin en çok kullanılan katmanı budur. | | **Workspace** | Firmanın ürün alanı. Kullanıcıların içine girip çalıştığı, lisansların ve seat'lerin bağlandığı, entegrasyonların kurulduğu operasyon alanı. Aynı zamanda faturalamanın dayandığı birim. | | **Ürün / Lisans** | Bir workspace üzerinde aktif olan ürün hakkı: hangi ürün, hangi paket, kaç seat, hangi tarih aralığı, aylık ne kadar. | | **Lead** | Henüz müşteri olmamış potansiyel kayıt. Web, referans, fuar, banka, inbound veya outbound kaynaklı. | | **Fırsat** | Nitelikli hale gelmiş lead'in satış pipeline'ındaki hali. Aşamalar arasında ilerler. | | **Teklif** | Ürün, paket, seat, kontör ve özel kalemlerden oluşan, müşteriye gönderilen fiyat önerisi. | ### 3.2 Ticari ve operasyonel terimler | Terim | Anlamı | |---|---| | **VKN** | Vergi Kimlik Numarası. 10 hane. Tüzel kişilikler için. | | **TCKN** | T.C. Kimlik Numarası. 11 hane. Şahıs firmaları / vergi kimliği henüz alınmamış durumlar için. | | **Kayıt anahtarı** | Sistemin firmayı tanıdığı tekil kimlik. **Asla değişmez.** | | **Fatura kimliği** | Faturaya yazılan vergi kimliği. Değişebilir; her değişim loglanır. | | **Geçici anahtar** | Vergi kimliği henüz yokken sistemin otomatik ürettiği tekil anahtar. Format: `GEC-2026-000431`. Harf öneki taşıdığı için VKN/TCKN ile karışmaz. | | **MRR** | Monthly Recurring Revenue — aylık tekrar eden gelir. Aktif ürün satırlarının aylık tutarları toplamı. | | **Seat** | Bir workspace'te tanımlı kullanıcı hakkı sayısı. | | **Kontör** | Kullanım bazlı satın alınan bakiye (ör. e-fatura kontörü). | | **Churn** | Müşteri kaybı. | | **SLA** | Service Level Agreement — destek taleplerinde taahhüt edilen yanıt/çözüm süresi. | | **Onboarding** | Yeni müşterinin kurulum ve ilk kullanım süreci. | | **Audit Log** | Kim, ne zaman, neyi değiştirdi kaydı. Değiştirilemez (immutable). | | **SMMM** | Serbest Muhasebeci Mali Müşavir. Müşteri yönlendiren mali müşavir veya muhasebe ofisi. | | **Owner** | Workspace'i kullanan son kullanıcı; ürün içindeki rol adıdır, çevrilmez. | | **Sorumlu** | WEGS tarafında kayıttan sorumlu çalışan (Müşteri Sorumlusu, Teklif Sorumlusu, Lead Sorumlusu). | ### 3.3 Çevrilmeyen sektör terimleri Şunlar İngilizce kalır, Türkçeleştirilmez: `Workspace` · `Lead` · `Pipeline` · `Churn` · `MRR` · `SLA` · `Onboarding` · `Audit Log` · `Owner` · `Trial` · `Seat` Bunların dışındaki her arayüz metni Türkçedir. Çekim ekleri kesme işaretiyle yazılır: *Workspace'ler, Lead'in, MRR'a*. ### 3.4 Kullanılmayan kelimeler Bu kelimeler arayüzde **hiç geçmez**, çünkü karşılıkları sabitlenmiştir: | Kullanılmaz | Yerine | |---|---| | Sahip, Müşteri Sahibi, Account Owner | **Sorumlu** | | Pasif (müşteri için) | **Eski Müşteri** | | İskonto, ıskonto | **İndirim** | | Defter, tek defterli, ayrık defterli | **Workspace** ve türetilmiş yapı rozetleri | | Şube (ayrı nesne olarak) | **Adres kaydı** veya ayrı **Firma** | | Toplamı elle gir | **Manuel tutar gir** | > **Kural:** Terim değişikliği yalnızca *görünen metni* etkiler. Alan adları, CSS sınıfları ve `data-*` öznitelikleri değişmez (`.owner`, `.disc-input`, `is-discount` sabit kalır). Böylece modüller arası kopyalama ve gelecekteki API eşlemesi kırılmaz. --- ## 4. Veri modeli ve hiyerarşi ### 4.1 Dört katman ``` MÜŞTERİ ← ticari ilişki: sözleşme, faturalama tercihi, konsolide MRR └── FİRMA ← tüzel kişilik: unvan, VKN/TCKN, yetkililer, adresler └── WORKSPACE ← ürün alanı: lisans, seat, kontör, entegrasyon, owner └── ÜRÜN/LİSANS ← ürün, paket, seat, tarih aralığı, aylık ücret ``` Her katman bir üstteki katmana bağlıdır ve **kendi altındaki katmanı çoğaltabilir**: bir müşterinin birden fazla firması, bir firmanın birden fazla workspace'i, bir workspace'in birden fazla ürün lisansı olabilir. ### 4.2 Katman katman: ne taşır? **MÜŞTERİ** — ticari ilişkiyi temsil eder, tüzel kişiliği değil. | Alan | Not | |---|---| | Müşteri adı | Grup adı veya tek firmanın unvanı | | Müşteri tipi | Tekil · Grup Şirketi · Franchise Ağı | | Faturalama tercihi | Merkezi · Firma bazında | | Ortak sözleşme ve indirim | Gruba uygulanan ticari koşullar | | Konsolide MRR | Altındaki tüm firmaların MRR toplamı (türetilir) | > Tekil firmalarda müşteri kaydı **otomatik oluşur**; kullanıcı ayrıca doldurmaz. **FİRMA** — tüzel kişilik. | Alan | Not | |---|---| | Unvan | Ticari unvan | | Kayıt anahtarı | VKN / TCKN / geçici anahtar — değişmez | | Fatura kimliği | Faturaya yazılan numara — değişebilir | | Ticaret sicil, sektör, segment, şehir | | | Adresler | Çoklu kayıt (merkez, şube, depo, fatura adresi) | | Yetkili kişiler | Çoklu kayıt, rollü | | Sağlık skoru | Türetilir | | Firma sorumlusu | WEGS tarafındaki sorumlu çalışan | | Kaynak | Doğrudan / bayi / alt bayi / SMMM | | Bağlı müşteri | Zorunlu; boş bırakılırsa tekil müşteri otomatik oluşur | **WORKSPACE** — ürün alanı. | Alan | Not | |---|---| | Workspace ID ve adı | | | Owner | Ürün içindeki asıl kullanıcı | | Domain | | | Durum | Aktif · Onboarding · Trial · Sona Yakın · Askıya Alınmış | | Ürünler | Go, Commerce, Collect… | | Paket, seat, kontör | | | Son giriş | | | Aktivasyon skoru | Türetilir | | Onboarding durumu | | | Entegrasyon sağlığı | | **ÜRÜN / LİSANS** | Alan | |---| | Ürün · Paket · Seat · Başlangıç–bitiş tarihi · Aylık ücret | ### 4.3 Beş gerçek dünya senaryosu Model şu beş yapıyı karşılamak zorundadır. Her senaryonun modele nasıl oturduğu: | # | Gerçek dünya | Modeldeki karşılığı | |---|---|---| | 1 | **Grup şirketi** — bir holding altında farklı VKN'li şirketler | 1 Müşteri (tip: Grup Şirketi) → N Firma (her biri kendi VKN'si ile) | | 2 | **Tek defterli şubeler** — aynı VKN, tek muhasebe | 1 Müşteri → 1 Firma → 1 Workspace; şubeler adres listesinde | | 3 | **Ayrık defterli şubeler** — aynı VKN, şube başına ayrı muhasebe | 1 Müşteri → 1 Firma → N Workspace | | 4 | **Franchise sistemi** — farklı VKN'li bayilik noktaları | 1 Müşteri (tip: Franchise Ağı) → N Firma | | 5 | **Tekil firma** | 1 Müşteri (otomatik) → 1 Firma → 1 Workspace | ### 4.4 "Şube" neden ayrı bir nesne değil? Erken tasarımda ayrı bir *Şube* nesnesi düşünüldü ve **bilinçli olarak reddedildi.** Gerekçe: - "Şube" kelimesi Türkiye pratiğinde üç farklı şeyi anlatıyor: aynı VKN'li fiziksel nokta, aynı VKN'li ayrı defter, farklı VKN'li franchise noktası. - Bu üçü aynı nesneye sıkıştırılırsa hiçbiri doğru modellenmiyor. - Üçü zaten mevcut katmanlarla karşılanıyor: **fiziksel nokta = adres kaydı**, **ayrı defter = ayrı workspace**, **farklı VKN = ayrı firma**. Sonuç: veri modeli düz kaldı, kullanıcı üç ayrı kavramı ezberlemek zorunda kalmadı. ### 4.5 Yapı rozetleri (türetilmiş) Bir firmanın yapısı elle seçilmez, **veriden hesaplanır**: | Rozet | Türetme kuralı | |---|---| | `Tekil` | 1 firma, 1 workspace | | `Çok workspace'li` | 1 firma, birden fazla workspace | | `Grup üyesi` | Müşteri tipi = Grup Şirketi | | `Franchise noktası` | Müşteri tipi = Franchise Ağı | > **Not:** Eski "tek defterli / ayrık defterli" ifadeleri tamamen düşürüldü — muhasebe jargonu operasyon ekibine gereksiz yük bindiriyordu. --- ## 5. Kimlik ve faturalama modeli Bu bölüm sistemin en ince kurgusudur ve yasal risk taşır. Sorun şudur: **müşteri para ödemeye hazır ama VKN'sini vermemiş.** Satışı durdurmak ticari kayıp, faturasız bırakmak yasal risk. ### 5.1 İki ayrı alan Karışıklığın çıkacağı yer burasıdır, o yüzden baştan ayrılır: | Alan | Ne işe yarar | Değişir mi? | |---|---|---| | **Kayıt anahtarı** | Sistemin firmayı tanıdığı tekil kimlik | **Asla değişmez** | | **Fatura kimliği** | Faturaya yazılan vergi kimliği | Değişir, her değişim loglanır | Kayıt anahtarı üç şekilde oluşur: 1. Girilen **VKN** (10 hane) 2. Girilen **TCKN** (11 hane) 3. Vergi kimliği yoksa sistemin otomatik ürettiği **geçici anahtar** (`GEC-2026-000431`) > **Neden anahtar değişmiyor?** Workspace, destek, eğitim ve aktivasyon geçmişi bu anahtara bağlıdır. Anahtarı değiştirmek müşteri hafızasını ikiye bölmek olur. Geçici anahtarla açılan kayıt sonradan VKN alsa bile anahtarı sabit kalır; VKN **fatura kimliği** alanına yazılır. ### 5.2 Fatura kimliği kademesi Satış departmanı sırayla dener: 1. **VKN varsa** → VKN yazılır, konu kapanır 2. **VKN yok, TCKN alınabiliyorsa** → TCKN yazılır, e-Arşiv şahıs adına kesilebilir 3. **İkisi de yoksa** → `11111111111` yazılır, e-Arşiv yine kesilir Üçüncü seçenek kaydın üstünde ayrı bir rozet taşır — çünkü bu bir çözüm değil, **kabul edilmiş bir eksiktir** ve finansın görebilmesi gerekir. ### 5.3 Yedi günlük sayaç ``` Gün 0 Ödeme doğrulandı → LİSANS HEMEN AKTİF "VKN topla" görevi sorumluya düşer, sayaç başlar Gün 1-6 Müşteriye hatırlatma, sorumluya günlük uyarı VKN gelirse → fatura VKN ile kesilir, sayaç kapanır Gün 7 Sayaç dolar → e-Arşiv otomatik ŞAHIS ADINA kesilir Kimlik: TCKN varsa TCKN, yoksa 11111111111 Unvan: gerçek kişinin ad-soyadı ``` Sayaç **türetilmiş veridir**: `ödeme doğrulama tarihi + 7 gün − bugün`. Elle girilmez, elle sıfırlanmaz. Müşteri VKN'sini sonradan ilettiğinde güncelleme yapılır; **bundan sonraki faturalar** yeni bilgiye göre kesilir. Geçmiş fatura için "iptal → yeniden kes" akışı ayrı bir modal olarak çalışır. ### 5.4 Bu kurgunun mantığı Kilit **satıştan alınıp fatura anına taşınmıştır.** Bunun üç sonucu var: - Para bekletilmiyor, lisans anında aktif oluyor → ticari kayıp yok - Fatura mutlaka kesiliyor → yasal risk kapalı - Eksiklik görünür kalıyor → finans neyin eksik olduğunu biliyor --- ## 6. Kanal modeli: Bayi, Alt Bayi, SMMM ### 6.1 Hiyerarşi | Seviye | Tanım | Görebileceği veri | |---|---|---| | **WEGS Merkezi** | Sistemin sahibi ve üst yönetim katmanı | Tüm müşteri, firma, bayi, alt bayi, SMMM ve kaynak verileri | | **Bayi** | WEGS adına müşteri yönlendiren veya kanal oluşturan iş ortağı | Kendi girdiği + kendine bağlı alt bayi ve SMMM'lerin getirdiği kayıtlar | | **Alt Bayi** | Bir bayiye bağlı alt iş ortağı | Yalnızca kendi girdiği veya kendisine atanmış kayıtlar | | **SMMM** | Müşteri yönlendiren mali müşavir | Yalnızca kendi yönlendirdiği kayıtlar | ### 6.2 Veri izolasyonu kuralları - Bayi başka bir bayinin müşterisini, SMMM'sini veya performansını **göremez** - Alt bayi, bağlı olduğu ana bayinin tüm verilerini **göremez** - SMMM birden fazla bayi üzerinden müşteri yönlendirebilir; **her yönlendirme ayrı kaynak ilişkisi** olarak tutulur - WEGS her müşterinin hangi kaynakla geldiğini açıkça görür ### 6.3 Kaynak, tek alan değil ilişkidir Bir kaydın kaynağı `kaynak = "Bayi X"` gibi tek bir alan olarak tutulamaz. Çünkü aynı SMMM farklı bayiler üzerinden müşteri yönlendirebilir. Bu yüzden: - **SMMM kaydı tekildir** - SMMM'nin bayi ile ilişkisi **ayrı bir bağlantı kaydıdır** - Müşteri yönlendirmesi bu bağlantı üzerinden kaynaklandırılır ### 6.4 WEGS merkezi de bir kanaldır WEGS merkezi sistemde özel bir kaynak olarak tanımlanır. Böylece doğrudan gelen müşteriler, merkeze bağlı SMMM'ler ve WEGS satış ekibinin oluşturduğu leadler aynı kaynak modeliyle yönetilir. ### 6.5 KPI etkisi > **Temel prensip:** Müşteri hangi kanaldan gelirse gelsin satış, eğitim, destek ve iletişim süreci WEGS ekibi tarafından yürütülür. Kaynak bilgisi ayrıca tutulur; KPI'larda tüm müşteriler **ortak satış hunisine** dahil edilir. Kanal komisyon oranı **%25 üzerindeyse Finans onayına düşer.** --- ## 7. Menü haritası Sol sidebar iki grupta 22 madde taşır. İlk dört madde bilinçli olarak veri modelinin omurgasını okutur: **özet → ilişki → tüzel kişilik → ürün alanı.** ``` OPERASYON 1 Dashboard 2 Müşteriler ← 1. katman · ticari ilişki, sözleşme, faturalama 3 Firmalar ← 2. katman · tüzel kişilik, VKN, yetkili, adres 4 Workspace'ler ← 3. katman · ürün alanı, lisans, seat, entegrasyon 5 Leadler 6 Satış Pipeline 7 Bayi & SMMM Kanal Yönetimi 8 Teklifler 9 Lisanslar 10 Paket & Fiyatlandırma 11 Onboarding 12 Müşteri Başarı 13 Destek Talepleri 14 Finans & Tahsilat 15 Faturalar SİSTEM & YÖNETİM 16 Toollar 17 Entegrasyonlar 18 Sistem Sağlığı 19 Raporlar 20 Audit Log 21 Admin Ayarları 22 Eğitim Materyalleri & SSS ``` ### 7.1 Menüye dair kararlar - **Üç katman, üç menü öğesi.** Müşteri katmanını Firmalar modülünün içine segment olarak gömmek denendi; menü hiyerarşiyi yalan söylediği için vazgeçildi. Yeni ekip üyesi menüye bakınca sistemin yapısını okuyabilmeli. - **Liste tekrarı endişesi filtreyle çözüldü.** Tekil firmalarda müşteri kaydı otomatik oluştuğu için "Müşteriler" listesi "Firmalar" listesinin kopyası gibi görünme riski taşıyordu. Çözüm: **Müşteriler listesi varsayılan olarak yalnızca çok firmalı yapıları gösterir** (Grup Şirketi ve Franchise Ağı); tekiller filtreyle açılır. - **Workspace'ler modülü ayrı kalır.** Destek ve teknik ekip günlük olarak firmadan bağımsız sorgular yapıyor: onboarding'de takılmış, trial'ı bitmek üzere olan, entegrasyonu kopmuş, askıya alınmış workspace'ler. Bu ekran kaldırılırsa bir workspace'e ulaşmanın tek yolu önce hangi firmaya ait olduğunu bilmek olur. - **Bayi & SMMM Kanal Yönetimi alt menü değil, ayrı modüldür.** - **"Müşteri Başarı" adı değişmedi** — o modül ticari ilişkiyi değil, müşteri memnuniyeti disiplinini anlatır. - 22 maddede sidebar kısa ekranlarda dikey kayar; grup başlıkları (`OPERASYON` / `SİSTEM & YÖNETİM`) **yapışkan** kalır. > ⚠️ **Uyumsuzluk uyarısı:** Proje talimatlarındaki (system prompt) menü listesi hâlâ eski 20 maddelik yapıyı (2 Müşteriler, 3 Workspace'ler, 5.1 Bayi alt menü) içeriyor. Yukarıdaki 22 maddelik liste günceldir; proje talimatlarının güncellenmesi gerekir. --- ## 8. Ana iş akışları ### 8.1 Lead'den müşteriye dönüşüm ``` 1 Lead oluşur Web, referans, fuar, banka, inbound/outbound 2 Satışçı atanır Kaynak, sektör, ürün ilgisi veya bölgeye göre 3 İhtiyaç analizi Görüşme notu, ürün ihtiyacı, bütçe 4 Fırsat açılır Nitelikli lead pipeline'da fırsata dönüşür 5 Firma / Workspace Satış kazanılınca firma ve workspace oluşur, onboarding başlar ``` ### 8.2 Teklif ve lisans aktivasyonu ``` 1 Teklif hazırlanır Ürün, paket, seat, kontör, entegrasyon, özel kalemler 2 Onay kontrolü İndirim tavanı aşılırsa yönetici onayına düşer 3 Müşteriye gönderilir PDF teklif + ödeme bağlantısı 4 Ödeme alınır Finans kaydı oluşur 5 Lisans aktifleşir Ürün, paket ve seat hakları workspace'te aktif olur ``` > **Kritik kural:** Teklif kabul edildiğinde fiyat yalnızca *not* olarak kalmaz; müşteriye bağlı **kalıcı özel fiyat / özel indirim kuralına** dönüşür. Sonraki ödeme, yenileme ve faturalandırma bu kuralı dikkate alır. ### 8.3 Ödeme → otomatik fatura → otomatik lisans Müşteri kendi ürün panelinden ödeme yaptığında panel tarafında manuel işlem beklenmez: | Olay | Otomatik aksiyon | Oluşan kayıt | |---|---|---| | Ödeme başarılı | Ödeme kaydı oluşur, satış/finans durumu güncellenir | Payment, gelir kaydı, audit log | | Fatura kesilecek ödeme | e-Fatura/e-Arşiv otomatik oluşur | Invoice, PDF, fatura durumu | | Yeni paket satın alındı | Ürün lisansı oluşur, tarih aralığı atanır | Product License | | Lisans yenilendi | Bitiş tarihi uzatılır | Renewal log | | Ek seat alındı | Seat havuzu artar | Seat transaction | | Kontör alındı | Bakiye artar, geçerlilik atanır | Credit transaction | | Ek modül alındı | Modül yetkisi workspace'te aktif olur | Module entitlement | | Ödeme başarısız | Lisans/fatura oluşmaz, uyarı gider | Failed payment log, takip görevi | > **İş kuralı:** Fatura ve lisans aktivasyonu **yalnızca ödeme sağlayıcısından doğrulanmış** başarılı ödeme sonrası yapılır. Başarısız, beklemede veya şüpheli ödemede lisans otomatik aktive edilmez. ### 8.4 VKN bekleyen firma akışı Bkz. §5.3. İki kollu akış: VKN gelirse normal fatura, gelmezse 7. günde e-Arşiv şahıs adına. ### 8.5 Churn risk yönetimi ``` 1 Sinyal yakalanır Pasif kullanım, geciken ödeme, açık kritik ticket, lisans bitişi 2 Risk skoru hesaplanır Kullanım + finans + destek + iletişim sinyalleri birleşir 3 Aksiyon önerilir Kural motoru / AI müşteri başarı ekibine öneri üretir 4 Görev açılır Arama, toplantı, demo, teknik çözüm veya ödeme takibi 5 Sonuç izlenir Risk düşer, sabit kalır veya yönetim eskalasyonuna çıkar ``` ### 8.6 Dashboard: "Aksiyon bekleyen workspace'ler" Türetilmiş veri kuralına uyar; her satırın **sebebi** ve **kaç gündür beklediği** görünür, tıklanınca doğrudan o workspace'e gider. | Tetikleyen durum | Rozet | |---|---| | Onboarding 7+ gündür yarım | warning | | Trial bitişine 5 gün kaldı | warning | | Entegrasyon 24 saattir kopuk | danger | | Lisans bitişine 15 gün kaldı | warning | | Askıya alınmış, 90 gün sayacı işliyor | danger | | VKN bekleyen firmaya bağlı, eşik üstü | danger | Sağ üstte "Tümünü gör" → Workspace'ler modülüne aynı filtre uygulanmış halde açılır. > **Bilinçli olarak çıkarıldı:** "Seat %100 dolu" uyarısı bu karta girmez. Seat dolması bir sorun değil, olağan bir durumdur. --- ## 9. Durum kümeleri ve geçiş kuralları ### 9.1 Firma / Müşteri `Müşteri Adayı` → `Aktif Müşteri` → `Eski Müşteri` - **Askıya alma müşteriyi Eski Müşteri yapmaz** — ilişki devam ediyordur. - Askı 90 günlük veri saklama süresini doldurduğunda geçiş **otomatik** olur. Bu bir kişisel yorum değil, sistem sonucudur. ### 9.2 Workspace `Aktif` · `Onboarding` · `Trial` · `Sona Yakın` · `Askıya Alınmış` - Workspace durumu **firma seviyesinde tekrarlanmaz.** - **Askıdaki workspace geliri MRR'a sayılmaz**; "risk altındaki MRR" olarak ayrı izlenir. ### 9.3 Teklif `Taslak` · `Onay Bekliyor` · `Gönderildi` · `Görüntülendi` · `Kabul` · `Reddedildi` · `Süresi Doldu` · `Revize Edildi` - "Süresi Doldu" ve "Görüntülendi" **türetilmiş durumlardır**; elle işaretlenmez. ### 9.4 İndirim yetkisi — iki ayrı mekanizma Bu ayrım kritiktir ve sık karıştırılır: | Nerede | Mekanizma | Davranış | |---|---|---| | **Ödeme ve fatura kalemleri** | **Sert sınır** | Tavanı aşan değer anında tavana çekilir, onay akışı yoktur. Belge anında kesinleştiği için beklemeye tahammülü yoktur. | | **Teklif kalemleri** | **Onay akışı** | Tavan aşılırsa teklif `Onay Bekliyor` durumuna geçer; onaylanmadan gönderilemez. Teklif bir öneridir, revizyonu ve bekleme durumu vardır. | | **Kanal komisyon oranı** | **Onay akışı** | %25 üzerindeki oran Finans onayına düşer. | **İndirim tavanı sayıları henüz sabitlenmedi.** Rol bazlı öneri: Satış Uzmanı %15 · Satış Müdürü %25 · Satış Direktörü %35 · Admin %40. Tavanlar `Admin Ayarları > İndirim Yetkileri` ekranından rol ve kişi bazında tanımlanır. --- ## 10. Skorlar ve KPI sistemi ### 10.1 İki skor, iki seviye Bu ikisi **asla karıştırılmaz**: **Sağlık Skoru — firmaya aittir** | Bileşen | Ağırlık | |---|---| | Kullanım | %35 | | Destek | %20 | | Finans | %20 | | Yenileme & Onboarding | %15 | | Entegrasyon | %10 | Eşikler: `≥70 iyi` · `40–69 izlenmeli` · `<40 riskli` **Aktivasyon Skoru — workspace'e aittir** | Bileşen | Ağırlık | |---|---| | Kurulum & Onboarding | %30 | | İlk Değer Anı | %25 | | Kullanım Sıklığı | %20 | | İşlem Hacmi | %15 | | Entegrasyon & Seat | %10 | Eşikler: `≥70 aktif` · `40–69 kısmi` · `<40 düşük` > **Kural:** Alt puanların ağırlıklı toplamı **her zaman** ana skoru vermelidir. Ağırlıklar Admin Ayarları'ndan yönetilebilir. Skor hücresine tıklanınca kırılım popover'ı açılır — bileşik skorlar "kara kutu" olamaz. ### 10.2 KPI aileleri Master dokümanda 21 alt başlıkta tanımlı. Ana gruplar: - **Satış hunisi** — kayıttan ödemeye dönüşüm oranları, aşama bazlı düşüş - **Kayıt sonrası hız** — "ilk 5 dakika" operasyonu: mesai içi yeni kayıtlar için otomatik sayaç, görev ve uyarı - **Hoşgeldin araması / satış görüşmesi / eğitim-demo** — temas kalitesi ve no-show oranları - **Aktivasyon** — ilk değer anına ulaşma süresi - **Ekip performansı** — temsilci bazlı dönüşüm, takip disiplini - **Tıkanıklık analizi** — hangi aşamada ne kadar kayıp - **Gelir** — MRR, New MRR, Churn MRR, Expansion MRR - **Ürün / segment / kaynak bazlı kırılımlar** ### 10.3 Yasak gösterge tipi > **Tahmini gösterge kullanılmaz.** Kapanma olasılığı yüzdesi, ağırlıklı tahmin ve benzeri çarpımlar panelde yer almaz. Bunlar bir durumu ölçmez, bir varsayımı sayıya çevirir; kullanıcı hangi varsayımın içeride olduğunu göremez. Yerine somut toplam konur: **açık tutar, bu ay kapanan tutar, bekleyen teklif tutarı.** --- ## 11. Roller ve yetki matrisi | Rol | Görebilir | Yapabilir | Kısıt | |---|---|---|---| | **Super Admin** | Tüm modüller | Okuma, yazma, silme, ayar değiştirme | Kritik işlemlerde double-confirm ve audit zorunlu | | **Yönetim** | Dashboard, raporlar, müşteri, gelir, pipeline | Stratejik raporları görüntüler | Teknik ayarları değiştiremez | | **Satış Yöneticisi** | Lead, pipeline, teklif, müşteri, satış raporları | Fırsat atar, teklif onaylar | Sistem ayarları ve teknik loglara erişemez | | **Satış Temsilcisi** | Kendi lead, fırsat, teklif ve müşterileri | Görüşme, teklif, görev, takip kaydı | Başka temsilcinin fırsatını yönetemez | | **Müşteri Başarı** | Müşteri, onboarding, kullanım, churn, destek özeti | Görev açar, not ekler | Fiyat ve finansal işlem değiştiremez | | **Destek Ekibi** | Ticket, teknik özet, entegrasyon durumu | Ticket çözer, eskalasyon oluşturur | Finans ve fiyat bilgisine sınırlı erişir | | **Finans Ekibi** | Fatura, ödeme, tahsilat, MRR, lisans | Ödeme/tahsilat notu, finans raporları | Teknik log ve sistem ayarlarına erişemez | | **Teknik Ekip** | Entegrasyon, log, sistem sağlığı, workspace teknik bilgisi | Teknik problem ve servis yönetimi | Gelir ve fiyat bilgisine erişemez | | **Bayi Kullanıcısı** | Kendi ve bağlı kanal kayıtları, kendi kanal performansı | Müşteri adayı ekler, kayıtlarını takip eder | Başka bayilerin verilerini ve WEGS genel KPI'larını göremez | | **Alt Bayi Kullanıcısı** | Yalnızca kendi girdiği kayıtlar | Müşteri adayı ekler | Ana bayinin ve diğer alt bayilerin verilerini göremez | | **SMMM Kullanıcısı** | Yalnızca kendi yönlendirdiği kayıtlar | Yönlendirme yapar, durumlarını izler | Başka SMMM/bayi/WEGS iç verisini göremez | | **İçerik Yöneticisi** | Eğitim materyalleri, SSS, dosyalar | İçerik oluşturur, yayına alır | Yalnızca üst yönetim veya özel yetkilendirmeyle verilir | | **Salt Okunur** | Yetkilendirilen ekranlar | Sadece görüntüleme | Hiçbir kayıt değiştiremez | ### 11.1 Güvenlik ilkeleri - Panel müşteriye açık değildir; yalnızca WEGS iç ağı / yetkili kullanıcılar erişir - Panel doğrudan veritabanına sınırsız erişmez; servis/API katmanı üzerinden çalışır - **Her işlem audit log'a yazılır** - Kritik işlemlerde double-confirm, gerekirse yönetici onayı - Rol bazlı yetki + alan bazlı maskeleme + işlem bazlı izin **birlikte** kullanılır (ör. API anahtarı maskeli gösterilir, açma işlemi loglanır) --- ## 12. Karar kütüğü Alınmış ve gerekçesiyle sabitlenmiş kararlar. Bir öneri getirmeden önce bu liste okunmalıdır. | # | Karar | Gerekçe | Durum | |---|---|---|---| | **K-01** | Ayrı bir *Şube* nesnesi **yok** | "Şube" üç farklı şeyi anlatıyor; üçü de mevcut katmanlarla karşılanıyor (adres / workspace / firma) | Sabit | | **K-02** | Yapı rozeti ve durum alanları **türetilir**, elle girilmez | Elle girilen alan bakım yükü ve hata kaynağıdır | Sabit | | **K-03** | Grup tipi ve faturalama **ayrı alanlardır**; yapı rozeti grup tipinden türer, faturalamadan değil | Merkezi faturalama yapan bir franchise ağı ile grup şirketi aynı şey değildir | Sabit | | **K-04** | "Defter" kelimesi tasfiye edildi, nesne adı **Workspace** | Ürün içindeki gerçek nesne workspace'tir; iki isimli nesne olmaz | Sabit | | **K-05** | Faturalama tercihi **müşteri kaydında** durur, firma kaydında değil | Faturalama ticari ilişkinin özelliğidir, tüzel kişiliğin değil | Sabit | | **K-06** | Aynı VKN ile ikinci firma kaydı açılamaz; formda **canlı çakışma uyarısı** ve "Kayda git" butonu | Mükerrer kaydın en ucuz çözümü, hiç oluşmamasıdır | Sabit | | **K-07** | **Tek kaynak kuralı** — bir alanın hem girildiği hem hesaplandığı iki ayrı yer bulunmaz | İki kaynak = kaçınılmaz tutarsızlık | Sabit | | **K-08** | İndirim yetkisi **iki mekanizmalıdır**: fatura/ödemede sert sınır, teklifte onay akışı | Belge anında kesinleşir, teklif bir öneridir | Sabit | | **K-09** | Veri modeli üç katmana geçti: **Müşteri → Firma → Workspace** | "Müşteri grubu" opsiyonel bir etiketti; ticari ilişkinin gerçek sahibini taşıyamıyordu. Sözleşme ve faturalama tercihinin duracağı gerçek bir katman gerekti. | **v2'de değişti** | | **K-10** | **Kayıt anahtarı ≠ fatura kimliği** | Anahtar değişirse müşteri hafızası ikiye bölünür | Yeni | | **K-11** | Vergi kimliği olmayan firmaya satış **engellenmez**; geçici anahtar üretilir, lisans anında aktifleşir | Satışı durdurmak ticari kayıp; yasal risk fatura anındaki kuralla kapatılır | Yeni | | **K-12** | Ödemeden 7 gün sonra VKN gelmezse **e-Arşiv şahıs adına** otomatik kesilir | Yasal zorunluluk karşılanır, para bekletilmez | Yeni | | **K-13** | Menüde **üç katman = üç menü öğesi**; Müşteriler listesi varsayılan olarak çok firmalı yapıları gösterir | Menü hiyerarşiyi dürüstçe yansıtmalı; liste tekrarı filtreyle çözülür | Yeni | | **K-14** | Workspace'ler modülü ayrı kalır, firma içine gömülmez | Destek/teknik ekip firmadan bağımsız workspace sorgusu yapıyor | Yeni | | **K-15** | "tek defterli / ayrık defterli" ifadeleri düşürüldü; rozetler `Tekil · Çok workspace'li · Grup üyesi · Franchise noktası` | Muhasebe jargonu operasyon ekibine gereksiz yük | Yeni | | **K-16** | Dashboard aksiyon kartında **"Seat %100 dolu" uyarısı yok** | Seat dolması sorun değil, olağan durum | Yeni | | **K-17** | Bayi & SMMM Kanal Yönetimi **alt menü değil, ayrı modül** | — | Yeni | --- ## 13. Değişmez tasarım kuralları Bu kurallar tüm modüllerde geçerlidir ve modülden modüle tartışılmaz. ### 13.1 Türetilmiş veri kuralı Ekranda görünen her sayının kaynağı belli olur. | Gösterge | Kaynağı | |---|---| | MRR | Ürün satırlarının aylık tutarları toplamı | | Sözleşme değeri | MRR × sözleşme süresi + tek seferlik kalemler | | "X gündür durgun" | Son aktivite kaydının tarihi ile bugün arasındaki fark | | "X× ertelendi" | Tarihin ileri alındığı değişiklik kayıtlarının sayısı | | Aşamada geçen gün | İki aşama giriş tarihi arasındaki fark | | Gecikme uyarısı | Beklenen tarih < bugün **ve** kayıt hâlâ açık | | VKN geri sayımı | Ödeme doğrulama tarihi + 7 gün − bugün | > **Kaynağı görünmeyen sayı ekranda durmaz.** Bir gösterge elle girilmiş bir alandan besleniyorsa ya kaynağı kullanıcıya gösterilir (tooltip, kayıt listesi, zaman çizelgesi) ya da gösterge kaldırılır. ### 13.2 Veri girişi ve görünürlük - **Bir alanın girildiği yer ile görüldüğü yer aynı olmalıdır.** Kilit penceresinde toplanan her alan, ait olduğu aşamanın altında geri gösterilir ve orada düzeltilebilir. Kullanıcı veriyi girdiği ekranı bir daha bulamıyorsa o veri ölüdür. - Her düzeltme aktivite çizelgesine **eski → yeni** değeriyle ve değiştiren kişiyle yazılır. - 20 kayıttan fazlasında `