CRM for Everyone: Satış Dışı Ekipleri CRM'e Almak

CRM for Everyone ile modüller iki türe ayrılır. Org modülü (Organization Module), Leads, Contacts, Accounts, Deals gibi standart modüller ve yöneticinin açtığı özel modüllerdir; tüm organizasyon için tasarlanır, erişimi profil ve rol belirler. Ekip modülü (Team Module) ise bir ekibin kendi süreci için açtığı ve yalnızca o modüle eklenen kişilerin gördüğü modüldür.

Bu ayrım teknik bir ayrım değil, sahiplik ayrımıdır. Karar anında sorulacak tek soru şudur: "Bu veri şirketin ortak hafızası mı, yoksa bir ekibin iş takibi mi?"

Karar kuralı

• Veriyi birden fazla ekip günceller ve raporlar birleşik bakmalıysa org modülü. Estetik klinikte "Tedavi Planı" hem danışman, hem hekim, hem finans tarafından okunuyor ve ciroya bağlanıyorsa bu bir org modülüdür.
• Veriyi tek ekip üretir, diğerleri yalnızca sonucunu görürse ekip modülü. Medikal ekibin ön değerlendirme notları, hukuk ekibinin sözleşme incelemesi, kalite ekibinin uygunsuzluk kaydı buna örnektir.
• Erişimin kişi bazında daraltılması gerekiyorsa ekip modülü. Participant profiliyle herkes yalnızca kendi kaydını görür; bunu org modülünde rol ve paylaşım kuralıyla kurmak çok daha ağırdır.
• Org kaydının bu veriyi alan olarak taşıması gerekiyorsa org modülü. Org modülünden ekip modülüne lookup kurulamaz. Deals kaydında bu veri bir alan olarak dururken iş akışı ve rapor kurmanız şartsa veriyi org modülü olarak açın; yalnızca görmek yetiyorsa ekip modülü ile bağlı kayıt (Connected Records) ya da ilgili liste yeterlidir.

Sürüme göre limitler

Standard'daki tek lookup alanı pratikte şu demektir: ekip modülünü aynı anda hem Contacts'a hem Deals'a alan olarak bağlayamazsınız. Klinik için bu çoğu zaman Contacts'tır, çünkü medikal değerlendirme hastaya aittir, satış fırsatına değil. Anlaşma bağlamı da gerekiyorsa ya bağlı kayıt kullanılır ya da sürüm sorusu öne çıkar.

Teamspace, bir ekibin kenar çubuğunda gördüğü modül kümesidir. İçinde org modülleri de ekip modülleri de bulunabilir. Onu bir yetki katmanı olarak değil, masa düzeni olarak düşünün: teamspace kimin hangi modülleri önünde bulacağını düzenler; kaydın kendisine erişimi ise profil, rol ve ekip modülü profili belirler.

Mekaniği bilmeden kurgu yapılmaz

• CRM for Everyone açıldığında tüm modüller "CRM Teamspace" adlı varsayılan alana bağlanır. Hiç teamspace kurmadıysanız herkes bu alanda çalışır.
• Bir teamspace'e eklenmek, içindeki ekip modüllerine erişim vermez. Her ekip modülünde ayrıca profil atanmalıdır. Org modülleri ise kullanıcının mevcut profil iznine göre görünür.
• Her teamspace'in tek bir yöneticisi olur. Herhangi bir aktif CRM kullanıcısı bu rolü alabilir; özel bir profil izni gerekmez. Manage Teamspace izni olanlar ise tüm teamspace'leri yönetebilir.
• Erişim "seçili kullanıcılar" olarak ayarlandığında teamspace yöneticisi otomatik eklenmez. Kendini kullanıcı olarak eklemezse yönettiği alanı ön yüzde göremez.
• Org modülleri birden fazla teamspace'te yer alabilir. Teamspace silinirse içindeki ekip modülleri silinmez, bağsız kalır ve başka bir teamspace'e eklenebilir.
• Teamspace başına en fazla 50 klasör açılır; klasör seçilmezse modül "Root" altına düşer. Modülü olmayan bir teamspace kaydedilemez.
• Zoho Projects entegreyse teamspace'e proje de eklenebilir: teamspace başına 30, tüm teamspace'lerde toplam 500 proje. Entegrasyon teamspace içinden ilk kez kurulursa Projects deneme sürümünde açılır (3 proje, 10 kullanıcı).

