छोटी टीमों के लिए हल्का CRM स्कीमा जो सरल बना रहता है

यह CRM स्कीमा कौन सी समस्या हल करना चाहिए

एक छोटी टीम को एक ऐसे CRM की ज़रूरत होती है जो रोज़मर्रा के सवालों का तेज़ जवाब दे: हम किससे बात कर रहे हैं, हम क्या बंद करने की कोशिश कर रहे हैं, आख़िरी बार क्या हुआ, और अगला कदम क्या है। यही एक हल्के CRM स्कीमा का असली काम है। जो कुछ भी इन सवालों का समर्थन नहीं करता, वह अक्सर शोर होता है।

छोटी टीमों को शायद गहरी अकाउंट हायरार्कियाँ, दर्जनों कस्टम ऑब्जेक्ट्स या जटिल स्कोरिंग मॉडल की ज़रूरत नहीं होती। उन्हें स्पष्ट ownership, टचप्वाइंट्स का सरल हिस्ट्री, और एक पाइपलाइन चाहिए जिसे सब एक ही तरह समझें।

"सरलता" तब टूटती है जब यह free text और duplicates पर निर्भर हो। अगर एक व्यक्ति डील स्टेज को "Negotiation" लिखता है और दूसरा "negotiating" लिखता है, तो रिपोर्टिंग अनुमान बन जाती है। अगर activities अलग तालिकाओं में रहती हैं (calls, meetings, notes), तो आपके पास कई तारीख़ फ़ील्ड्स हो जाते हैं और कोई भरोसेमंद “last touched” मान नहीं रह जाता।

यह स्कीमा चार मुख्य ऑब्जेक्ट्स पर टिकता है जो अधिकांश छोटी-टीम CRM आवश्यकताओं को कवर करते हैं बिना इसे एक राक्षस में बदलने के:\n

• Contacts (और वैकल्पिक रूप से organizations) — वे लोग जिनसे आप बात करते हैं\n- Deals — वे अवसर जिन्हें आप पाइपलाइन के माध्यम से ट्रैक करते हैं\n- Activities — tasks, meetings, calls, और notes के लिए एक एकीकृत लॉग\n- Permissions — यह तय करने वाले व्यावहारिक नियम कि कौन क्या देख सकता और एडिट कर सकता है\n साफ़ रिपोर्टिंग का मतलब है कि आप भरोसेमंद तरीके से देख सकें: इस सप्ताह स्टेज के अनुसार डील्स, स्टेज से स्टेज कन्वर्ज़न रेट, किसी स्टेज में औसत समय, डील के अनुसार आख़िरी एक्टिविटी, और हर रेप के आज के खुले टास्क। ये रिपोर्ट तब भी समझदारी से काम करनी चाहिए जब टीम 3 से बढ़कर 15 हो जाए।

अगर आप AppMaster जैसी no-code टूल में एक आंतरिक CRM बना रहे हैं, तो यह तरीका डेटाबेस छोटा रखता है जबकि डैशबोर्ड और साप्ताहिक समीक्षाओं के लिए स्थिर नंबर देता है।

खुद को बँधे बिना हल्का रहने के सिद्धांत

एक हल्का CRM स्कीमा तब काम करता है जब यह एक सवाल स्पष्ट रूप से जवाब दे: यह तथ्य कहाँ रहता है? अगर एक ही “सच” दो जगह स्टोर हो सकता है, तो होगा भी—और आपकी रिपोर्ट्स धीरे-धीरे अलग हो जाएँगी।

स्रोत-सच ऑब्जेक्ट्स का एक छोटा सेट चुनें और बाकी सब कुछ उन्हें पॉइंट करे। अधिकांश छोटी टीमों के लिए यह हैं: Contacts, Organizations (ऑप्शनल), Deals, और Activities। जब अधिक विवरण चाहिए, तो एक नई तालिका जोड़ें बजाय एक टेक्स्ट फ़ील्ड में सबकुछ भरने के जो बाद में जंक ड्रॉर बन जाए।

