• सॉफ्टवेयर बनाने की लागत लगभग शून्य होने के साथ, फीचर्स और UI तेजी से कॉपी किए जा सकने वाले कमोडिटी बन रहे हैं, और SaaS की वैल्यू सॉफ्टवेयर पैकेजिंग के नीचे मौजूद दुर्लभ एसेट्स की ओर शिफ्ट हो रही है
  • नई defensibility प्रोप्राइटरी डेटा लूप्स और action permissions, एजेंट के decision-making चरण में आने वाले distribution, और ERP·ledger·identity·compliance platforms जैसे deterministic systems of record से आती है
  • सीट-आधारित मॉडल से outcome-based pricing में जाने पर provider failure cost उठाता है, और profitability billing amount तथा inference cost·failure rate के अंतर को मैनेज करने वाली underwriting क्षमता पर निर्भर करती है
  • एजेंट analysis·monitoring·reconciliation·follow-up work को बड़े पैमाने पर संभालते हैं; सीटों की संख्या घटे तब भी अगर automate होने वाले काम की मात्रा unit price में गिरावट से तेज बढ़े, तो कुल सॉफ्टवेयर market बड़ा हो सकता है
  • इंसानी habits और word-of-mouth पर निर्भर PLG की तुलना में, जरूरत पड़ने पर एजेंट द्वारा call किए जाने वाले approved tools ज्यादा अहम हो जाते हैं; strategy भी दुर्लभ एसेट हासिल करना→outcome pricing→agent distribution पर पकड़ के 3 चरणों में पुनर्गठित होती है

मौजूदा SaaS प्लेबुक क्यों टूट गई

  • 2026 की शुरुआत में सॉफ्टवेयर market से 4 हफ्तों में लगभग 2 ट्रिलियन डॉलर की वैल्यू गायब हो गई, और यह पिछले 20 वर्षों से लागू माने जा रहे नियमों के टूटने की सामूहिक समझ से जुड़ा था
  • Salesforce ने अपने इतिहास के सबसे तेजी से बढ़े product Agentforce को 1.2 बिलियन डॉलर ARR के scale तक पहुंचाया, लेकिन उसका stock 52-week low पर गिर गया
  • Clay और Cursor जैसे नए startups मौजूदा software companies से कहीं तेज बढ़ रहे हैं, और existing databases में chatbot जोड़ने से आगे जाकर सॉफ्टवेयर की value criteria को बदल रहे हैं
  • वह classic 3-step model जिसमें समय ही moat था

    • पुरानी enterprise software strategy इस premise पर आधारित थी कि build करना मुश्किल है, और wedge→suite→platform के 3 चरणों में आगे बढ़ती थी
    • पहला चरण wedge था: किसी एक feature को existing products से 10x बेहतर बनाना, और इस बात को defensibility बनाना कि उसे copy करने में सालों लगेंगे
    • दूसरे चरण में उसी buyer को adjacent products cross-sell करके 100 मिलियन डॉलर ARR से ऊपर की product suite तक विस्तार किया जाता था
    • तीसरा चरण पर्याप्त scale मिलने के बाद underlying systems तक replace और own करने वाला platform transition था
    • हर चरण में 3–5 साल लगते थे, और सिर्फ code ही नहीं बल्कि वह calendar time भी moat की तरह काम करता था
    • अगर production cost लगभग शून्य हो जाए और competitor weekend में flagship feature दोबारा बना सके, तो वह feature moat नहीं बल्कि marketing budget वाली commodity के करीब है
    • हजारों छोटे AI tools से मुकाबला करना पड़ेगा—यह चिंता temporary threat से ज्यादा एक नए नियम जैसी है
    • build करना जितना free होता जाएगा, product surface advantage टिके रहने की अवधि भी उतनी ही शून्य के करीब जाएगी
  • build capability से owned assets की ओर बदलाव

    • competition का axis उसी product को तेज बनाने से ऐसे एसेट्स own करने की ओर 90 डिग्री घूम गया है जिन्हें replicate नहीं किया जा सकता
    • पहले सबसे अच्छा बनाने वाली company को reward मिलता था, लेकिन अब build cost खत्म होने के बाद भी जो चीज दुर्लभ बचती है, उसे रखने वाली company को advantage है
    • market सिर्फ software companies की कमजोर performance को reflect नहीं कर रहा; वह उन companies का revaluation कर रहा है जिनकी value सिर्फ product surface पर थी, और उनके नीचे non-replicable assets रखने वाली companies को अलग छांट रहा है
    • क्या build करना है, इसकी बजाय क्या own करना चाहिए ज्यादा महत्वपूर्ण सवाल बन गया है