Teamspace'i neye göre bölmeli

Fonksiyona göre

Satış, Pazarlama, Operasyon, Hukuk. Çoğu KOBİ için doğru başlangıç budur; Standard'ın 5 teamspace limitine de sığar.

Lokasyona göre

İki şubeli klinik, üç bölge müdürlüğü. Dikkat: şubeler arası veri ayrımı rol ya da bölge (territory) ile yapılır. Teamspace yalnızca ekranı sadeleştirir, veriyi ayırmaz.

Sürece göre

Üretim firmasında Kalite (QA/QC), Bakım, Tedarik. Her biri kendi ekip modülünü taşır; ortak müşteri ve sipariş verisi org modülünde kalır.

Örnek: butik estetik klinik

Üç teamspace yeterli olur. Hasta Danışmanlığı: Leads, Contacts, Deals ve Randevular (Appointments). Medikal Ekip: Contacts (yalnızca okuma profiliyle) ve "Ön Değerlendirme" ekip modülü. Pazarlama: Leads, Campaigns ve "İçerik ve Görsel Onayı" ekip modülü. Son modül Türkiye'de ayrıca önemlidir: önce/sonra fotoğrafının pazarlamada kullanılması hastanın açık rızasına bağlıdır. Rıza durumu, fotoğrafın kullanılacağı kanal ve rıza tarihi bu modülde alan olarak tutulur; pazarlama ekibi hastanın iletişim bilgisine erişmeden yalnızca onaylı içeriği görür.

CRM for Everyone'ın getirdiği asıl değişiklik arayüz değil, yönetimin dağıtılmasıdır. Eskiden her alan ve her iş akışı merkezi yöneticiden geçerdi; satış dışı ekipler de küçük bir değişiklik için haftalarca beklediği için CRM'i bırakıp kendi tablolarına dönerdi. Şimdi üç yönetici katmanı var. Rol, profil ve paylaşım kurallarının kendisini Güvenlik ve Erişim Yönetimi rehberinde ele aldık; burada yalnızca yeni katmanların o yapıya nasıl oturduğunu anlatıyoruz.

Merkezi yönetici gücünü kaybetmez. Ekip modülü yöneticisinin kararlarını geri alabilir, onu görevden alabilir, ekip modüllerinin tüm yapılandırmasına Setup > Customization > Modules and Fields üzerinden ulaşabilir. Ama kayıt verisini görmek için kendini modüle eklemesi gerekir. Bu, KVKK açısından olumlu bir varsayılandır: "BT her şeyi görüyor" itirazına karşı somut bir cevaptır.

Ekip modülü içindeki beş profil

Alan ve eylem izinleri profil bazında modül > ... > Manage Profiles penceresinden ayarlanır; Fields sekmesi alt form alanlarını da kapsar. Notes ve Attachments eylemleri tüm profillerde varsayılan olarak kapalıdır. Canlıya geçişin ilk günü gelen "not ekleyemiyoruz" şikâyetinin tipik sebebi budur.

Public field: org verisini modülü açmadan göstermek

Ekip modülündeki bir kullanıcının Accounts ya da Contacts modülüne erişimi olmayabilir. Lookup ile bağlanan kaydın seçili alanlarını Public field olarak işaretlediğinizde bu alanlar ekip modülü kaydının içinde görünür; kullanıcı ana modüle hiç girmez. Standard ve üzeri sürümlerde vardır, tüm sürümlerde sınır 30 alandır. Klinikte hekim, hastanın yaşını, geçmiş işlem bilgisini ve alerji alanını görür; telefon, adres ve ödeme bilgisini görmez. Bu, KVKK'nın veri minimizasyonu ilkesinin CRM'deki doğrudan karşılığıdır.

Erişim kapsamını kurma sırası

1. 01Create Team Module iznini kime vereceğinizi seçin

   Neden: Bu izne sahip her kullanıcı, üyesi olduğu her teamspace'te ekip modülü açabilir. Kontrolsüz izin, üç ayda kimsenin sahiplenmediği modüller üretir.

   Setup > Security Control > Profiles içinde, Admin Level Permissions altındaki Create Team Module seçeneği.