कुछ नियम मॉडल को सरल और लचीला रखते हैं:\n

• एक तथ्य, एक घर: फ़ोन नंबर Contact का है, डील वैल्यू Deal की है।\n- ओवरलोडेड फ़ील्ड्स की बजाय स्पष्ट टेबल चुनें: stage history एक comma-separated string नहीं होना चाहिए।\n- IDs स्थिर रखें और नाम एडिटेबल: लोग कंपनियों के नाम बदलते हैं, प्राइमरी कीज़ नहीं।\n- "status" को "type" से अलग रखें: एक task एक समय में “open” और “call” दोनों हो सकता है।\n- मान लें कि imports गंदे होंगे: खाली, डुप्लिकेट, और अजीब फॉर्मैटिंग सामान्य हैं।

दिन एक पर गंदे डेटा की योजना बनाएं: अपने कोर टेबल्स पर कुछ सामान्य परंतु शक्तिशाली फ़ील्ड जोड़ें: created_at, updated_at, और एक सरल external_id (या import_source + import_key)। यह आपको री-इम्पोर्ट करने का सुरक्षित तरीका देता है बिना डुप्लिकेट बनाए।

एक ठोस उदाहरण: आप एक स्प्रेडशीट इम्पोर्ट करते हैं जहाँ “Acme Inc.” आधी पंक्तियों में “ACME” के रूप में दिखाई देती है। यदि Organization.name एडिटेबल है और Organization.id स्थिर है, तो आप बाद में रिकॉर्ड्स मर्ज कर सकते हैं बिना मौजूदा deals और activities को तोड़े।

Contacts और organizations: काम करने वाला सबसे सरल स्ट्रक्चर

एक हल्का CRM स्कीमा एक निर्णय से शुरू होता है: क्या आप केवल लोगों को ट्रैक करते हैं, या लोगों के साथ कंपनियों को भी? यदि आपकी टीम व्यवसायों को बेचती है, तो आप आमतौर पर दोनों चाहते हैं: Contact (व्यक्ति) और Organization (कंपनी)। यदि आप उपभोक्ताओं को बेचते हैं, तो आप organizations पूरी तरह छोड़ सकते हैं और हर रिकॉर्ड को contact के रूप में रख सकते हैं।

B2B सेटअप के लिए रिश्ते को सरल रखें: प्रत्येक contact एक प्राथमिक organization से संबंधित हो (nullable), और एक organization के कई contacts हो सकते हैं। यह अधिकांश छोटी-टीम वर्कफ़्लोज़ को कवर करता है बिना आपको जटिल अकाउंट हायरार्कियों की ओर धकेले।

आवश्यक फ़ील्ड्स को न्यूनतम रखें

बहुत सारे फ़ील्ड्स अनिवार्य बना देने से डेटा गन्दा होने का सबसे तेज़ तरीका है। एक अच्छा बेसलाइन है:\n

• Contact: id, नाम (या first_name + last_name), created_at\n- Organization: id, name, created_at\n बाकी सब (job title, website, address, industry, source) वैकल्पिक हो सकते हैं। बाद में नियम जोड़ सकते हैं, पर उन जगहों को साफ़ करना मुश्किल है जहाँ "N/A" जैसे placeholder भरे गए हों।

ईमेल और फ़ोन: दर्द के बिना यूनिकनेस

ईमेल को unique बनाना प्रलोभन होता है। यह B2C या उस CRM के लिए अच्छा है जो आपके लॉगिन सिस्टम के रूप में भी काम करता है। छोटी B2B टीमों में, साझा इनबॉक्स (sales@, info@) और बार-बार उपयोग किए गए फोन नंबर आम हैं। सख्त यूनिकनेस नियम वैध रिकॉर्ड्स को ब्लॉक कर सकते हैं।

एक व्यावहारिक समझौता:\n

• यूनिकनेस तब ही लागू करें जब वैल्यू मौजूद हो (और केवल यदि यह आपके उपयोग के मामले से मिलता हो)।\n- डुप्लिकेट की अनुमति दें, पर UI में मिलान मिलने पर एक नरम वार्निंग दिखाएँ।

