Judgment और outcomes की कीमत तय करें, घंटों की नहीं। AI समय और लागत के बीच का link तोड़ देता है, इसलिए घंटे वाला model तेज़ होने पर आपको दंड देता है: जितना बेहतर आपका workflow, उतने कम घंटे bill होते हैं और उसी outcome के लिए उतनी कम कमाई। AI-native सुधार यह है कि जो client असल में ख़रीदता है उसकी कीमत तय करें — decisions, एक standard, एक outcome — और production को एक input cost मानें जिसे आप control करते हैं।
मैंने agency काम की कीमत दोनों तरफ़ से तय की है, विक्रेता और ख़रीदार की तरह, और यह वह बदलाव है जिसमें लोग सबसे ज़्यादा ठोकर खाते हैं। Instinct है कि price list रखें और बस तेज़ deliver करें। वह एक अकेला कदम है जो quality बदले बिना आपकी revenue सिकोड़ने की गारंटी देता है।
घंटे वाली कीमत की समस्या
घंटे वाली कीमत तब समझ में आती थी जब समय लागत के साथ चलता था। अगर एक plan में चालीस घंटे लगते थे, तो उसकी लागत चालीस घंटे के वेतन और overhead के बराबर थी, और rate वह लागत plus एक margin था। Model ईमानदार था क्योंकि input और output जुड़े थे: ज़्यादा काम, ज़्यादा घंटे, ज़्यादा लागत। Clients agencies को rate और मोटे तौर पर effort से compare कर सकते थे।
AI उस link को काट देता है। वही plan समय के एक अंश में हो सकता है, लागत के एक अंश में, बराबर या बेहतर quality के साथ। घंटे वाले model में, वह सुधार पूरा client के पास एक छोटे invoice की तरह बह जाता है, और agency उस मूल्य का कुछ भी कैप्चर नहीं करती जो उसने बनाया। बदतर, यह agency को धीमे काम करने का एक प्रोत्साहन देता है — ठीक वही व्यवहार जिसके लिए client पैसे नहीं देना चाहता। घंटे वाली कीमत अब एक structural misfit है, style की पसंद नहीं।
आप असल में क्या बेचते हैं
एक AI-native engagement को खोलें और client घंटे नहीं ख़रीद रहा है। वह एक ऐसा फ़ैसला ख़रीद रहा है जिस पर उसे भरोसा हो, एक ऐसा standard जो टिके, और एक ऐसा outcome जिसे वह भरोसे से अकेला produce न कर सके। Model और workflow वह तरीक़ा हैं जिससे आप यह deliver करते हैं, वह चीज़ नहीं जो आप बेचते हैं। जब आप ऐसे देखें, तो price का सवाल बन जाता है: फ़ैसले का value क्या है, और हम उसे कैसे बाँटते हैं?
यह re-framing मायने रखता है क्योंकि यह बदलता है कि "scope" का मतलब क्या है। घंटों में, scope effort है। Outcomes में, scope outcome है और उसके आस-पास की constraints। एक client जो एक ऐसा campaign चाहता है जो एक ख़ास लक्ष्य हासिल करे, वह उससे अलग चीज़ ख़रीद रहा है जो एक तय संख्या की assets delivered चाहता है, और कीमत चाहिए कि वह प्रतिबिंबित करे कि उसे क्या चाहिए।
तीन pricing models
Judgment के लिए retainer। Client senior judgment और एक standard तक लगातार पहुँच के लिए पैसे देता है। यह उस काम के लिए काम करता है जिसमें value continuous है — strategy, review, आगे क्या करना है इस पर स्थायी call — और जहाँ volume अनुमान लगाना मुश्किल है। एक retainer घंटों की बाल्टी नहीं है; यह decision layer की एक subscription है, एक तय स्तर की पहुँच और ज़िम्मेदारी के साथ।
Project या outcome पर कीमत। Client एक तय outcome के लिए एक तय कीमत देता है। यह उस काम के लिए काम करता है जिसका एक साफ़ अंत-राज्य है: एक plan, एक launch, एक relaunch, एक measurement design। आप production cost का risk absorb करते हैं, जो अब कम है क्योंकि AI production को सस्ता बनाता है, और अगर आप efficient हैं तो आप अंतर रखते हैं। यहाँ discipline outcome को सही-सही scope करना है, ताकि "done" एक negotiation न हो।
Performance या upside का हिस्सा। Client outcome के एक हिस्से के पैसे देता है। यह उस काम के लिए काम करता है जहाँ outcome मापने लायक़ और attributable है, और जहाँ आपके पास उसके लिए accountable होने का पर्याप्त control है। यह सबसे high-risk और सबसे विवादास्पद model है, इसलिए यह सिर्फ़ तब काम करता है जब measurement शुरू होने से पहले तय हो। इसे वहाँ इस्तेमाल करें जहाँ आप outcome पर सचमुच विश्वास करते हैं, किसी pitch को कीमत पर जीतने के लिए नहीं।
ज़्यादातर AI-native agencies एक मिश्रण चलाती हैं: judgment layer के लिए retainer, defined deliverables के लिए project pricing, और कभी-कभी performance deal जब fit असली हो।
घंटों के बिना कीमत कैसे तय करें
आप अब भी लागत को floor की तरह इस्तेमाल कर सकते हैं, भले ही वह आधार होना बंद हो जाए। जिस senior समय और workflow को आप commit कर रहे हैं उसकी पूरी लागत आँकें, जो margin चाहिए वह जोड़ें, और उसे एक floor मानें जिसके नीचे काम लेने लायक़ नहीं। फिर value से कीमत तय करें — outcome का client के लिए क्या मूल्य है — और floor price होना बंद कर के एक ऐसी line बन जाता है जिसे आप पार नहीं करते।
व्यावहारिक सार: फ़ैसले की कीमत तय करें, delivery की लागत निकालें, और कभी पहले को दूसरे से तय न होने दें। अगर value-वाली कीमत आपके cost floor से नीचे है, तो काम एक misfit है, discount का मौक़ा नहीं। अगर वह बहुत ऊपर है, तो आपने वह जगह पाई जहाँ judgment सचमुच पैसे लेने लायक़ है — जो पूरे model का मक़सद है।
Pitch में क्या बदलता है
Outcome pricing बदलता है कि आप कैसे बेचते हैं, सिर्फ़ कैसे invoice करते हैं नहीं। एक team और price list की जगह, आप फ़ैसला और outcome पेश करते हैं, और समझाते हैं कि senior judgment plus एक workflow एक बड़ी team से बेहतर दाँव क्यों है। यह एक कठिन pitch है procurement-driven buyer के लिए, जो hourly rates compare करने में trained है, और एक आसान pitch उस client के लिए जो धीमे और महँगे काम से जला हुआ है। इससे पहले कि आप model से lead करें, जानें कि आप किस buyer के सामने हैं।
Pitch में दूसरा बदलाव यह है कि कीमत में क्या शामिल है इस पर ईमानदार हों। एक retainer price को पहुँच और ज़िम्मेदारी का नाम लेना चाहिए, वरना client उसे एक unlimited बाल्टी मानेगा। Project pricing को outcome और exclusions का नाम लेना चाहिए। एक कीमत ख़ुद को तभी बचाती है जब buyer ठीक-ठीक देखे कि वह क्या ख़रीद रहा है और क्या नहीं।
Scope का सवाल
Outcome pricing numbers में नहीं, scope में सबसे ज़्यादा fail होती है। एक vague outcome client को उसे बढ़ाने का न्योता देता है, और हर विस्तार वह काम है जिसकी आपने कीमत नहीं तय की। सुधार यह है कि deliverable, constraints, और क्या साफ़ तौर पर scope से बाहर है, यह कीमत की उसी साँस में तय करें। "Campaign के लिए एक measurement design" का scope है; "measurement में हमारी मदद करें" का नहीं।
यह वही discipline है जो agency design framework services पर लागू करता है: जानें कि client output के अलावा किस चीज़ के पैसे दे रहा है। एक कीमत तभी ख़ुद को बचाती है अगर outcome defined हो। एक vague scope वाली fixed price outcome pricing नहीं है; यह एक बिना सीमा का एहसान है।
बचत कहाँ जाती है
AI जो मूल्य बनाता है — पुरानी और नई delivery लागत के बीच का फ़र्क़ — उसे कहीं जाना है। आप वह सब client को सस्ते काम की तरह दे सकते हैं, सब margin की तरह रख सकते हैं, या बाँट सकते हैं। तीनों defensible हैं, लेकिन जान-बूझकर चुनें। सब दे देना आपको commodity बना देता है और एक दौड़ को तल की तरफ़ न्योता देता है। सब रखना तब तक काम करता है जब तक client ध्यान न दे और पूछे कि कीमत क्यों नहीं हिली। इसे बाँटना अक्सर टिकाऊ जवाब है: client को बेहतर deal मिलता है, आप बेहतर margin रखते हैं, और relationship अगली procurement review से बच जाती है।
ग़लती बिना पहले redesign किए बाँटना है। अगर आप delivery दोबारा बनाने से पहले कीमत घटाते हैं, तो आप वह margin दे रहे हैं जो आपके पास कभी था ही नहीं। Workflow redesign करें, नई cost structure confirm करें, और फिर तय करें कि बढ़त कैसे बाँटें। एजेंसी सस्ती है या नहीं वाला सवाल उस बँटवारे में और गहरा जाता है।
सोमवार को क्या करें
अपनी मौजूदा price list लें और हर service को judgment-led या production-led mark करें। Judgment-led काम retainer या outcome pricing की तरफ़ जाता है; production-led काम वहीं है जहाँ आप घंटे वाले trap के सबसे ज़्यादा exposed हैं और उसे पहले reprice या reposition करना चाहिए। फिर हर service के लिए एक cost floor बनाएँ ताकि आपको वह line पता हो जिसे पार नहीं करना।
आख़िर में, अगली proposal का outcome एक ऐसे वाक्य में लिखें जिसे client दोहरा सके। अगर आप नहीं कर सकते, तो scope price के लिए तैयार नहीं है, और कोई pricing model उसे नहीं बचाता।
FAQ
क्या हमें घंटे वाली बिलिंग पूरी तरह छोड़ देनी चाहिए?
ज़रूरी नहीं, लेकिन इसे सचमुच अनिश्चित काम के लिए fallback मानें, default नहीं। घंटे अब भी तब उपयोगी हैं जब दोनों पक्ष पहले से एक outcome define न कर सकें। लक्ष्य outcome pricing या retainer को default और घंटों को exception बनाना है।
जब client घंटों पर ज़ोर दे तो कीमत कैसे तय करें?
Senior समय की कीमत तय करें, production की नहीं। अगर client सिर्फ़ घंटे ख़रीदना चाहता है, तो judgment को एक ऐसी rate पर charge करें जो उसकी दुर्लभता दर्शाए और model की रफ़्तार को एक अदृश्य efficiency रहने दें जिसे आप list नहीं करते। Production की बचत को कम rate में न बदलें।
अगर client तुरंत discount माँगे?
Outcome price पर discount एक scope की बातचीत है, price की नहीं। पूछें कि outcome का कौन-सा हिस्सा वे छोड़ना चाहते हैं, या कौन-सी constraint ढीली करना चाहते हैं। Scope बदले बिना delivery की कीमत घटाना बस काम को आपके floor के नीचे खिसका देता है।
क्या एक छोटी एजेंसी performance pricing इस्तेमाल कर सकती है?
सिर्फ़ वहाँ जहाँ outcome मापने लायक़, attributable और आपके control में हो। एक छोटा shop जिसके पास अपने काम की साफ़ दृष्टि है वह इसे अच्छे से इस्तेमाल करता है; जिसके पास वह दृष्टि नहीं वह एक ऐसा risk ले रहा है जिसे वह manage नहीं कर सकता। Retainer और project से शुरू करें, और performance deal का हक़ कमाएँ।
Short version
Judgment और outcomes की कीमत तय करें, घंटों की नहीं, क्योंकि AI ने समय और लागत के बीच का link तोड़ दिया। Decision layer के लिए retainer, defined outcomes के लिए project pricing, और performance deals सिर्फ़ वहाँ जहाँ measurement ईमानदार हो। Delivery की लागत निकालें, value की कीमत तय करें, और कभी दूसरे को पहले से तय न होने दें। Agency-Model guide बाक़ी cover करता है, और for-agencies track price और structure लाती है।
कीमत वह जगह है जहाँ एक एजेंसी की strategy दिखती है। अगर आप घंटों से निकल चुके हैं, तो मैं सुनना चाहूँगा कि जब आपने ऐसा किया तो clients ने क्या कहा।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी, जापानी, सरलीकृत चीनी और कोरियाई में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।