2. 02Teamspace'i ve yöneticisini belirleyin

   Neden: Teamspace erişimi daraltılmazsa herkes her ekibin modül listesini görür; kafa karışıklığı yetki sorunundan önce gelir.

   Admin & Permissions bölümünde "seçili kullanıcılar" seçeneğiyle kullanıcı, rol, profil ya da grup ekleyin. Yöneticiyi ayrıca kullanıcı olarak eklemeyi unutmayın.

3. 03Ekip modülüne kişileri profilleriyle ekleyin

   Neden: Teamspace üyeliği modül erişimi vermez; bu adım atlanırsa modül boş görünür.

   Modül > ... > Manage User Access > Add User, ardından Access Type seçimi. Birden çok kullanıcıya toplu profil atanabilir.

4. 04Alan izinlerini ve eylemleri ayarlayın

   Neden: Hassas alan (ör. medikal not) yalnızca Member ve üstüne açık olmalı; Participant ve Requester görmemeli.

   Manage Profiles > Actions ve Fields sekmeleri. Notes ve Attachments'ı gereken profillerde açın.

5. 05Public field seçimini ekipler arasında paylaştırın

   Neden: 30 alanlık sınır tüm organizasyon içindir; ilk açılan ekip hepsini tüketirse sonraki ekip boşta kalır.

   Her ekip için "bu ekibin işini yapması için gereken en az alan" listesini yazılı hâle getirin.

6. 06Kimin hangi ekip modülünde olduğunu kayıt altına alın

   Neden: KVKK denetiminde "bu veriyi kim görebiliyor" sorusu tek bir listeyle cevaplanmalı.

   Özellikle merkezi yöneticinin kendini eklediği modülleri ve bunun gerekçesini not edin.

Satış dışı ekibin CRM'e girmesinin önündeki en somut engel lisans maliyetiydi: ayda birkaç kez bir kayda bakacak hukuk danışmanı ya da kalite sorumlusu için tam lisans ödemek zor savunulur. Team User lisansı bu boşluğu dolduruyor. Ama bir bedeli var: düşük fiyat, org modüllerinde dar yetki demek.

Org modüllerinde çizilen sınır

Team User yapabilir

• En fazla 10 org modülünde, rol ve hiyerarşisine göre kayıt görmek (varsayılan: Leads, Contacts, Accounts, Deals)
• Org kayıtlarına not, etiket ve ek eklemek
• Entegrasyonlarla gelen kayıtları görmek, Feeds üzerinden yazışmak

Team User yapamaz

• Org kaydına sahip olmak, kaydı paylaşmak, sahibini değiştirmek
• Toplu güncelleme, silme, içe ve dışa aktarma
• Send Email ile e-posta, arama ya da toplantı başlatmak; Leads, Quotes, Sales Orders dönüştürmek
• Rapor ve analitik görmek, Zia ile zenginleştirme, sandbox, kullanıcı alanına (User field) atanmak

Ekip modüllerinde ise bu sınırlar geçerli değildir. Team User'ın yetkisi yalnızca modüldeki profiline bağlıdır: kayıt sahibi olur, içe ve dışa aktarır, toplu e-posta gönderir, hatta modülün yöneticisi olabilir. Yani Team User, "kendi ekibinde tam yetkili, şirketin ortak verisinde misafir" bir kullanıcıdır.

Otomasyonun Team User karşısındaki davranışı

• Assignment rule kaydı Team User'a atamaz. Kriter uysa bile atlanır. Satış temsilcisi rolüne bir Team User koyarsanız dağıtım dengesi sessizce bozulur.
• Workflow ile oluşan org kaydında sahip Team User'a denk gelirse sahiplik ana kaydın sahibine gider.
• Sahip alanı olmayan bir wizard ile Team User org kaydı açarsa kayıt, Team User'ın alt rolündeki bir normal kullanıcıya; alt rol yoksa Super Admin'e atanır.
• Team User manuel e-posta gönderemez, ama gönderen "Current User's Email" olarak ayarlanmış iş akışı, onay ya da fonksiyon e-postaları onun adresinden çıkabilir. Müşteriniz, beklemediği bir operasyon personelinden e-posta alabilir; bunu bilinçli tasarlayın.