यदि आपको कई ईमेल या फ़ोन नंबर चाहिए, तो email_2 या phone_3 जैसे कॉलम न जोड़ें। इसके बजाय एक अलग टेबल का उपयोग करें (उदाहरण के लिए, ContactMethod जिसमें type, value, is_primary)। रिपोर्टिंग साफ़ रहती है और मॉडल स्वाभाविक रूप से स्केल होता है।

उदाहरण: आपकी टीम Pat से मिलती है, जो क्वार्टर के बीच नौकरी बदल देता है। Contact को Organization से जोड़कर आप Pat को नई कंपनी में मूव कर सकते हैं, पुराने contact methods को हिस्ट्री के लिए रख सकते हैं, और आपकी रिपोर्ट्स अभी भी कंपनी के अनुसार डील्स गिनती सही दिखाएंगी।

Deals और पाइपलाइन्स: ऐसा स्ट्रक्चर जो पढ़ने में आसान रहे

एक डील आपका forecasting यूनिट है: एक संभावित खरीद जो एक स्पष्ट अगले कदम के साथ हो। डील रिकॉर्ड छोटा रखें, और सब कुछ को रेफरेंस करें।

शुरू करें उन फ़ील्ड्स के साथ जिन्हें आप टीम के किसी भी सदस्य को समझा सकें:\n

• Deal name: एक छोटा लेबल जो सूची में समझ आए\n- Stage: पाइपलाइन स्टेज का रेफरेंस (हाथ से टाइप न करें)\n- Value: अनुमानित राशि (और पूरे सिस्टम के लिए एक ही मुद्रा चुनें)\n- Owner: आगे बढ़ने के लिए ज़िम्मेदार व्यक्ति\n- Close date: बंद होने की सबसे अच्छी वर्तमान अनुमानित तारीख

रिश्तों के लिए, डील पर एक प्राथमिक संपर्क चुनें। इससे रिपोर्टिंग सीधी रहती है (उदाहरण के लिए, contact के अनुसार रेवेन्यू, सेगमेंट के अनुसार विन रेट)। यदि कभी आपको अधिक लोगों को शामिल करने की ज़रूरत पड़े, तो deal_contacts टेबल जोड़ें ताकि आप अतिरिक्त contacts अटैच कर सकें बिना हर डील को जटिल many-to-many में बदलने के। अधिकांश छोटी टीमें 1 प्राथमिक संपर्क और वैकल्पिक प्रतिभागियों के साथ ठीक रहती हैं।

स्टेज़ वे जगह हैं जहाँ CRMs अक्सर गंदे हो जाते हैं। स्टेज को free text में न रखें। स्टेजेज़ को रेफरेंस डेटा के रूप में स्टोर करें ताकि आप बाद में स्टेज का नाम बदल सकें बिना रिपोर्ट्स को तोड़े। एक न्यूनतम stage टेबल में हो सकता है:\n

• stage_id\n- pipeline_id\n- stage_name\n- stage_order\n- is_closed (या अलग फ्लैग्स won और lost के लिए)\n यदि आपकी टीम छोटी है, तो रिकॉर्ड्स को "lead" और "deal" में बाँटना तब तक टालें जब तक आप वास्तव में लीड्स को अलग तरह से मैनेज न करते हों। एक सरल नियम काम करता है: जब आपके पास ट्रैक करने के लायक वास्तविक अवसर हो, तब वह डील है। उससे पहले, इसे एक contact के रूप में रखें जिसमें स्थिति जैसी "new" या "nurture" हो। इससे पाइपलाइन पठनीय रहती है और आधी बनी डील्स आपके नंबरों को प्रदूषित नहीं करतीं।

