മിക്ക CRM ചാറ്റ്ബോട്ടുകളും വിലകൂടിയ കാൽക്കുലേറ്ററുകൾ മാത്രമാണ്. പൈപ്പ്ലൈൻ മൂല്യത്തെക്കുറിച്ച് (pipeline value) ചോദിച്ചാൽ, ഒരു റിപ്പോർട്ടിൽ നിന്ന് നേരിട്ട് എടുത്ത ഒരു സംഖ്യ അവർ നൽകുന്നു. ആ സംഖ്യ എന്തുകൊണ്ട് മാറിയെന്ന് ചോദിച്ചാൽ, സംഭാഷണം അവിടെ അവസാനിക്കുന്നു. ഡാറ്റയും യഥാർത്ഥ ധാരണയും തമ്മിലുള്ള ആ വിടവിലാണ് ഇടപാടുകൾ നഷ്ടപ്പെടുന്നത്, വരുമാനവും ശ്രദ്ധിക്കപ്പെടാതെ ഇല്ലാതാകുന്നു.
യഥാർത്ഥ പ്രവർത്തന മൂല്യം വരുന്നത് സന്ദർഭത്തിൽ (context) നിന്നാണ്. ക്ലോസ് റേറ്റ്സ് (close rates) എന്തുകൊണ്ട് മാറിയെന്നും, ഈ പ്രവണത തുടർന്നാൽ എന്ത് സംഭവിക്കുമെന്നും, ഏത് മാറ്റമാണ് ഇതിന് കാരണമായതെന്നും നിങ്ങൾ അറിയേണ്ടതുണ്ട്. Zoho CRM ചാറ്റ്ബോട്ടിൽ ഇത്തരമൊരു ബുദ്ധിശക്തി നിർമ്മിക്കുന്നത് സയൻസ് ഫിക്ഷൻ അല്ല. ഇതിന് വൃത്തിയുള്ള ഒരു ഡാറ്റാ പൈപ്പ്ലൈൻ, കൃത്യമായ ഒരു സെമാന്റിക് ലെയർ (semantic layer), കാരണങ്ങളിലേക്ക് തിരിഞ്ഞുനോക്കാൻ കഴിയുന്ന രീതിയിലുള്ള ഒരു ആർക്കിടെക്ചർ എന്നിവ ആവശ്യമാണ്.
യഥാർത്ഥ പ്രശ്നം ഡാറ്റയല്ല, സന്ദർഭമാണ് (Context)
സെയിൽസ് ടീമുകൾ ഇതിനകം തന്നെ ഡാഷ്ബോർഡുകളിൽ മുങ്ങിയിരിക്കുകയാണ്. എല്ലാ CRM-കളും ഡസൻ കണക്കിന് ബാർ ചാർട്ടുകളും ഫണൽ വ്യൂകളും നിർമ്മിക്കുന്നു. എന്നാൽ ഒരു സംഖ്യ മാത്രം വെറുമൊരു വിവരമാണ്. ക്ലോസ് റേറ്റ്സിൽ 15 ശതമാനം കുറവുണ്ടായി എന്നത് എന്തോ സംഭവിച്ചു എന്ന് സൂചിപ്പിക്കുന്നുണ്ടെങ്കിലും, അത് എന്തുതന്നെയാണെന്ന് പറയുന്നില്ല. ഒരു SDR ടീം അവരുടെ ക്വാളിഫിക്കേഷൻ സ്ക്രിപ്റ്റ് മാറ്റിയിട്ടുണ്ടോ, പെയ്ഡ് ട്രാഫിക് സ്രോതസ്സ് അയോഗ്യരായ സന്ദർശകരെയാണ് എത്തിച്ചിരിക്കുന്നതോ, അതോ ഒരു എതിരാളി മാസത്തിന്റെ തുടക്കത്തിൽ ആക്രമണാത്മകമായ വിലയിടൽ ആരംഭിച്ചോ എന്ന് അത് വ്യക്തമാക്കുന്നില്ല.
ഒരു സ്മാർട്ട് സിസ്റ്റം ചോദ്യത്തിന് പിന്നിലെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. അത് ഒരു CRM-നെ വെറുമൊരു സ്റ്റാറ്റിക് ഡാറ്റാബേസ് ആയിട്ടല്ല, മറിച്ച് ഒരു സജീവ സിഗ്നൽ സ്ട്രീം ആയിട്ടാണ് കാണുന്നത്. ശരിയായി നിർമ്മിച്ചാൽ, ചാറ്റ്ബോട്ട് അനോമലി (anomaly) കണ്ടെത്തുകയും, മൂലകാരണങ്ങൾ പരിശോധിക്കുകയും, ഡാറ്റാ റോകൾക്ക് പകരം ബിസിനസ് ഔട്ട്കമുകളെക്കുറിച്ച് സംസാരിക്കുകയും ചെയ്യുന്ന ഒരു അനലിറ്റിക്കൽ പാർട്ണറായി മാറും.
Zoho-യുടെ API-യുമായി പോരാടുന്നത് നിർത്തുക
നിങ്ങൾക്ക് എന്തെങ്കിലും വിശകലനം ചെയ്യുന്നതിന് മുമ്പ്, Zoho-യിൽ നിന്ന് ഡാറ്റ വൃത്തിയായി പുറത്തേക്ക് മാറ്റണം. ഓരോ സ്റ്റാൻഡേർഡ്, കസ്റ്റം ഒബ്ജക്റ്റുകൾക്കും പ്രത്യേക സിങ്ക് സ്ക്രിപ്റ്റുകൾ എഴുതാനുള്ള ആഗ്രഹം നിയന്ത്രിക്കുക. Zoho-യുടെ API പേജിനേഷൻ (pagination), റേറ്റ് ലിമിറ്റുകൾ, OAuth ടോക്കൺ മാനേജ്മെന്റ് എന്നിവ കർശനമായി പാലിക്കുന്നുണ്ട്. നിങ്ങളുടെ CRM-ലെ ഓരോ ചെറിയ സ്കീമ മാറ്റവും മെയിന്റനൻസ് തലവേദനയായി മാറുകയും, എൻജിനീയറിങ് സമയം യഥാർത്ഥ ഉൽപ്പന്ന ജോലികളിൽ നിന്ന് മാറ്റിവയ്ക്കേണ്ടി വരികയും ചെയ്യും.
പകരം Airbyte ഉപയോഗിക്കുക. ഇതിൽ Zoho CRM കണക്റ്റർ ഉണ്ട്, അത് സങ്കീർണ്ണമായ കാര്യങ്ങൾ നിങ്ങൾക്കായി കൈകാര്യം ചെയ്യുന്നു. ഇത് മോഡിഫൈഡ് ടൈംസ്റ്റാമ്പുകൾ ഉപയോഗിച്ച് ഇൻക്രിമെന്റലായി സിങ്ക് ചെയ്യുന്നു, അതിനാൽ ഓരോ മണിക്കൂറിലും മുഴുവൻ ടേബിളുകളും വലിച്ചെടുക്കേണ്ടി വരുന്നില്ല. ഇത് സ്കീമകളെ സ്വയമേവ നോർമലൈസ് ചെയ്യുന്നു, Lead_Source_Detail അല്ലെങ്കിൽ Qualification_Score പോലുള്ള കസ്റ്റം ഫീൽഡുകൾ ചേർക്കുന്ന നിമിഷം ഇത് വളരെ പ്രധാനമാണ്. ആ ഫീൽഡുകളിൽ മാറ്റം വരുമ്പോൾ, എക്സ്ട്രാക്ഷൻ ലോജിക് വീണ്ടും എഴുതേണ്ടി വരാതെ തന്നെ Airbyte അതിനനുസരിച്ച് മാറുന്നു. കൂടാതെ, ഇത് ഡാറ്റ നേരിട്ട് Postgres, Snowflake, അല്ലെങ്കിൽ BigQuery എന്നിവയിലേക്ക് എത്തിക്കുന്നു; ഇത് പാതിരാത്രിയിൽ തകരാറിലാകാൻ സാധ്യതയുള്ള ഇടനില ഫയലുകളെ ഒഴിവാക്കുന്നു.
ആ വിശ്വാസ്യത പ്രധാനമാണ്, കാരണം നിങ്ങളുടെ സ്റ്റാക്കിന്റെ അടുത്ത പാളികൾ ഡാറ്റയുടെ പുതുമയെ (freshness) ആശ്രയിച്ചിരിക്കുന്നു. ഡാറ്റ ശേഖരണത്തിൽ റെക്കോർഡുകൾ വിട്ടുപോവുകയോ ഡ്യൂപ്ലിക്കേറ്റ് ആകുകയോ ചെയ്താൽ, നിങ്ങളുടെ അനോമലി ഡിറ്റക്ഷൻ തെറ്റായ സൂചനകൾ നൽകുകയും കാസ്വൽ അനാലിസിസ് (causal analysis) തെറ്റായ കാരണങ്ങൾ ചൂണ്ടിക്കാണിക്കുകയും ചെയ്യും.
ആറ് പാളികൾ, ഒരൊറ്റ വ്യക്തമായ ശബ്ദം
ഓരോ ഘടകവും അതിന്റെ ജോലി കൃത്യമായി ചെയ്യുന്ന രീതിയിൽ നിങ്ങളുടെ ആർക്കിടെക്ചർ പാളികളായി (layered) സൂക്ഷിക്കുക. ഈ വേർതിരിക്കൽ സിസ്റ്റം ഡിബഗ് ചെയ്യുന്നത് എളുപ്പമാക്കുന്നു, വികസിപ്പിക്കുന്നത് ചെലവ് കുറയ്ക്കുന്നു, കൂടാതെ സെയിൽസ് ലീഡർഷിപ്പ് ചാറ്റ്ബോട്ട് എങ്ങനെ ഒരു ഉത്തരത്തിൽ എത്തിച്ചേർന്നു എന്ന് ചോദിക്കുമ്പോൾ കൂടുതൽ വിശ്വാസ്യത നൽകുന്നു.
1. Data Ingestion
Airbyte നിശ്ചിത സമയക്രമത്തിൽ Leads, Deals, Contacts, Activities എന്നിവ ശേഖരിക്കുന്നു. ഈ നാല് ഒബ്ജക്റ്റുകളാണ് മിക്ക സെയിൽസ് പ്രവർത്തനങ്ങളുടെയും ജീവനാഡി. ഡാറ്റാ എക്സ്ട്രാക്ഷൻ ലളിതവും പ്രവചിക്കാവുന്നതുമായി നിലനിർത്തുക.
2. Data Warehouse
ആദ്യം റോ ഡാറ്റ (raw data) ഒരു സ്റ്റേജിംഗ് ഏരിയയിലേക്ക് ലോഡ് ചെയ്യുക. അനലിസ്റ്റുകളോ അൽഗോരിതങ്ങളോ നേരിട്ട് Zoho-യുടെ പ്രൊഡക്ഷൻ API ക്വറി ചെയ്യുന്നത് ഒഴിവാക്കുക. സ്കീമകളിൽ മാറ്റം വരുമ്പോൾ ഒരു റിക്കവറി പോയിന്റ് നൽകാനും, നിങ്ങളുടെ CRM-നെ ബാധിക്കാതെ ചരിത്രപരമായ ഡാറ്റ വീണ്ടും പ്രോസസ്സ് ചെയ്യാനും ഒരു സ്റ്റേജിംഗ് ലെയർ സഹായിക്കുന്നു.
3. Semantic Layer
ബിസിനസ് പദങ്ങളുടെ യഥാർത്ഥ അർത്ഥം നിങ്ങൾ നിർവചിക്കുന്നത് ഇവിടെയാണ്. ഒരു "won deal" എന്നാൽ Closed Won എന്ന സ്റ്റേജുള്ള, 100 ശതമാനം പ്രോബബിലിറ്റിയുള്ള, കഴിഞ്ഞ 90 ദിവസത്തിനുള്ളിൽ നടന്ന ഒരു അവസരം ആകാം. ഒരു "stalled lead" എന്നാൽ 14 ദിവസമായി ലോഗ് ചെയ്ത ആക്റ്റിവിറ്റി ഇല്ലാത്ത ഒന്നാകാം. ചാറ്റ്ബോട്ട് പിന്നീട് ഒരു റീജിയണൽ മാനേജരോട് സ്റ്റാൾഡ് ലീഡുകൾ വർദ്ധിച്ചുവെന്ന് പറയുമ്പോൾ, ക്വാർട്ടർലി ബോർഡ് റിപ്പോർട്ടിൽ കാണുന്ന അതേ നിർവചനം തന്നെ അത് ഉപയോഗിക്കണം. ഈ ലെയർ ഇല്ലെങ്കിൽ, ഡാഷ്ബോർഡ് 42 ക്ലോസ്ഡ് ഡീലുകൾ കാണിക്കുമ്പോൾ ബോട്ട് 38 ആണെന്ന് വാദിക്കുന്ന അവസ്ഥ നേരിടേണ്ടി വരും.
4. Anomaly Detection
വ്യക്തമായ വ്യതിയാനങ്ങൾ (outliers) കണ്ടെത്താൻ സ്റ്റാറ്റിസ്റ്റിക്കൽ മോഡലുകൾ ഉപയോഗിക്കുക; ഉദാഹരണത്തിന്, സാധാരണ ആക്റ്റിവിറ്റി കാണുന്ന ഞായറാഴ്ചകളിൽ ഡീൽ ക്രിയേഷൻ പൂജ്യമായി കുറയുകയോ, അല്ലെങ്കിൽ ഒരു വലിയ എന്റർപ്രൈസ് ഡീൽ കാരണം പൈപ്പ്ലൈൻ മൂല്യം പെട്ടെന്ന് ഉയരുകയോ ചെയ്യുന്നത് കണ്ടെത്താം. മാസത്തിലുടനീളം ക്ലോസ് റേറ്റ്സ് ആഴ്ചയിൽ രണ്ട് ശതമാനം വീതം കുറയുന്നത് പോലുള്ള സൂക്ഷ്മമായ മാറ്റങ്ങൾ കണ്ടെത്താൻ ലൈറ്റ് വെയ്റ്റ് ML ഉപയോഗിക്കുക. നിങ്ങൾക്ക് ഈ രണ്ട് രീതികളും ആവശ്യമാണ്. ഒരു വലിയ തീപിടുത്തം കണ്ടെത്താൻ ശക്തമായ ഉപകരണം വേണം, എന്നാൽ പുക കണ്ടെത്താൻ കൂടുതൽ സെൻസിറ്റീവ് ആയ ഉപകരണം വേണം.
5. Causal Analysis
ഈ ലെയർ "എന്തുകൊണ്ട്" എന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. ഒരു മെട്രിക് ഡിപെൻഡൻസി ഗ്രാഫ് (metric dependency graph) നിർമ്മിക്കുക. വരുമാനം (Revenue), ക്ലോസ് റേറ്റ് (close rate), പൈപ്പ്ലൈൻ വോളിയം (pipeline volume) എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു. ക്ലോസ് റേറ്റ്, ലീഡ് ക്വാളിറ്റി (lead quality), റെപ് പെർഫോമൻസ് (rep performance) എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു. ലീഡ് ക്വാളിറ്റി, ട്രാഫിക് ചാനൽ (traffic channel), ക്വാളിഫിക്കേഷൻ മാനദണ്ഡങ്ങൾ (qualification criteria) എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു ഡൗൺസ്ട്രീം മെട്രിക് (downstream metric) പരാജയപ്പെടുമ്പോൾ, സിസ്റ്റം ഗ്രാഫിലൂടെ അപ്സ്ട്രീമിലേക്ക് (upstream) സഞ്ചരിക്കുന്നു. കോറിലേഷൻ ശക്തിയും (correlation strength) സമയക്രമവും (timing proximity) അടിസ്ഥാനമാക്കി ഇത് സാധ്യമായ കാരണങ്ങളെ ക്രമീകരിക്കുന്നു. ഇത്തരത്തിലാണ് ഒരു പ്രശ്നം വെളിപ്പെടുത്തുന്നതിൽ നിന്ന് അതിന്റെ യഥാർത്ഥ കാരണം കണ്ടെത്തുന്നതിലേക്ക് ബോട്ട് മാറുന്നത്.
6. Chat Interface
Retrieval-Augmented Generation (RAG) ഉപയോഗിച്ച് ഒരു LLM വഴി കണ്ടെത്തലുകൾ അവതരിപ്പിക്കുക. പ്രധാനപ്പെട്ട കാര്യം, LLM നിങ്ങളുടെ സെമാന്റിക് ലെയറിനെ (semantic layer) മാത്രമേ ക്വറി ചെയ്യാവൂ, ഒരിക്കലും റ〉(raw) വെയർഹൗസ് ടേബിളുകളെ അല്ല. റ〉(raw) ടേബിളുകൾ ഫോറിൻ കീകളിലും (foreign keys) യുണിക്സ് ടൈംസ്റ്റാമ്പുകളിലും (Unix timestamps) ആണ് സംസാരിക്കുന്നത്. എന്നാൽ സെമാന്റിക് ലെയർ ബിസിനസ് ഭാഷയിലാണ് സംസാരിക്കുന്നത്. RAG മോഡലിനെ നിങ്ങളുടെ യഥാർത്ഥ നിർവചനങ്ങളുമായി ബന്ധിപ്പിക്കുന്നു, അതിനാൽ ഹാളുസിനേഷനുകൾ (hallucinations) കുറയുകയും കൃത്യത വർദ്ധിക്കുകയും ചെയ്യുന്നു.
ഒരു മെട്രിക് ഗ്രാഫ് എല്ലാം എങ്ങനെ മാറ്റുന്നു
ഒരു നോട്ടിഫിക്കേഷനും (notification) ഒരു ഇൻസൈറ്റും (insight) തമ്മിലുള്ള വ്യത്യാസം ശ്രദ്ധിക്കുക. ഒരു അടിസ്ഥാന ഡാഷ്ബോർഡ് ഇപ്രകാരം ഒരു അലേർട്ട് നൽകുന്നു: "ഈ ആഴ്ച ക്ലോസ് റേറ്റ് 15 ശതമാനം കുറഞ്ഞു." അത് ഒരു തലക്കെട്ട് മാത്രമാണ്, ഒരു രോഗനിർണ്ണയമല്ല. ഒരു സ്മാർട്ട് സിസ്റ്റം ഇപ്രകാരം പറയും: "ചാനൽ X-ൽ നിന്നുള്ള ലീഡ് ക്വാളിറ്റി ചൊവ്വാഴ്ച കുറഞ്ഞതുകൊണ്ടാണ് ക്ലോസ് റേറ്റ് കുറഞ്ഞത്." ആ രണ്ടാമത്തെ വാചകം ഒരു സെയിൽസ് മാനേജർക്ക് ഉടൻ തന്നെ നടപടിയെടുക്കാനുള്ള വഴി കാണിച്ചുതരുന്നു. ക്വാർട്ടർ മോശമാകുന്നതിന് മുൻപ് തന്നെ അവർക്ക് പരസ്യച്ചെലവ് (ad spend) നിർത്താനോ, ലാൻഡിംഗ് പേജിലെ ഫോം പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കാനോ, അല്ലെങ്കിൽ SDR കവറേജ് പുനർനിശ്ചയിക്കാനോ സാധിക്കും.
ഇത് നിർമ്മിക്കാൻ മുകളിൽ വിവരിച്ച കാസൽ ഗ്രാഫ് (causal graph) ആവശ്യമാണ്. ഡൗൺസ്ട്രീം നോഡ്—ക്ലോസ് റേറ്റ്—അപ്രതീക്ഷിതമായി മാറുന്നအခൾ, സിസ്റ്റം അതിന്റെ പാരന്റ് നോഡുകളെ (parents) വിലയിരുത്തുന്നു. ഇത് ലീഡ് സ്കോറുകൾ, ചാനൽ മിക്സ്, സമീപകാല വില വ്യതിയാനങ്ങൾ, റെപ് അസൈൻമെന്റുകൾ എന്നിവ പരിശോധിക്കുന്നു. ഇത് ഊഹിക്കുകയല്ല ചെയ്യുന്നത്; ബിസിനസ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന രീതിയെ പ്രതിഫലിപ്പിക്കുന്ന ഒരു ഘടനയിലൂടെയാണ് ഇത് സഞ്ചരിക്കുന്നത്.
പ്രൊഡക്ഷനിൽ ഇത് ശരിയായി നടപ്പിലാക്കുക
ആർക്കിടെക്ചർ മാത്രം മതിയാവില്ല, കൃത്യമായ നിർവ്വഹണം (execution) പ്രധാനമാണ്.
ചെറുതായി തുടങ്ങുക. ബിസിനസ് നിലവിൽ നിരീക്ഷിക്കുന്ന മൂന്നോ നാലോ പ്രധാന മെട്രിക്സുകൾ തിരഞ്ഞെടുക്കുക. പൈപ്പ്ലൈൻ ക്രിയേറ്റഡ് (Pipeline created), ശരാശരി ഡീൽ സൈസ് (average deal size), ക്ലോസ് റേറ്റ് (close rate), സെയിൽസ് സൈക്കിൾ ദൈർഘ്യം (sales cycle length) എന്നിവ നല്ലൊരു തുടക്കമാണ്. വെബ്സൈറ്റ് ബൗൺസ് റേറ്റ് (website bounce rate), ഇമെയിൽ ഓപ്പൺ റേറ്റ് (email open rate), അല്ലെങ്കിൽ സോഷ്യൽ സെന്റിമെന്റ് (social sentiment) എന്നിവ ഉൾപ്പെടുത്തുന്നതിന് മുമ്പ് ഇവ കൃത്യമാണെന്ന് ഉറപ്പുവരുത്തുക. അമിതമായ അലേർട്ടുകൾ ആശയക്കുഴപ്പമുണ്ടാക്കും (noise), ഇത് സിസ്റ്റത്തെ അവഗണിക്കാൻ ആളുകളെ പ്രേരിപ്പിക്കും.
മനുഷ്യന്റെ അറിവും ഗണിതശാസ്ത്രവും സമന്വയിപ്പിക്കുക. നിങ്ങളുടെ സെയിൽസ് ഓപ്പറേഷൻസ് ടീമിനെക്കൊണ്ട് കാസൽ ഗ്രാഫിന്റെ ആദ്യ പതിപ്പ് തയ്യാറാക്കാൻ അനുവദിക്കുക. ലീഡ് സ്കോറുകൾ കുറയുമ്പോൾ, അതിന്റെ കാരണം പലപ്പോഴും ഒരു പ്രത്യേക ക്യാമ്പയിനോ അല്ലെങ്കിൽ ക്വാളിഫിക്കേഷൻ സ്ക്രിപ്റ്റിലെ മാറ്റമോ ആണെന്ന് അവർക്ക് അനുഭവപരിചയത്തിലൂടെ അറിയാം. സ്റ്റാറ്റിസ്റ്റിക്കൽ കോറിലേഷൻ (Statistical correlation) ഈ ബന്ധങ്ങളെ സ്ഥിരീകരിക്കുകയോ ചോദ്യം ചെയ്യുകയോ ചെയ്തേക്കാം, എന്നാൽ അത് ഒറ്റയ്ക്ക് ഇത്തരം കാര്യങ്ങൾ കണ്ടെത്തുന്നതിനേക്കാൾ പ്രയാസമാണ്. സെയിൽസ് ഓർഗനൈസേഷനുകളിലെ കാരണവും ഫലവും (cause and effect) ഡൊമെയ്ൻ വൈദഗ്ധ്യവുമായി (domain nuance) ബന്ധപ്പെട്ടതാണ്. അതിനെ മാനിക്കുക.
എല്ലാം ഓഡിറ്റ് ചെയ്യുക. ഓരോ ചാറ്റ്ബോട്ട് ഉത്തരവും അത് നിർമ്മിക്കാൻ ഉപയോഗിച്ച കൃത്യമായ സെമാന്റിക് നിർവചനം, SQL ഫ്രാഗ്മെന്റ്, അല്ലെങ്കിൽ മെട്രിക് വേർഷൻ എന്നിവയ്ക്കൊപ്പം രേഖപ്പെടുത്തുക. ഒരു അക്കൗണ്ട് 'ഹൈ റിസ്ക്' (high risk) ആണെന്ന് ബോട്ട് അടയാളപ്പെടുത്തിയതിനെക്കുറിച്ച് ഒരു റെപ് ചോദ്യം ചെയ്യുമ്പോൾ, അതിന്റെ കാരണം വ്യക്തമാക്കുക. സെയിൽസ് ടീമുകളുടെ വിശ്വാസമാണ് ഏറ്റവും വലിയ മൂല്യം. ബോട്ട് വെറുതെ ഊഹിക്കുകയാണെന്ന് ഉപയോക്താക്കൾ സംശയിച്ചാൽ, അവർ പഴയ രീതികളായ ഗട്ട് ഇൻസ്റ്റിങ്ക്റ്റിലേക്കും (gut instinct) സ്പ്രെഡ്ഷീറ്റുകളിലേക്കും മടങ്ങും.
യഥാർത്ഥ പാഠം
ഉപയോക്താക്കൾക്ക് CRM ഫീൽഡുകൾ മാത്രം തിരിച്ചു കാണിക്കുന്ന ലുക്കപ്പ് ടൂളുകൾ നിർമ്മിക്കുന്നത് നിർത്തുക. അതിനപ്പുറത്തേക്ക് പോകാനുള്ള സാങ്കേതികവിദ്യ—Airbyte വഴിയുള്ള സ്ട്രീമിംഗ് ഇൻജഷൻ (streaming ingestion), നിയന്ത്രിത സെമാന്റിക് ലെയർ (governed semantic layer), സ്റ്റാറ്റിസ്റ്റിക്കൽ കൂടാതെ കാസൽ മോഡലുകൾ, ബിസിനസ് ലോജിക്കിൽ അധിഷ്ഠിതമായ LLM എന്നിവ ഇപ്പോൾ ലഭ്യമാണ്. പ്രയാസകരമായ കാര്യം മോഡൽ വയറിംഗ് അല്ല. മറിച്ച്, മെട്രിക്സുകൾ കൃത്യമായി നിർവചിക്കാനും, കാരണങ്ങളെ അപ്സ്ട്രീമിൽ ഘടിപ്പിക്കാനും, വെറുതെ അലേർട്ടുകൾ നൽകി ബുദ്ധിമാനാകാൻ ശ്രമിക്കാതെ സിസ്റ്റത്തെ നിയന്ത്രിക്കാനുമുള്ള അച്ചടക്കമാണ്. ഉത്തരങ്ങൾക്കായി നിർമ്മിക്കുക, അപ്പോൾ ചാറ്റ്ബോട്ടിന് സെയിൽസ് മീറ്റിംഗുകളിൽ ഇടം ലഭിക്കും.
Based on the architecture described by Mayu2008. For more discussions on data engineering and AI systems, join the GyaanSetu community.