Rol bazında lisans kararı

Ekleme yolu: Setup > General > Users > + New User yanındaki ok > Add New Team User. Toplu eklemede Import Users kullanılır; CSV'deki Profile değeri "Team" içermelidir. İçe aktarma yalnızca yeni kullanıcı ekler, mevcut Team User'ı güncellemez; lisans sayısı dolunca kalan satırlar atlanır ve Import History'de gerekçesiyle listelenir.

Ekipler arası iş en çok "bir bakar mısın" mesajlarında kaybolur. Türkiye'de klinik ve hizmet firmalarında bu kanal neredeyse her zaman WhatsApp grubudur. Talep geldi mi, kim üstlendi, ne zaman bitti sorularının cevabı bir telefonun sohbet geçmişinde kalır; çalışan ayrıldığında o geçmiş de gider.

Requester (talep eden), ekip modülünün dışından talep açan kişidir. Modülü teamspace'te görmez, mevcut kayıtlara erişemez, kayıt sahibi olmaz ve modülü yapılandıramaz. Kenar çubuğundaki My Requests (Taleplerim) sekmesinden, kendisine açılmış ekip modüllerine talep açar ve yalnızca kendi taleplerini izler. Her talep ekip modülünde yeni bir kayıttır; talebi alan ekip kendi sürecini o kayıt üzerinde yürütür ve tüm geçmiş kaydın zaman çizelgesinde kalır.

Talebi doğru kişiye düşürmek: Requester Settings

Yol: ekip modülü > ... > Requester Settings. Bu ayarı yalnızca modülün yöneticileri değiştirebilir.

• Varsayılan sahip: Admin, Manager, Member ve Participant arasından en fazla 5 kişi seçilir. Birden fazla kişi seçilirse talepler sırayla (round-robin) dağıtılır.
• Atama kuralı: Kritere göre sahip belirlemek için bir assignment rule bağlanır. Requester ayarına bağlı bir kural doğrudan silinemez; önce ayar değiştirilmelidir.
• Hiç kimse seçilmezse talep bir modül yöneticisinin üzerine düşer.
• Davet: Benzersiz bir bağlantı ya da QR kodla kişi kendi kendine requester olur. Tüm şirkete hizmet veren ekipler için "Allow All Org Users as Requesters" seçeneği vardır.
• Bildirim: Kullanıcı requester olarak eklendiğinde modül adını ve Requests sekmesi bağlantısını içeren bir e-posta alır.

Talebi bağlamıyla açmak

Ekip modülü lookup ile Deals ya da Contacts'a bağlıysa, talep ana kaydın ilgili listesinden (related list) açılabilir ve lookup alanı otomatik dolar. Requester'ın formda gördüğü alanlar, modül yöneticisinin tanımladığı alan izinleriyle ve modülün business card alanlarıyla belirlenir. Talep ayrıca bağlı kayıt bölümünden de açılabilir; kullanıcının her seferinde My Requests sekmesine gitmesi gerekmez.

Klinik akışı

1. 01

   Talep

   Danışman, hastanın kaydında "Ön Değerlendirme" listesinden talep açar; şikâyet ve fotoğraf alanlarını doldurur.

2. 02

   Atama

   Requester Settings'e bağlı kural, talebi işlem türüne göre ilgili hekime atar.

3. 03

   Değerlendirme

   Hekim notunu yazar, durum alanını "Uygun" ya da "Ek muayene" yapar.

4. 04

   Dönüş

   Danışman sonucu Taleplerim sekmesinde görür ve hastaya döner. WhatsApp'ta kimseye soru sormaz.

Ekipleri CRM'e aldıktan sonraki soru, işin ekipten ekibe nasıl devredileceğidir. Lookup alanı bu ilişkiyi baştan, yönetici eliyle ve bire bir referans olarak kurar. Connected Records (bağlı kayıtlar) ise kayıt anında, alan açmadan kurulan esnek bir bağdır.