उदाहरण: दो-व्यक्ति की सेल्स टीम "Acme Renewal" को Sam द्वारा ओन्ड एक डील के रूप में ट्रैक करती है, स्टेज "Proposal Sent", वैल्यू 12,000, क्लोज़ डेट अगले महीने। प्राथमिक संपर्क बायर है, और दूसरा संपर्क एक फ़ाइनेंस अप्रूवर के रूप में जोड़ा गया है। चूंकि स्टेज नाम और ऑर्डर फिक्स्ड हैं, रिपोर्ट्स निरंतर रहती हैं।

Activities: tasks, meetings, और notes के लिए एक मॉडल

एक छोटी टीम को calls, emails, meetings, और notes के अलग-अलग टेबल्स की ज़रूरत नहीं होती। एक Activity मॉडल आम तौर पर पर्याप्त होता है, और यह CRM को उपयोग में आसान और रिपोर्टिंग में आसान बनाता है।

एकल Activity टेबल

जो कुछ भी हुआ (या होना चाहिए) उसके लिए एक रिकॉर्ड का उपयोग करें। इसे एक सरल type फ़ील्ड दें जिसमें छोटा फिक्स्ड सेट हो, जैसे: call, email, meeting, note, task। सूची छोटी रखें ताकि लोग हर बार एक ही शब्द चुनें।

Activities को बिना भ्रम के लिंक करने के लिए स्पष्ट नियम रखें:\n

• यदि यह किसी व्यक्ति के बारे में है (follow-up call, intro email), तो इसे एक contact से लिंक करें।\n- यदि यह रेवेन्यू को मूव करने के बारे में है (pricing call, negotiation meeting), तो इसे एक deal से लिंक करें।\n- यदि यह सचमुच दोनों को शामिल करता है, तो दोनों से लिंक करें, पर पाइपलाइन रिपोर्टिंग के लिए deal को प्राथमिक मानें।

व्यवहार में, Activity में contact_id (nullable) और deal_id (nullable) हो सकता है, साथ ही एक वैकल्पिक owner_id (किसका जिम्मा है) भी।

रिपोर्टिंग-हितैषी टाइमस्टैम्प्स

दोनों due_at और completed_at रखें। ये अलग प्रश्नों का उत्तर देते हैं। due_at बताता है कि क्या होना चाहिए था (योजना और वर्कलोड)। completed_at बताता है कि असल में क्या हुआ (निष्पादन और चक्र-समय)।

आप अलग फ़ील्ड के बिना भी स्टेटस निकाल सकते हैं: अगर completed_at सेट है, तो यह पूरा हुआ है। अगर नहीं, तो यह खुला है। इससे अतिरिक्त स्टेटस मान जो समय के साथ अलग हो सकते हैं, की ज़रूरत नहीं रहती।

एक खोजने योग्य फ़ील्ड जैसे summary या body में activity टेक्स्ट रखें। शुरू में नोट्स को ज़्यादा संरचित करने से बचें। उदाहरण: “Call with Maya: confirmed budget, send proposal Friday.” बाद में केवल तभी विशेष फ़ील्ड जोड़ें जब आपको असली दर्द महसूस हो।

Ownership और visibility: व्यावहारिक रखें

Ownership वह होता है जो अगले कदम के लिए ज़िम्मेदार है। हल्के CRM स्कीमा में, यह आमतौर पर एक फ़ील्ड जैसे owner_user_id में डील पर (और अक्सर contacts पर भी) होता है।

“owner” के दो अर्थ अक्सर मिश्रित हो जाते हैं: user assignment (एक विशिष्ट व्यक्ति) और team assignment (एक समूह)। यदि आप शुरुआत से ही सब कुछ team-owned करने की कोशिश करते हैं, तो आज किसे काम करना चाहिए यह अस्पष्ट हो जाता है।

एक डिफ़ॉल्ट जो अधिकांश छोटी टीमों के लिए काम करता है: सब कुछ हर किसी के लिए दिखाई देता है, पर हर डील का ठीक एक owner होता है। सहयोग आसान रहता है, और जब किसी को कवर करना हो तो परमिशन एज़ केस नहीं बनते।