चार एसेट्स जिन्हें free में नहीं बनाया जा सकता

  • प्रोप्राइटरी डेटा का compounding loop

    • पहला एसेट खरीदा हुआ डेटा नहीं, बल्कि product usage के दौरान पैदा होने वाला और अगले परिणामों को बेहतर बनाने वाला proprietary data loop है
    • जिस usage data cycle को competitors शुरुआत से reproduce नहीं कर सकते, वह समय के साथ एसेट बनता है; और जैसे-जैसे एजेंट बढ़कर ज्यादा डेटा consume करते हैं, defensibility भी गहरी होती जाती है
    • अगर usage एक non-replicable feedback loop नहीं बनाता, तो product commodity बनने का इंतजार कर रहा UI भर रह जाता है
  • महत्वपूर्ण actions perform करने का अधिकार

    • दूसरा एसेट सिर्फ read access नहीं, बल्कि ऐसे action permissions हैं जिनसे वास्तविक परिणाम पैदा होते हैं
    • पैसे move करना, contracts sign करना, medical records बदलना, production code deploy करने की permissions लंबे समय तक trust बनाकर ही मिलती हैं और कुछ सेकंड में revoke भी हो सकती हैं; इन्हें सिर्फ सस्ती development capability से नहीं बनाया जा सकता
    • enterprise compliance के 20 सालों को improvised AI coding से reproduce नहीं किया जा सकता—यह logic integrations से आगे action permissions पर भी लागू होता है
    • agent environment में data पढ़ने वाले agent से ज्यादा मूल्यवान वह agent है जिसे company write operations सौंप सकती है
  • एजेंट decision-making stage में distribution

    • तीसरा एसेट agent distribution है: वह ability कि जिस पल agent तय करता है कि कौन सा tool इस्तेमाल करना है, उस समय आपका tool चुना जा सके
    • इंसानों के लिए search visibility या viral growth से ज्यादा अहम यह बन जाता है कि जरूरत पड़ने पर agent आपको discover कर सके और भरोसेमंद tool मान सके
  • deterministic core और systems of record

    • चौथा एसेट ERP, ledger, identity·compliance platforms जैसे deterministic core और systems of record हैं
    • एजेंट को actions के लिए definitive source चाहिए; इसलिए legal या financial outcomes वाली tasks में 10 में 6 बार सही model पर्याप्त नहीं है
    • agent orchestration systems of record को replace नहीं करता, बल्कि उनके ऊपर build होता है
    • दूसरी companies के data पर सिर्फ polished interface लगाने वाली companies सबसे ज्यादा exposed हैं; वहीं non-replicable assets रखते हुए software भी बेचने वाली companies अपेक्षाकृत safe हैं
    • पिछले 20 सालों में software खुद दुर्लभ था, इसलिए यह बात छिपी रही; core शुरुआत से ही underlying assets own करने में था

