कॉल शेड्यूल करने की कोशिश बंद करें
(matduggan.com)- नए SaaS product को हल्के-फुल्के तौर पर आज़माने की कोशिश करते ही sales emails, mailing lists और बार-बार कॉल के अनुरोध शुरू हो जाते हैं, जिससे user का समय लगातार खिंचता रहता है
- खरीदारी का flow असल में ज़रूरी एक-दो features से हटकर fixed demo और “everything platform” जैसी explanation की तरफ चला जाता है, और sales rep व sales engineer कॉल्स बढ़ाते जाते हैं
- payment approval stage में senior decision-makers को कॉल में लाने का दबाव बढ़ता है, और internal approval में आम तौर पर कम से कम एक महीना, Fortune 500 में सब कुछ ठीक चलने पर भी कम से कम 3 महीने लगते हैं
- खरीदारी के बाद sales rep गायब हो जाता है और LLM-based customer support, लंबे SLA, undocumented limits और failure modes असली users के हिस्से में आते हैं
- account rep problem solving से ज़्यादा additional features बेचने पर ध्यान देता है, और अंत में जब उससे तेज़ और free open-source alternative आ जाता है, तो contract renewal रोकने और email breakup पर बात खत्म होती है
trial के बाद चिपक जाने वाले contact
- नई service या product आज़माते समय सबसे बड़ी बाधाओं में से एक है उसके बाद आने वाला लगातार contact
- शुरुआत में यह “अगर कोई सवाल हो तो बताइए” जैसे harmless email से शुरू होता है, लेकिन जल्द ही “customer success fun-gineer” जैसे कोई व्यक्ति trial experience check करने के नाम पर संपर्क करता है
- user आम तौर पर किसी एक specific feature को देखने के लिए sign up करता है
- अगर वह feature नहीं है, तो interest छोड़कर बात भूल जाता है
- अगर अभी evaluation में नहीं है, तो यह समझना मुश्किल होता है कि contact क्यों आ रहा है
- mailing list में बने रहने पर नए releases और launch notifications आते रहते हैं
- interest न होने पर भी, मनचाहा feature जुड़ गया हो सकता है—इस वजह से हर बार unsubscribe करने पर सोचना पड़ता है
- अगर accessible release notes नहीं हैं, तो marketing email ही feature add हुआ या नहीं यह check करने का इकलौता रास्ता बन जाता है
“एक कॉल कर लेते हैं” में बदलता खरीद flow
- सबसे खराब स्थिति तब होती है जब आप सचमुच service इस्तेमाल कर सकते हैं, और यहीं से calls की एक series schedule में बंध जाती है
- website पर credit card number डालकर बात खत्म होने के बजाय, Microsoft Teams पर अजनबियों के साथ relationship बनाना पड़ता है
- typical SaaS sales team में दो roles दिखते हैं
- sales rep CRM में data डालता है और deal close होने तक लगातार push करता है
- “sales engineer”, “customer success engineer” जैसे title वाला व्यक्ति उन गिने-चुने लोगों में से होता है जिन्होंने documentation सच में पढ़ी होती है, और product को नए “everything platform” की तरह समझाता है
- demo में वे features भी शामिल होते हैं जो user नहीं चाहता
- user सिर्फ एक-दो features check करने आया था, लेकिन fixed demo template flexible नहीं होता
- sales rep user को technical बताने जैसी हल्की तारीफ से माहौल नरम करने की कोशिश करता है
- sales engineer का demo किसी खराब moment पर टूट जाता है, और फिर “आम तौर पर यह ठीक चलता है” वाली सफाई आती है
security, compliance और लंबा होता approval
- किसी point पर compliance और security के बारे में पूछने पर बेकार certificates का bundle भेज दिया जाता है
- certification documents को इस तरह treat किया जाता है जैसे वे यह proof न हों कि items सच में पूरे किए गए हैं, बल्कि बस यह दिखाते हों कि उन्हें credible तरीके से पूरा किया गया दिखाया जा सकता है
- demo और relationship-building खत्म होने के बाद sales team user के senior decision-maker को कॉल में शामिल कराने की कोशिश करती है
- decision-makers हर हफ्ते कई companies के sales pitches सुनना नहीं चाहते, इसलिए proposal summarize करने का काम user पर आ जाता है
- अगर user product को सच में important मानता है, तो internal approval के लिए जरूरी लोगों से खुद संपर्क करना पड़ता है
- इस process में कम से कम एक महीना लगता है
- Fortune 500 company में, सब कुछ perfect चलने पर भी कम से कम 3 महीने लगते हैं
- समय बचाने के लिए product अपनाने की कोशिश एक बड़े project में बदल जाती है, और user सोचने लगता है कि क्या बेहतर होता अगर वह खुद ही tool को reverse-engineer कर लेता
खरीद के बाद बचने वाली limits और customer support
- approval खत्म होते ही और money transfer होते ही sales rep गायब हो जाता है, और user को Customer Service, यानी LLM के हवाले कर दिया जाता है
- “limitless, cloud-based platform” असली use में कई limits दिखाता है
- किसी दिन यह normal काम करता है
- अगले दिन कोई invisible threshold पार हो जाती है और पूरा flow टूट जाता है
- documentation फायदे highlight करने के लिए लिखी होती है, इसलिए warnings या limits ढूँढना मुश्किल होता है
- LLM customer support वही documentation links बार-बार देता है, और उसके बाद ही किसी real person को email भेजना possible होता है
- support email का SLA 72 business hours जैसा लंबा होता है, और इसे इस तरह लिया जाता है कि आपने Super Enterprise Plan™ नहीं चुना
- response इस तरह खत्म होता है कि आप किसी invisible limit तक पहुँच गए हैं, इसलिए workflow को restructure करें
- use जारी रखने पर undocumented failure modes की list बढ़ती जाती है
- उदाहरण: “दो buttons बहुत जल्दी दबाने पर iFrame error देता है”
- लगता है stack errors log कर रहा होगा, लेकिन कोई भी contact करके cause explain नहीं करता या fix करने में help नहीं करता
account rep, upsell, open source और goodbye
- एक दिन नया account rep contact करता है और product इस्तेमाल करने के तरीके व help discuss करने के लिए call मांगता है
- यह call feedback collection या problem solving से ज़्यादा एक और sales pitch जैसी होती है
- rep problems की list सुनकर “देखता हूँ” कहता है, लेकिन असली मकसद additional features खरीदने के लिए मनाना निकलता है
- additional features SSO या API access जैसी चीजें होती हैं, जिनका seller के लिए cost लगभग कुछ नहीं होता, लेकिन user के लिए बहुत बड़ा फर्क पड़ता है
- user को तय करना पड़ता है कि basic functionality पाने के लिए product और खरीदे, या इसे पूरी तरह हटाकर दूसरा रास्ता चुने
- आखिरकार कोई open-source developer वही काम करने वाला free tool बना देता है
- नाम CodeSquish, Dojo, GitCharm जैसा अजीब-सा हो सकता है
- इसके बारे में किसी colleague से पता चलता है, और देखने पर यह ज़रूरी सारे काम करता है, cost zero है और 100 गुना तेज़ है
- भले ही इसे सिर्फ एक व्यक्ति maintain कर रहा हो और forum केवल Discord server हो, फिर भी यह commercial product से कहीं बेहतर होता है
- contract की वजह से breakup टलता है, लेकिन अंत में Finance को renewal न करने के लिए बता दिया जाता है
- renewal रुकता दिखते ही vendor team अचानक बहुत interest दिखाती है, और समझाने की कोशिश करती है कि open-source tool असल में inferior है
- user कहता है “हम internally discuss करेंगे”, लेकिन असल में कोई discussion नहीं करता, और अंत में email से goodbye बताकर domain block कर देता है
1 टिप्पणियां
Hacker News की रायें
निवेशक भी अक्सर ऐसी processes को परिपक्वता का संकेत और top-tier तरीका मानते हैं
उलटा approach यह है कि जानकारी को जितना हो सके पारदर्शी तरीके से सार्वजनिक किया जाए और रोका न जाए, कमजोरियों को पहले ही ईमानदारी से बताया जाए, जब ग्राहक किसी इंसान से बात करना चाहे तो उसे तुरंत ऐसे व्यक्ति से जोड़ा जाए जो समस्या हल कर सके, जब तक ग्राहक अनुरोध न करे AI agent फोन न करे और तुरंत बता दे कि वह AI है, मासिक/त्रैमासिक/वार्षिक/सिर्फ release notes जैसे flexible email subscription options दिए जाएं, और अगर product fit न हो तो किसी अधिक उपयुक्त दूसरे product जैसे उपयोगी विकल्प सुझाए जाएं
value-based pricing की वजह से कई कंपनियां इस स्थिति में फंस जाती हैं। standard price रखने के बजाय वे customer की गहराई से जांच करती हैं, product से मिलने वाली value का अनुमान लगाती हैं और उसी हिसाब से price तय करती हैं। theory में इससे revenue maximize होता है, लेकिन यह धीमा और दखलंदाज है
free plan users बहुत basic programming भी नहीं कर पाते, और अनुमति मिलते ही पूरा tech support time खा सकते हैं
AI usage disclose करना, कई newsletter options देना, और fit न हो तो ईमानदारी से कहना reasonable है और असल में अच्छी तरह काम भी किया। लेकिन पहले वाले तीन product को बिगाड़ सकते हैं। हालांकि हो सकता है कि मैं cynic हूं या अब तक गलत तरीके से handle करता रहा हूं
अगर premise यह है कि investor funding से unicorn बनाना है, तो बात सही है; लेकिन किसी solo company के लिए, जिसके पास side income है और जो धीमी मगर steady growth चाहती है, यह तरीका सही हो सकता है
बिना regulation वाली competition नीचे की तरफ race है, जहां सबसे unethical, intrusive, illegal की सीमा पर खड़ी और manipulative tactics जीतती हैं
best product नहीं, best marketing जीतती है; customer-friendliness नहीं, coercion के जरिए conversion rate जीतता है; और product/service की value नहीं, बल्कि लोग जितना maximum दे सकते हैं वही price बन जाता है
free plan या trial और ठीक-ठाक documentation होने के बावजूद वे demo मांगते हैं। अपनी तरफ किसी से review करवाने के बजाय मेरा समय बर्बाद करना पसंद करते हैं
असल में switch करने का कोई इरादा नहीं होता, फिर भी enterprise competitor के renewal contract को सस्ता कराने के लिए price/functionality comparison के तौर पर इस्तेमाल करते हैं
यह भी पक्का नहीं होता कि sale होगी या नहीं, फिर भी अंतहीन security questionnaires भरने पड़ते हैं। जैसे शुक्रवार रात 11 बजे 100 से ज्यादा सवाल भरना किसे पसंद नहीं होगा
procurement process में 3–6 महीने लगते हैं, और अक्सर एक-दो third-party software resellers बीच में आ जाते हैं जिन्हें सिर्फ अपना margin दिखता है। CDW से कहना पड़ता है कि हम price 15% कम करके तुम्हें पैसा कमाने में मदद नहीं करेंगे
contract खत्म होने के बाद भी पैसा 60–90 दिन बाद आता है, लेकिन service पहले ही देनी पड़ती है और cash flow दबाव में आ जाता है। bank manager भी फोन कर सकता है कि margins और credit card limit क्यों maxed out हैं
इसलिए बड़ी कंपनियों से मैं जरूर महंगा charge करूंगा
पहले से साफ-साफ बता देना कि क्या करेंगे और क्या नहीं, सच में मदद करता है। वे अब भी procurement forms जैसी चीजें मांगते हैं, लेकिन कम से कम मना करके expectations set कर सकते हैं
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
अगर थोड़ी customization चाहिए, या कोई early startup product-market fit को refine और prove करने के लिए pilot customer के साथ काम कर रहा हो, तो मुश्किल और बढ़ जाती है। अगर customer investor portfolio की कोई दूसरी startup नहीं बल्कि एक असली company है, और उसके अंदर बहुत छोटी team से ज्यादा पर असर पड़ता है, तो भले ही आपके पास पहले से CEO का attention हो, आपको कई departments के stakeholders के साथ महीनों तक अंतहीन meetings के लिए तैयार रहना होगा
एक agile early startup के तौर पर यह महसूस होता है कि theory में आपके पास बड़ी और सुस्त enterprise company की तुलना में जबरदस्त innovation advantage होना चाहिए, क्योंकि वे कुछ भी कर पाने में असमर्थ लगते हैं
लेकिन अगर आपने वही गलती कर दी कि आपको उसी कुछ-न-कर-पाने वाली बड़ी और सुस्त enterprise company की सहमति चाहिए, तो अब उनकी movement barriers में से ज्यादातर आपकी barriers बन जाती हैं
मैंने इसी कहानी का और भी खराब variant देखा है। एक engineer, जिसकी team पहले से एक अच्छा open-source solution सफलतापूर्वक चला रही थी, ने सुना कि दूसरे engineer पर किसी घटिया product की enterprise sales push गिर पड़ी है और alarm बजाने की कोशिश की, लेकिन तब तक बहुत देर हो चुकी थी
org chart में ऊपर की तरफ किसी ने political capital लगाकर sign कर दिया था, और कुछ मामलों में company का पैसा उसी खास product पर खर्च करना किसी व्यक्ति का performance metric बन गया था। इसलिए सभी alternatives block हो गए, सबने sales close होने का महीनों इंतजार किया, फिर IT द्वारा SSO और database setup करने के लिए एक और महीना इंतजार किया, और जो solution ठीक से काम कर रहा था उससे कचरे पर जबरन migration कर दिया गया
आखिरकार contract renew नहीं हुआ और इसे push करने वालों ने अपनी इज्जत बचा ली, लेकिन जिन लोगों पर यह थोपा गया था उनमें से आधे बेहतर कंपनियों में चले गए, एक चौथाई को घटिया product की वजह से रुकावट झेलनी पड़ी और PIP मिला या career stagnate हो गया, और बचे हुए चौथाई में से भी ज्यादातर अगले साल lay off हो जाएंगे
enterprise sales को बस NO कहना चाहिए। अपना product बेचने के लिए enterprise sales करनी पड़े, इससे भी बुरा यह है कि किसी और enterprise sales से पैदा हुए खराब purchase decision को employee के तौर पर जबरन इस्तेमाल करना पड़े
लेकिन जब open-source solution ढूंढते हैं, तो आम तौर पर वह बेहतर होता है और आप जो चाहते हैं वह सब कर सकता है।
docker compose upसे ही आसानी से test भी हो जाता हैलेकिन deployment stage पर compliance सिर्फ SOC2 certification देखती है, और इस आधार पर code की deep due diligence मांगती है कि theory में दुनिया का कोई भी व्यक्ति code बदल सकता है, और फिर जोरदार रोक लग जाती है
मैनेजर पूछता है कि मुफ़्त और open source होते हुए यह इतना अच्छा कैसे हो सकता है, और overload में चल रही टीमों को आम तौर पर एक और unpredictable software को support करना पसंद नहीं होता
इसलिए आखिर में चुनाव यह रह जाता है कि खराब SaaS, अंतहीन और बेकार sales cycle, और डरावने व महंगे vendor lock-in पर पैसा और दिमाग जलाया जाए, या open source को in-house अपनाकर और चलाकर थोड़ा पैसा और दिमाग जलाया जाए
आम तौर पर open source चुना जाता है। खासकर तब, जब SaaS तेज़ और आसान self-onboarding, मायने रखने वाली evaluation period, और predictable व transparent pricing नहीं देता
और जब वह व्यापक रूप से adopt हो जाता है, तो author को support किया जाता है, या अगर open source software ज़्यादा complex हो तो support plan के लिए budget रखा जाता है। भले ही असल में उसकी ज़रूरत शायद ही पड़े
“[…] Google पर CodeSquish खोजा तो वह मेरी ज़रूरत की सारी चीज़ें करता था, cost 0 थी, और performance 100 गुना बेहतर थी। जबकि उसे Vermont के farm से कभी-कभार निकलकर अपने self-hosted git repository में code push करने वाला एक एकांतप्रिय व्यक्ति maintain करता था।”
उस गरीब एकांतप्रिय maintainer को किसी मंगलवार दोपहर पता चलता है कि आपकी company “CodeSquish” से सालाना 100 million dollars कमा रही है और कुछ भी contribute नहीं कर रही। वह Vermont farm में मुर्गियों को दाना डालते हुए चुपचाप अपनी life choices—नहीं, license choices—पर शक करने लगता है
ज़्यादातर open source या SaaS, Fortune 500 companies में उपयोगी तो होते हैं, लेकिन अक्सर सुविधा जैसी चीज़ होते हैं, इसलिए उनकी value लगाना मुश्किल होता है। लेख में भी दिखता है कि SaaS vendor बड़ी company को ज़्यादा valuable दिखने के लिए सजावट करता है, लोगों को call करके बकवास push करता है, और value-based pricing इस्तेमाल करता है
किसी company के open source system चलाने का मतलब यह भी ज़्यादा नहीं देखा कि वह उसे resell करती हो। आम तौर पर वे पूरी intellectual property own करना चाहते हैं, इसलिए लेख की तरह अपनी ही घटिया चीज़ फिर से बना लेते हैं
Amazon ने Elastic के साथ जो किया, वह इसलिए possible था क्योंकि Elastic ने brand बनाया था। किसी random project के साथ ऐसा नहीं कर सकते। कोई project infrastructure चलाने में इस्तेमाल हो सकता है, लेकिन किसी खास library या project को value attribute करना बहुत मुश्किल है
Amazon पैसा इसलिए कमाता है क्योंकि वह Amazon है, इसलिए नहीं कि वह Linux kernel इस्तेमाल करता है। खैर, यह दिमाग में ठीक से बैठाना मुश्किल problem है
पहला, इसका बड़ा हिस्सा B2B sales करने और software industry के आधे हिस्से को चलाते रहने के लिए ज़रूरी भी हो सकता है। बेचने वाली company को कई बार contact करना, sales engineer लगाना, और सभी decision-makers को align कराने की process में मदद करनी पड़ सकती है। वरना काम शुरू ही नहीं होता। Buyers बहुत busy होते हैं और बड़ी companies को बेचना बहुत complex है, इसलिए इसका कुछ हिस्सा B2B deals को चलते रखने के लिए necessary evil है
दूसरा, काश companies सच में बेहतर तरीके से खरीदतीं। बड़े enterprises enterprise bloat software पर millions of dollars खर्च करते हैं, जबकि startup 1/10 cost पर 10 गुना बेहतर चीज़ बना सकता है। अगर उन्हें आसानी से बेचा जा सके, तो इस पागलपन के बिना भी सबको बेहतर चीज़ें मिल सकती हैं
original post का experience soul-crushing है, इससे सहमत हूँ, लेकिन customers भी अगर खुद की थोड़ी मदद करें तो उनकी जेब में ज़्यादा पैसा रहेगा और बेहतर technology भी मिलेगी
Enterprise product बस अलग category है, और यह product itself से अलग बात है
“LinkedIn पर देखा कि आप Spanish बोलते हैं। सुना है कि ‘¡Qué chévere!’ बातचीत में energy और brightness लाने का uniquely charming तरीका है। हाल में practice करने का मौका मिला?”
“बदलते regulations के साथ adapitates करने वाले compliance automation tools develop करते हैं, जो secure और efficient investment program सुनिश्चित करते हुए overhead कम करते हैं।”
कोई इंसान LinkedIn पर मेरे Spanish “limited working proficiency” marker को देखकर पहली sentence जैसी बात नहीं कहेगा। और दूसरे में “Adapitates” कोई real word नहीं है, बल्कि hallucination है। https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Problem sales itself नहीं है; ज़्यादातर लोग कुछ हद तक sales accept कर लेते हैं। एक data replication company से non-personalized cold email मिला था, जो छोटा, to-the-point और spam email के हिसाब से sincere था, इसलिए सच में product में interest पैदा हुआ
धरती पर हर company इस technology को experiment कर रही है, और जब वे इसे बिगाड़ते हैं तो अगर हम strong signal नहीं देंगे, तो हम अपने future selves को इसी कचरे से बाँध रहे होंगे
जिन customers को ये features चाहिए, उन्हें cost चाहे जो हो, support या SOC-2 report जैसी चीज़ें चाहिए होती हैं, और वही उन customers को subsidize करते हैं जिन्हें ये नहीं चाहिए। अगर इससे मदद मिले, तो SSO और SLA वाला advanced package ही product की real price मान लें
वैसे भी tech field में असली cost-based pricing लगभग होती ही नहीं
इसका मतलब मूल रूप से यह है कि company को कम से कम 1 additional employee की fully loaded cost उठानी होगी। वह fully loaded cost मोटे तौर पर salary का 2x मान लें, और उसे ऐसे SLA मांगने वाले customers की संख्या से divide करें, तो दिखने लगता है कि कितना charge करना चाहिए
अगर पता हो कि जवाब 3 दिन बाद ही मिलेगा, तो साफ़-साफ़ चीज़ें खुद खोज लेता हूँ, और support से तभी संपर्क करता हूँ जब जवाब किसी और तरीके से न मिले। लेकिन छोटी SLA, खासकर phone support, कुछ तरह के ग्राहकों को हर error message जस का तस copy-paste करने और support team से उसे हल करने की उम्मीद करने पर मजबूर करती है, भले ही वह error product से आया ही न हो। खुद अनुभव किया है
Cross-subsidy regulation की वजह से हो सकती है, या तब जब company market monopoly की कोशिश कर रही हो
Product की कीमत development cost से ज़्यादा इस बात पर तय होती है कि कितना charge किया जा सकता है और variable costs क्या हैं। जैसा आपने बताया, इससे price discrimination होता है, और ऊपर से ऐसा लग सकता है कि एक group दूसरे group को subsidize कर रहा है, लेकिन वास्तव में ऐसा हो भी न सकता है
मैं marginal cost और ideal decision-making का model देखना चाहूँगा। High-paying customers के लिए exclusive feature बनाने का फैसला तभी profitable होता है जब वे customer उस feature की कीमत चुकाएँ। दूसरे customers को वह feature मिल सकता है, लेकिन वह “subsidy” नहीं है। हालांकि इससे बेहतर शब्द क्या होगा, यह मुझे नहीं पता
बिना बकवास वाला direct approach, तुरंत demo, meaningful evaluation period, आसान onboarding वगैरह दें, तो आप उन customers को खो देंगे जो सामान्य sales game की उम्मीद करते हैं
स्रोत: मैं खुद direct approach अपनाता हूँ
तो फिर sales engineer के साथ phone call क्यों? Email तो बस delete किया जा सकता है
बताई गई स्थिति की तरह अगर technical person final decision-maker को रोक रहा है, तो यह ज़्यादा जुआ है और अक्सर fail होता है
जिन products में मैं credit card details डालकर तुरंत शुरू करना चाहता हूँ, वे सिर्फ AWS EC2 या domain registration service जैसे general-purpose software हैं
Pricing/sales model में रेखाएँ कभी-कभी उलझ जाती हैं; जैसे enterprise product को general-purpose software की तरह price करना। यह आम तौर पर company के immature होने का संकेत है
दो-तीन अंकों की कीमत वाले software के लिए sales team नहीं होनी चाहिए। पाँच-छह अंकों या उससे ऊपर के software के लिए sales और onboarding process में इंसान ज़रूरी हैं। क्योंकि मैं जो भुगतान करता हूँ, उसका बड़ा हिस्सा support के लिए होता है
समस्या यह है कि हम आम तौर पर यह नहीं जानना चाहते कि “क्या यह use case पूरा कर सकता है”, बल्कि यह जानना चाहते हैं कि “यह इस use case को कितनी अच्छी तरह पूरा करता है।” Software को खुद इस्तेमाल किए बिना इसका आकलन करना मुश्किल है
मुझे sales pitches बहुत अक्सर नहीं मिलतीं, लेकिन दूसरे कारणों से मेरा रवैया मिलता-जुलता है। पहले दरवाज़े में पैर रखने के लिए हाँ कहकर बाद में detailed terms पर नहीं कहने की स्थिति से बचने के लिए, मैं सब कुछ लिखित में रखना चाहता हूँ