जब आपको सख्त visibility चाहिए, तो इसे एक सिंगल स्विच के रूप में रखें, ना कि जटिल मैट्रिक्स। उदाहरण के लिए, deals और activities पर visibility फ़ील्ड जोड़ें जिसमें public और private मान हों, जहाँ private का अर्थ है “केवल owner (और admins) देख सकते हैं।”

आपको केवल तब teams या territories चाहिए जब इनमें से कोई सच हो:\n

• आपके पास अलग-अलग समूह हैं जो एक-दूसरे के डील नहीं देखना चाहिए।\n- आप टीम द्वारा प्रदर्शन रिपोर्ट करते हैं और लोग टीमों के बीच बदलते हैं।\n- मैनेजरों को अपने समूह तक पहुँच चाहिए, पर पूरे कंपनी तक नहीं।\n- आप लीड्स को साझा क्यू में असाइन करते हैं इससे पहले कि कोई रेप उन्हें क्लेम करे।

Ownership रिपोर्टिंग को प्रभावित करता है। यदि आप साफ़ “by rep” नंबर चाहते हैं, तो डील पर वर्तमान owner_user_id के अनुसार रिपोर्ट करें। यदि आप “by team” रोलअप भी चाहते हैं, तो owner_team_id जोड़ें (या मालिक की प्रोफ़ाइल से निकाले), पर स्पष्ट रहें कि स्रोत ऑफ़ ट्रुथ कौन सा है।

उदाहरण: दो रेप्स एक इनबॉक्स साझा करते हैं। एक नया डील अनअसाइंड्ड शुरू होता है owner_user_id = null और owner_team_id = Sales के साथ। जैसे ही Alex उसे लेता है, owner_user_id = Alex सेट करें (टीम को Sales ही रखें)। आपकी पाइपलाइन पठनीय रहती है और टीम टोटल्स भी काम करते हैं।

Permissions डिज़ाइन: पर्याप्त नियंत्रण, बिना जटिलता के

सरल RBAC से शुरू करें

परमिशन्स तब सबसे अच्छा काम करते हैं जब आप तीन विचार अलग रखें: roles (कौन), resources (क्या), और actions (क्या कर सकते हैं)। यह role-based access control (RBAC) है, और टीम बढ़ने पर भी यह समझने में आसान रहता है।

resources को अपने कोर ऑब्जेक्ट्स के पास रखें: Contacts, Organizations, Deals, Activities, और शायद Pipelines (यदि स्टेजेज़ एडिटेबल हों)। उन पर एक छोटा, सुसंगत action सेट परिभाषित करें: view, create, edit, delete, export।

Export को अलग रखना अच्छा है। कई टीमें व्यापक viewing अधिकारों से ठीक रहती हैं, पर bulk data निकालने को सीमित रखना चाहती हैं।

ऑब्जेक्ट-लेवल परमिशन्स शुरू करने के लिए सबसे आसान जगह हैं: “क्या यह रोल डील्स को संपादित कर सकता है?” अधिकांश छोटी टीमों के लिए यही महीनों तक काफी होता है। रिकॉर्ड-लेवल नियम (प्रति contact या प्रति deal) वही जगह है जहाँ जटिलता आती है, इसलिए केवल वास्तविक ज़रूरत होने पर ही जोड़ें।

एक व्यावहारिक पहला कदम एक ownership नियम है: हर रिकॉर्ड की owner_user_id होती है, और non-admins केवल वही एडिट कर सकते हैं जो उनके हैं। यदि आपको एक और परत चाहिए, तो team_id जोड़ें और टीम-व्यापी viewing की अनुमति दें जबकि edits owner-only रखें।

रिकॉर्ड-लेवल नियम केवल जब वास्तव में ज़रूरी हों

रिकॉर्ड-लेवल परमिशन्स उन मामलों के लिए जोड़ें जैसे:\n

• सेल्स रेप्स को एक-दूसरे के डील नहीं दिखने चाहिए\n- सपोर्ट डील्स को देख सकते हैं पर संपादित नहीं कर सकते\n- मैनेजर सभी देख सकते हैं और owners reasssign कर सकते हैं