Outcome-based pricing billing नहीं, underwriting business है

  • risk customer से provider की ओर शिफ्ट होता है

    • seat-based pricing में customer 500 licenses खरीदने के बाद actual usage से जुड़े risk भी उठाता था, और provider delivered value से अलग access rights के लिए payment लेता था
    • providers outcome delivery risk लगभग नहीं उठाते थे—यह एक वजह थी कि peak period में प्रमुख SaaS companies revenue के 18–19x पर trade कर सकती थीं
    • solved tickets, closed deals, completed tasks के आधार पर charge करने पर provider result guarantee करने की position में आता है, और agent fail होने की cost भी provider उठाता है
    • companies tools नहीं, बल्कि accountable outcomes बेचने लगती हैं; इसलिए outcome-based SaaS की structure traditional software की तुलना में insurance company जैसी होती है
  • inference cost और failure rate margin तय करते हैं

    • margin उस price से तय होता है जो outcome के लिए charge किया गया, और उसे deliver करने में लगी inference cost·failure cost के अंतर से
    • cost of goods AI inference के हिसाब से बदलती है, इसलिए gross margin fixed 80% नहीं रहता; यह model के अनुसार बदलता है और volatility भी बढ़ती है
    • जो company outcome risk को सबसे अच्छे से underwrite करती है, वही winner होती है; और outcome pricing को सही तरह से set करने के लिए data चाहिए—यह फिर से proprietary data loop से जुड़ता है
    • Gartner के forecast के अनुसार, 2030 तक enterprise SaaS spending का कम से कम 40% usage·agent·outcome-based pricing की ओर shift होगा
    • जिन companies के पास risk को price में reflect करने वाला data है, वे advantage accumulate कर सकती हैं; लेकिन guesswork पर निर्भर companies हर failed outcome के साथ margin गंवाएंगी

सीटें घटने पर भी market क्यों बढ़ सकता है

  • fixed workload वाले bearish view की premise

    • bearish view मानता है कि total workload fixed है और agents कम workforce से वही काम कर देंगे, इसलिए seats और revenue साथ-साथ घटेंगे
    • यह logic जनवरी 2026 के मध्य से फरवरी मध्य तक एक महीने में software market value के लगभग 2 ट्रिलियन डॉलर घटने के पीछे काम कर रहा था
    • outcome-based pricing में revenue basis logged-in users की संख्या से बदलकर completed workload हो जाता है, इसलिए fixed workload premise टिकती नहीं
    • agents सिर्फ इंसानों जितना ही काम नहीं करते; cost और attention की limits के कारण जिन analysis·monitoring·reconciliation·follow-up tasks पर companies ने staff नहीं लगाया था, उन्हें भी वे कहीं बड़े scale पर कर सकते हैं
    • अब तक execute न हो पाए काम का backlog बड़ा है, और agents इस क्षेत्र तक भी automation पहुंचा सकते हैं
  • workload growth और unit price decline की प्रतिस्पर्धा

    • मुख्य economic variable यह नहीं कि seats घटती हैं या नहीं, बल्कि यह है कि नए automate होने वाले काम की growth rate per-task price की गिरावट से ज्यादा है या नहीं
    • कई categories में workload ज्यादा तेज बढ़ सकता है, इसलिए seat model कमजोर होने पर भी कुल software market बढ़ सकता है
    • Salesforce के fiscal 2027 Q1 के top 10 deals में से 7 ने seats add कीं, और उसी अवधि में Agentforce लगभग 3x बढ़कर 1.2 बिलियन डॉलर ARR के करीब पहुंचा
    • इस case में existing seat model की गिरावट से ज्यादा तेजी से total market expansion दिखाई दिया
    • seats में गिरावट को सीधे revenue decline से जोड़ने पर यह बात छूट जाती है कि revenue basis खुद बदल रहा है
    • bearish view existing pricing model के decline पर सही हो सकता है, लेकिन long-term market terminal size को काफी कम आंक सकता है