• Bağın hedefi her zaman bir ekip modülüdür: org modülünden ekip modülüne ya da ekip modülünden ekip modülüne. Hesapta hiç ekip modülü yoksa bölüm görünmez.
• Oluşturulabilecek bağlı kayıt sayısında sınır yoktur. Create Team Module iznine sahip kullanıcılar bağlı kayıt oluşturabilir.
• Bağlı kaydı silmek yalnızca bağı kaldırır; iki kayıt da yerinde kalır.
• Bağ kendiliğinden güncellenmez. Karşı kayıttaki bir değişikliğin diğerine yansıması için iş akışı ya da bağlı akış gerekir.

Connected Workflows: devri otomatikleştirmek

Anlaşma kazanıldığında operasyonun başlaması, operasyon bitince eğitimin açılması, eğitim bitince müşteri tipinin güncellenmesi: tek modüllük bir iş akışı kuralı bu zinciri taşıyamaz. Connected Workflow (bağlı akış) bir birincil modülde başlar ve bağlı modüllerdeki tetikleyicileri ile eylemleri tek bir akışta tanımlar.

• Tetikleyiciler: kayıt oluşturulduğunda, düzenlendiğinde, oluşturulduğunda ya da düzenlendiğinde, belirli bir alan değiştiğinde.
• Eylemler: bağlı modülde yeni bağlı kayıt oluşturmak, mevcut bağlı kaydı güncellemek, e-posta ile bildirmek.
• Çok modüllü kriter: "Other module criteria" ile koşul, bağlı modüllerdeki değerlere göre kurulur. ANY ya da ALL seçimi "bağlı taleplerden biri tamamlandığında" ile "hepsi tamamlandığında" arasındaki farkı belirler.

Danışmanlık firması örneği. Birincil modül Deals. Anlaşma "Closed Won" olduğunda "Proje Açılışı" ekip modülünde bağlı kayıt oluşur. Proje Açılışı "Tamamlandı" olduğunda "Eğitim" ekip modülünde kayıt açılır ve satış temsilcisine bildirim gider. Eğitim kaydı tamamlandığında Accounts'taki müşteri tipi güncellenir. Dört modül, Standard'ın 5 modüllük sınırına sığar; ama iki akışlık hak burada birini tüketir. İkinci akışı neye ayıracağınızı baştan planlayın.

Ekip modülü yöneticisinin otomasyon sınırı

Ekip modülü yöneticisi kendi modüllerinde Assignment Rules, Workflow Rules, Blueprint ve Approval Process kurar. Custom function, webhook ve Zoho Flow eylemi oluşturamaz, yalnızca mevcut olanları bağlayabilir. Org modüllerini hiçbir şekilde etkileyemez; yönetmediği ekip modüllerinde yalnızca kayıt oluşturabilir. Blueprint'te geçiş sahibi olarak ekip dışından herhangi bir CRM kullanıcısını seçebilir. Bir org kaydından tetiklenen iş (anlaşma kazanıldı, operasyon kaydı açılsın) ya da dış sisteme giden bir webhook gerekiyorsa bunu org yöneticisi veya Manage Automation izni olan kişi kurar. Kurulum yolları: Setup > Automation > Workflow Rules, Setup > Automation > Assignment > Rules, Setup > Process Management > Blueprint ve Approval Processes. Blueprint ile iş akışı kuralı arasındaki genel tercihi İş Akışı Otomasyonu ve Süreç Yönetimi (Blueprint, Onay, İnceleme) rehberlerinde tartıştık.

Yeni arayüz modül içine dört görünüm ekledi. Liste, Kanban ve Canvas görünümlerini Modüller, Görünümler ve Sayfa Düzeni rehberinde anlattık. Burada yeni görünümleri "hangi yönetim sorusuna cevap veriyor" ekseninde ele alıyoruz; çünkü görünüm seçimi, raporun yapmadığı işi ekranın içinde yapmanın yoludur.

Grid: tablo alışkanlığını CRM'de tutmak