ऑडिट जरूरतों को हल्का पर वास्तविक रखें। प्रत्येक मुख्य तालिका में created_at, created_by, updated_at, और updated_by जोड़ें। यदि आगे गहरी हिस्ट्री चाहिए, तो एक छोटा audit_log टेबल जोड़ें जिसमें: object type, record id, action, who, when, और बदले हुए फ़ील्ड्स का छोटा JSON हो।

चरण-दर-चरण: एक वीकेंड में स्कीमा बनाएं

इसे सही करने का सबसे आसान तरीका है कि आप इसे एक छोटे प्रोडक्ट की तरह ट्रीट करें: पहले डेटा परिभाषित करें, असली एंट्रीज़ से यह साबित करें, फिर स्क्रीन बनाएं।

दिन 1: डेटा मॉडल लॉक करें

कागज़ या whiteboard पर एक त्वरित ERD स्केच से शुरू करें। तालिकाओं की संख्या कम रखें, पर लिंक स्पष्ट रखें: contact एक organization से संबंधित है (ऑप्शनल), deal एक पाइपलाइन से संबंधित है और उसका एक owner है, activity contact और/या deal से संबंधित हो सकती है।

फिर बेसिक्स करें:\n

• ऑब्जेक्ट्स और रिश्ते परिभाषित करें: contacts, organizations, deals, activities, users/roles, और यदि जरूरत हो तो छोटे lookup टेबल्स।\n- आवश्यक फ़ील्ड्स और defaults परिभाषित करें: created_at, owner_id, और key names required रखें; stage और currency के लिए defaults सेट करें यदि आप amounts उपयोग करते हैं।\n- enums या lookup टेबल्स परिभाषित करें: deal stages और activity types ताकि रिपोर्टिंग संगत रहे।\n- सामान्य फ़िल्टर्स के लिए इंडेक्स जोड़ें: owner_id, stage, due_at, created_at, और वे foreign keys जिन्हें आप रोज़ाना फ़िल्टर करते हैं।\n- 20 असली रिकॉर्ड्स के साथ टेस्ट करें: असली नाम, तारीख़ें, और गंदे नोट्स का उपयोग करें ताकि देखें क्या टूटता है।

दिन 2: रिपोर्टिंग को साफ़ साबित करें

फॉर्म्स बनाने से पहले, उन 6-8 सवालों को लिखें जो आपकी टीम हर हफ्ते पूछती है। उदाहरण: “Deals in Negotiation by owner”, “Overdue activities”, “New contacts this month”, “Won revenue by month”。अगर कोई सवाल जटिल joins या खास केस मांगता है, तो स्कीमा अभी ठीक करें।

एक सरल टेस्ट परिदृश्य मदद करता है: एक कंपनी में 3 contacts जोड़ें, अलग स्टेज में 2 deals, और उनके बीच 6 activities (एक call, एक meeting, दो tasks, और दो notes)। फिर देखें कि क्या आप बिना अनुमान लगाए पता लगा सकते हैं कि किसका मालिक कौन है, अगला कदम क्या है, और आख़िरी हफ़्ते में क्या बदला।

जब डेटा ठोस हो जाए, तो UI और ऑटोमेशन बाद में बनाएं। आप तेज़ी से आगे बढ़ेंगे और रिपोर्ट्स को वास्तविकता से मैच कराने के लिए इतिहास को फिर से लिखने की ज़रूरत नहीं पड़ेगी।

आम गलतियाँ जो रिपोर्टिंग को गंदा कर देती हैं

गंदा रिपोर्टिंग अक्सर उन “quick fixes” से शुरू होती है जो आज तेज़ लगते हैं पर हर हफ्ते आपको महँगा पड़ते हैं। एक हल्का CRM स्कीमा तब बेहतर काम करता है जब आपके डेटा के आकार साफ़ हों और टीम कुछ नियम सचमुच अपनाए।