एजेंट software distribution को कैसे पलटते हैं

  • human-centric PLG की कमजोरी

    • पिछले 15 वर्षों में dominant sales motion एक user हासिल करने के बाद अच्छी onboarding experience और peer recommendations के जरिए seats expand करने वाला bottom-up product-led growth (PLG) था
    • free tier, viral loops, UI polish—सब human attention और habits capture करने के लिए design किए गए थे
    • agents habits नहीं बनाते, onboarding देखकर प्रभावित नहीं होते, और colleagues को product recommend नहीं करते; इसलिए existing PLG growth loops कमजोर होते हैं
    • इसके बजाय वे functionality, reliability, cost और जरूरत के पल discoverability के आधार पर tools चुनते हैं
    • distribution का लक्ष्य इंसानों के बीच viral होने से बदलकर ऐसा default trusted tool बनना है जिसे agent action लेने के पल चुने
  • top-down enterprise sales की वापसी

    • कौन सा tool पूरे agent fleet द्वारा call किया जा सकता है, यह self-service end user नहीं बल्कि platform·security·architecture buyers तय करते हैं; इसलिए top-down enterprise sales फिर मजबूत हो सकती है
    • पिछले 10 वर्षों की यह common belief कि PLG enterprise sales से superior है, 2–3 सालों में पलट सकती है
    • agent द्वारा call किए जा सकने की state को प्रमुख go-to-market entry point के रूप में treat करना होगा
    • agent के decision point पर discover और trusted होना search results के first page पर दिखने जैसी भूमिका निभाता है
    • Salesforce ने Headless 360 launch करते हुए ऐसी structure पर जोर दिया जिसमें customer के direct login किए बिना भी agents system का उपयोग करते हैं
    • dashboard से ज्यादा product वह position बन जाता है जो उसके नीचे के system और approved agent tools list में होती है; भविष्य का actual user जिस UI को खोलेगा ही नहीं, उसे polish करना भर काफी नहीं है

नए रूप में परिभाषित SaaS के 3 चरण

  • चरण 1: non-replicable assets हासिल करना

    • defendable narrow niche खोजने की बजाय, अपनी reach के भीतर सबसे deep data loop, highest-trust action permission, या system-of-record status चुनकर तेजी से हासिल करना होगा
    • asset को wrap करने वाला product सस्ते में बनाया जा सकता है, लेकिन underlying asset खुद नहीं
  • चरण 2: outcome pricing और risk underwriting

    • seat pricing से हटकर ऐसी data advantage बनानी होगी जिससे outcomes के risk को competitors से ज्यादा accurate तरीके से price में reflect किया जा सके
    • outcome-based pricing outcomes को underwrite करने वाला business है, इसलिए सबसे बेहतरीन underwriting capability वाली company को advantage है
  • चरण 3: वह tool जिसे agent जरूर call करे

    • orchestration layer में distribution हासिल कर, workload explode होने पर ऐसा tool बनना होगा जिसे जरूरत के कारण call किया जाए, न कि इसलिए कि इंसान brand को याद रखते हैं

दिशा साफ है, लेकिन timing अनिश्चित है

  • agent reliability उन महत्वपूर्ण actions को सौंपने लायक threshold से नीचे अटक सकती है; इस स्थिति में human approval वाला core लंबे समय तक बना रहेगा और existing companies को adapt करने का समय मिलेगा
  • enterprise product launch announcements से नहीं, बल्कि procurement processes की speed से move करता है, इसलिए transition timing को ठीक-ठीक जानना मुश्किल है
  • spring sell-off के बाद market तेजी से recover हुआ, और SaaStr के Jason Lemkin के अनुसार forward software multiples cloud era में पहली बार S&P 500 से कम 22.7x पर bottom कर गए
  • यह recovery structural extinction तय होने से ज्यादा overreaction के correction जैसी दिखती है, और software bearish view change की direction और timing को confuse कर सकता है
  • SaaS खुद गायब नहीं हो रहा; वह value के target से packaging medium में downrank हो रहा है
  • पिछले 20 वर्षों में software दुर्लभ था और इसलिए value ले गया, लेकिन अब rewards data, trust, action permissions, और उस point की ओर shift हो रहे हैं जहां agents call करने के tools चुनते हैं
  • 2026 की competition यह अलग करने की प्रक्रिया है कि कौन सी companies दुर्लभ assets के ऊपर खड़ी हैं और कौन सी सिर्फ software packaging पकड़े हुए हैं
  • transition के बाद की structure के मुताबिक build करने वाले founders अगले 10 वर्षों का enterprise software अपने नाम कर सकते हैं

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.