Hücre içinde düzenleme, bir hücreyi sürükleyerek aynı değeri alttaki satırlara yayma ve birden çok kaydı seçip tek değer girme ile toplu güncelleme yapılır. Sayısal kolonlarda Add Aggregate ile toplam, ortalama, en küçük ve en büyük değer alınır (Number, Decimal, Currency, Long Integer, Percentage; Phone ve Auto Number desteklenmez). Onay bekleyen kayıt Grid'den onaylanır, reddedilir ya da devredilir. Satırdan kayıt oluşturma şu durumlarda form penceresine döner: zorunlu alan kolonlarda yoksa, modülde layout rule ya da veri zenginleştirme açıksa, varsayılan oluşturma yöntemi wizard ise, layout Campaign modülüne bağlıysa. Client script Grid'de çalışmaz.

Split: filtre yerine yan yana bölmeler

Kayıtlar picklist, kullanıcı ya da kriter ile bölünür. Bir split görünümünde en az 2, en fazla 10 bölme olur; bölme başına en fazla 10 kriter tanımlanır. Bölme başına gösterilecek kayıt sayısı tüm bölmeler için ortaktır. Picklist ve kullanıcı bölmelerinden doğrudan kayıt oluşturulabilir. "Select All" çalışmaz. Oluşturmak ve düzenlemek için Manage Views izni gerekir; paylaşılmış bir split görünümünü kullanmak izin istemez.

Chart: rapora gitmeden dağılımı görmek

Group By ile en fazla iki kategori, Measure ile en fazla iki ölçü seçilir. Gruplama alanı Date, Date/Time, Picklist ya da User olabilir; varsayılan gruplama kayıt sahibi, ölçü kayıt sayısıdır. Grafik türleri: column, bar, pie, donut, area, line, funnel. Grafik yayınlanabilir, yazdırılabilir ya da Analytics'teki bir panoya eklenebilir. Modül başına en fazla 5 grafik yayınlanır; silinen grafik geri getirilemez.

Timeline: iş yükünü zamana yaymak

Başlangıç ve bitiş için iki tarih alanı seçilir; Deals'ta varsayılan Created Time ve Closing Date'tir. "Working Days Only" seçilirse hafta sonu ve tatiller Company Settings içindeki Business Hours ayarına göre çıkarılır. Varsayılan renkler: yeşil tamamlanan, mavi süren, sarı başlamamış kayıt. Kayıt başına en fazla dört alan gösterilir, Record Name zorunludur. Kayıtlar picklist ya da kullanıcı alanına göre gruplanır. Başlangıç tarihi olmayan ya da bitişi başlangıçtan önce olan kayıtlar görünmez.

Interactions sekmesi, Leads ve Contacts kayıtlarında müşterinin tüm temas noktalarını kronolojik bir konuşma gibi dizer: solda müşterinin ürettiği sinyaller, sağda ekibin yaptığı takipler. Soru şu: bu müşteriyle en son ne zaman, hangi kanaldan, kim konuştu ve arada ne kadar boşluk kaldı? Enterprise ve Ultimate sürümlerde vardır. Kaydı görme izni olan herkes sekmeyi de görür. Yol: Leads ya da Contacts > kayıt > Timeline sekmesi > Interactions.

Signals

Müşterinin ürettiği hareket: e-posta açma, arama, web sitesi ziyareti, anket yanıtı. Bazı kanallarda ilgi düzeyini gösteren ek bilgi (impression) gelir: ankette yanıtlanan soru sayısı, ziyarette süre ve sayfa sayısı.

Follow-ups

Ekibin başlattığı temas, kimin yaptığı ve tarihiyle. Bazı kanallarda sonuç durumu eklenir: aramada yanıtlandı ya da yanıtlanmadı, e-postada Delivered ya da Bounced, Desk kaydında Open, Closed, On Hold, Escalated.

Milestones ve boşluk

Kilometre taşları yolculuğun büyük adımlarını işaretler. Sinyal ile takip arasındaki süre gösterilir; ortalamadan uzun boşluk "orphan state" olarak işaretlenir.

Görünüm üç türlüdür: All tüm öğeleri, Signals yalnızca müşteri sinyallerini ve her sinyalden önceki son takibi, Milestones ise kilometre taşlarını ve her birinden önceki son temasa odaklanır. Kanal, kullanıcı ve zaman aralığıyla (bugün, dün, son 7 gün, son 30 gün ya da özel aralık) filtrelenir.

İki mekanik, iki sonuç