एक सामान्य जाल सब कुछ एक "customer" तालिका में ज़बरदस्ती भरना है। यह सरल लगता है जब तक आप बुनियादी सवालों का उत्तर नहीं ढूँढ़ते जैसे “कितने डील्स एक कंपनी से जुड़े हैं?” या “किस व्यक्ति ने नौकरी बदली?” लोगों (contacts) और कंपनियों (organizations) को अलग रखें और उन्हें जोड़ें।

एक और रिपोर्टिंग किलर डील स्टेजेज़ को free text रखना है। अगर कोई "Negotiation" टाइप करे और दूसरा "negotiating", तो आपकी पाइपलाइन चार्ट पहले ही गलत हो चुकी है। स्टेजेज़ की फिक्स्ड लिस्ट (या स्टेज टेबल) उपयोग करें ताकि हर डील एक ही सेट को पॉइंट करे।

एक फ़ील्ड में कई मान पैक करना भी दर्दनाक है। कॉमा-सेपरेटेड ईमेल्स या फ़ोन नंबर सर्च, डेडुपिंग, और एक्सपोर्ट को मुश्किल बनाते हैं। यदि आपको वास्तव में कई मान चाहिए, तो उन्हें अलग पंक्तियों में स्टोर करें (उदाहरण: एक चाइल्ड टेबल में प्रति रिकॉर्ड एक ईमेल)।

Activities तब गंदी हो जाती हैं जब तारीख़ें अस्पष्ट हों। एक एकल “date” फ़ील्ड यह नहीं बता सकता कि कोई task last Friday due था या last Friday complete हुआ था। इन कॉन्सेप्ट्स को अलग रखें ताकि आप overdue और completed वर्क दोनों पर सही रिपोर्ट कर सकें।

यहाँ एक छोटा "भविष्य की बचत" चेकलिस्ट है:\n

• Contacts और organizations अलग करें, फिर उन्हें लिंक करें\n- स्टेज IDs का उपयोग करें, टाइप किए गए स्टेज नामों का नहीं\n- प्रत्येक फ़ील्ड में एक ही मान रखें; multiples के लिए चाइल्ड टेबल उपयोग करें\n- due_at और completed_at अलग फ़ील्ड बनाकर रखें\n- सरल रोल्स से शुरू करें; रिकॉर्ड-लेवल नियम केवल वास्तविक वर्कफ़्लो दिखने पर जोड़ें

उदाहरण: यदि आपकी टीम कॉल्स को नोट्स के रूप में लॉग करती है और बाद में उन्हें उसी फ़ील्ड को एडिट करके "done" मार्क कर देती है, तो आप यह रिपोर्ट नहीं बना पाएंगे कि follow-ups में कितना समय लगा। अलग फ़ील्ड्स के साथ वह रिपोर्ट सीधी बन जाती है।

स्कीमा पर कमिट करने से पहले त्वरित चेकलिस्ट

स्क्रीन, ऑटोमेशन और डैशबोर्ड बनाने से पहले एक त्वरित रिपोर्टिंग और नियम पास करें। हल्का CRM स्कीमा तभी हल्का रहता है जब आप सामान्य सवालों का जवाब कस्टम हैक्स या वन-ऑफ फ़ील्ड्स के बिना दे सकें।

इन चेक्स को असली सैंपल डेटा के साथ चलाएँ (20 contacts और 10 deals भी काफी हैं)। अगर आप फंसते हैं, तो आमतौर पर इसका मतलब है कि कोई फ़ील्ड गायब है, picklist असंगत है, या रिश्ता बहुत ढीला है।

वे 5 चेक्स जो अधिकांश समस्याओं को पकड़ लेते हैं

• रिपोर्टिंग बेसिक्स: क्या आप बिना उलझन के डील्स को स्टेज, owner, और close month के अनुसार ग्रुप कर सकते हैं?\n- वर्क मैनेजमेंट: क्या आप एक रिपोर्ट में “overdue activities by owner” खींच सकते हैं, जहाँ overdue एक ही due date और एक स्पष्ट done status पर आधारित हो?\n- Contact to organization: क्या एक contact बिना organization के अस्तित्व में रह सकता है, और क्या उन्हें बाद में लिंक किया जा सकता है बिना हिस्ट्री (emails, notes, deal participation) तोड़े?\n- सुसंगतता: क्या stages और activity types एक फिक्स्ड लिस्ट से आते हैं, ताकि आपके पास "Follow up", "Follow-up", और "Followup" तीन अलग मान न हों?\n- सुरक्षा: क्या आप सीमित कर सकते हैं कि कौन रिकॉर्ड्स delete या export करे, बिना सामान्य अपडेट्स (जैसे डील को अगले स्टेज में ले जाना) को ब्लॉक किए?

यदि आप इन पाँचों का जवाब "हाँ" दे सकते हैं, तो आप एक अच्छी स्थिति में हैं। यदि नहीं, तो स्कीमा छोटा रहते हुए ही अभी ठीक करें।

एक व्यावहारिक टिप: स्टेजेज़ और activity types को एक बार परिभाषित करें (टेबल या enum के रूप में) और हर जगह पुन: उपयोग करें ताकि हर स्क्रीन और प्रोसेस वही मान उपयोग करे।

एक वास्तविक छोटी-टीम उदाहरण और अगले कदम

एक 5-व्यक्ति एजेंसी हल्के CRM स्कीमा के लिए अच्छा परीक्षण है। टीम व्यस्त है, लीड्स हर जगह से आते हैं, और कोई डेटा की निगरानी नहीं करना चाहता। कल्पना करें: 1 admin, 2 sales, 1 ops lead, और 1 read-only साथी (founder जो केवल नंबर देखता है)।

एक नया inbound request आता है (web form या email): “Need a website refresh, budget $15k, timeline 6 weeks.” नियम सरल है: एक organization बनाएं (यदि यह कंपनी है) और एक contact बनाएं (व्यक्ति)। फिर उस organization से जुड़ा एक deal बनाएं, जिसपर contact प्राथमिक संपर्क हो।

इसे तेज़ रखने के लिए वे एक छोटा intake checklist उपयोग करते हैं:\n

• यदि domain या company name मौजूदा organization से मेल खाता है, तो उसे reuse करें।\n- यदि व्यक्ति का email मौजूद है, तो उस contact को reuse करें।\n- वास्तविक खरीद इरादा होने पर हमेशा एक deal बनाएं।\n- मूल संदेश को डील डिस्क्रिप्शन में रखें।\n- स्रोत (referral, form, outbound) को एक फ़ील्ड में रखें।

Activities मिस कॉल्स को रोकते हैं क्योंकि हर अगले कदम को एक तिथि वाला आइटम बनकर किसी व्यक्ति का मालिकाना मिलता है। जब sales में discovery कॉल होती है, वे एक activity को meeting के रूप में लॉग करते हैं और तुरंत अगला कदम भी जोड़ देते हैं: दो दिनों बाद एक कॉल। यदि ops को काम के स्कोप के लिए विवरण चाहिए, वे उसी डील पर एक task activity बनाते हैं ताकि यह एक ही जगह दिखे।

रोल्स व्यावहारिक रहते हैं: Admin सब कुछ एडिट कर सकता है और सेटिंग्स मैनेज कर सकता है, Sales contacts, deals और उनकी activities बना और अपडेट कर सकते हैं, Ops delivery-संबंधी फ़ील्ड्स और activities अपडेट कर सकता है, और Read-only पाइपलाइन और रिपोर्ट देख सकता है बिना डेटा बदले।

यदि आप इसे जल्दी से एक काम करने वाले आंतरिक टूल में बदलना चाहते हैं, तो AppMaster (appmaster.io) एक सीधे साधे विकल्प है: आप इसका उपयोग करके Data Designer (PostgreSQL) में स्कीमा मॉडल कर सकते हैं, Business Process editor में वर्कफ़्लो नियम जोड़ सकते हैं, एक साधारण lead inbox और deal पेज बना सकते हैं, और फिर जब टीम तैयार हो तो AppMaster Cloud या अपनी क्लाउड पर डिप्लॉय कर सकते हैं।