• Kilometre taşı, history tracking açık bir picklist'e dayanır. Modülde böyle bir alan yoksa kilometre taşı hiç görünmez. Takibi açtığınız andan önceki etkileşimler için geriye dönük kilometre taşı oluşmaz; yani bu ayarı ne kadar geç açarsanız o kadar kısa bir geçmiş okursunuz.
• Orphan state modül ortalamasına göre hesaplanır ve haftada bir yeniden hesaplanır. Sabah listesinde "bu hafta sahipsiz kalan hastalar" sorusunun cevabı buradan okunur, ama anlık değildir.

CRM for Everyone'ı "açıldı, kullanıyoruz" diyerek bırakan hesaplarda üç ay sonra aynı tablo görülür: varsayılan teamspace'te yirmi modül, kimin açtığı belli olmayan ekip modülleri, satış rolüne konmuş ve kayıt alamayan Team User'lar. Aşağıdaki sıra bunu önlemek için kurgulandı; değiştirmesi zor olan kararlar başta, sonradan değişebilenler sonda.

1. 01Mevcut durumu çıkarın

   Neden: Eski sekme grupları teamspace'e dönüştü, ama çoğu hesapta hâlâ her şey varsayılan "CRM Teamspace" içinde duruyor.

   Setup > Customization > Teamspace ekranında her teamspace kartının bilgi simgesinden içindeki modülleri listeleyin.

2. 02CRM dışında yürüyen işi envanterleyin

   Neden: Hangi ekibin hangi işi Excel'de, e-postada ya da WhatsApp grubunda tuttuğunu bilmeden modül türüne karar verilemez.

   Her iş için tek soru: ortak veri mi (org modülü), ekibin iş takibi mi (ekip modülü)?

3. 03Sürüm limitlerini eşleyin

   Neden: Standard'da 5 teamspace, modül başına 1 lookup ve 2 bağlı akış, tasarımı doğrudan şekillendirir.

   Timeline ve Interactions gerekiyorsa Enterprise ya da Ultimate şarttır; bu ihtiyaç lisans görüşmesinden önce netleşmeli.

4. 04Lisansı iş tanımına göre dağıtın

   Neden: Team User'dan normal kullanıcıya geçiş tek yönlüdür.

   Kayıt sahibi olacak, e-posta atacak, rapor görecek herkes normal lisansla; talep karşılayan ve kendi modülünde çalışan ekipler Team User ile.

5. 05İlk ekip modülünü tek ekiple deneyin

   Neden: Profil, alan izni ve requester akışı gerçek kullanıcıyla sınanmadan çoğaltılmamalı.

   Sandbox'ta kurup deneyebilirsiniz; ekip modülünü canlıya Administrator ya da Manage Sandbox izni olan kişi aktarır.

6. 06Requester akışını açın, paralel kanalı kapatın

   Neden: WhatsApp grubu açık kaldıkça talep CRM'e gelmez.

   Requester Settings ile sahip dağıtımını kurun, tamamlanma bildirimini iş akışıyla ekleyin.

7. 07Görünürlüğü kurun, sonra otomasyonu

   Neden: Ölçülmeyen bir devri otomatikleştirmek, yalnızca hatayı hızlandırır.

   Önce Chart ve Split görünümlerini yayınlayın; talep süreleri bir ay ölçüldükten sonra bağlı akışı kurun.

En sık gördüğümüz hatalar

• Create Team Module iznini geniş bir profile açmak. Kimsenin sahiplenmediği, adı birbirine benzeyen modüller birikir.
• Teamspace yöneticisini atayıp kullanıcı olarak eklememek. Yönetici alanı göremez ve "teamspace çalışmıyor" diye destek kaydı açar.
• Team User'ı satış rolüne koyup assignment rule'dan kayıt beklemek. Kural onu atlar, dağıtım dengesi bozulur.
• Standard'da ekip modülünün tek lookup alanını yanlış modüle bağlamak. Sonradan değiştirmek, dolu alanı taşımak demektir.
• Merkezi yöneticinin ekip modülü verisini gördüğünü varsaymak. Kendini eklemedikçe görmez; denetim listesi buna göre tutulmalı.
• Notes ve Attachments'ı açmayı unutmak. İlk gün ekibin kayda hiçbir şey ekleyemediği görülür.