12 ਜੂਨ 2025·8 ਮਿੰਟ
Shantanu Narayen ਅਤੇ Adobe ਦਾ SaaS ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮਾਡਲ ਵੱਲ਼ ਬਦਲਾਅ
Shantanu Narayen ਨੇ Adobe ਨੂੰ boxed ਸਾਫਟਵੇਅਰ ਤੋਂ subscriptions ਵੱਲ ਕਿਵੇਂ ਮੋੜਿਆ—ਅਤੇ ਕਿਹੜੀਆਂ ਪ੍ਰੋਡਕਟ, ਕੀਮਤ, ਅਤੇ go-to-market ਚੋਣਾਂ ਨੇ ਇਹ ਤਬਦੀਲੀ ਟਿਕਾਊ ਬਣਾਈ।
Shantanu Narayen ਨੇ Adobe ਨੂੰ boxed ਸਾਫਟਵੇਅਰ ਤੋਂ subscriptions ਵੱਲ ਕਿਵੇਂ ਮੋੜਿਆ—ਅਤੇ ਕਿਹੜੀਆਂ ਪ੍ਰੋਡਕਟ, ਕੀਮਤ, ਅਤੇ go-to-market ਚੋਣਾਂ ਨੇ ਇਹ ਤਬਦੀਲੀ ਟਿਕਾਊ ਬਣਾਈ।
Adobe ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਕਹਾਣੀ ਨਹੀਂ ਸੀ। ਦਹਾਕਿਆਂ ਤੱਕ ਇਹ boxed products—Photoshop, Illustrator, InDesign—ਦੇ ਨਾਲ creative ਕੰਮ 'ਚ ਹਾਕਮ ਰਹੀ, ਜਿਹੜੀਆਂ ਮਹਿੰਗੀਆਂ ਇਕ-ਵਾਰੀ ਖਰੀਦਾਂ ਹਿੰਦੀਆਂ ਸਨ ਅਤੇ ਗਾਹਕ ਹਰ ਕੁਝ ਸਾਲਾਂ ਬਾਅਦ upgrade ਕਰਦੇ ਸਨ। ਇਹ ਮਾਡਲ ਇੱਕ ਮਜ਼ਬੂਤ ਬ੍ਰਾਂਡ ਬਣਾਉਂਦਾ ਸੀ, ਪਰ ਇਹ ਗਾਹਕਾਂ ਨੂੰ "ਇੱਕ ਵਾਰੀ ਖਰੀਦੋ, ਫਿਰ ਉਡੀਕ ਕਰੋ, ਫਿਰ ਅਪਗਰੇਡ ਕਰੋ" ਦੀ ਆਦਤ ਦਿਵਾਉਂਦਾ ਸੀ, ਜਿਸ ਨਾਲ Adobe ਵੱਡੀਆਂ ਲਾਂਚ ਸਾਈਕਲਾਂ ਅਤੇ ਅਸਮਾਨ ਆਮਦਨੀ 'ਤੇ ਨਿਰਭਰ ਹੋ ਗਿਆ।
ਜੋ ਬਦਲਾਅ Shantanu Narayen ਨੇ ਅੱਗੇ ਕੀਤਾ ਉਹ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵਰਣਨ ਕਰਨ ਲਈ ਆਸਾਨ, ਪਰ ਅਮਲ ਵਿੱਚ ਔਖਾ ਸੀ: perpetual licenses ਤੋਂ recurring subscriptions ਵੱਲ ਜਾਣਾ। ਡਾਊਨਲੋਡ ਜਾਂ ਡਿਸਕ ਵੇਚਣ ਦੀ ਬਜਾਏ, Adobe ਮਹੀਨੇ-ਬ-ਮਹੀਨੇ ਆਮਦਨੀ ਕਮਾਉਣ ਲੱਗਿਆ—ਸਿਰਫ ਜੇ ਗਾਹਕ ਮੁੱਲ ਨੂੰ ਜਾਰੀ ਰੱਖਣ।
ਮਾਰਕੀਟ ਲੀਡਰ ਲਈ ਬਿਜ਼ਨਸ ਮਾਡਲ ਬਦਲਣਾ ਮੌਜੂਦਾ ਚਲਦੇ ਕੰਮ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਨਾਲ ਵਿਰੋਧ ਹੋ ਸਕਦਾ ਹੈ (ਸਾਫਟਵੇਅਰ "ਕਿਰਾਏ" ਨੇਹੀ ਹੋ ਰਿਹਾ), churn ਆ ਸਕਦਾ ਹੈ ਜੇ ਉਤਪਾਦ ਕਾਫੀ ਤੇਜ਼ ਨਹੀਂ ਹੋਇਆ, ਅਤੇ ਇੱਕ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਸਮਾਂ ਆ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਲਾਇਸੰਸ ਆਮਦਨੀ ਘਟਦੀ ਹੈ ਪਹਿਲਾਂ ਕਿ subscription ਆਮਦਨੀ ਉੱਪਰ ਆਵੇ।
ਉਤੇ ਹੀ, ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਅੰਦਰੂਨੀ ਤਬਦੀਲੀ ਲਿਆਉਂਦੀਆਂ ਹਨ। ਪ੍ਰੋਡਕਟ, ਫਾਇਨੈਂਸ, ਸਪੋਰਟ ਅਤੇ ਸੇਲਜ਼—ਸਭ ਨੂੰ ਹੁਣ retention 'ਤੇ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ—ਸਿਰਫ ਨਵੀਆਂ ਡੀਲਾਂ ਨਹੀਂ।
ਇਹ ਸੈਕਸ਼ਨ ਤੁਹਾਡੇ ਲਈ ਕਹਾਣੀ ਅਤੇ ਸਬਕਾਂ ਦਾ ਨਕਸ਼ਾ ਹੈ। ਤੁਸੀਂ ਵੇਖੋਗੇ:
ਵੱਸ ਸਮਾਪਤ 'ਤੇ, ਤੁਸੀਂ ਸਮਝ ਜਾਵੋਗੇ ਕਿ Adobe ਨੇ ਇਕ ਜੋਖਿਮਭਰਿਆ ਦਾਅ ਕਿਵੇਂ ਇੱਕ ਟਿਕਾਊ SaaS ਬਿਜ਼ਨਸ ਮਾਡਲ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ—ਅਤੇ SaaS ਅਤੇ product-led ਟੀਮਾਂ ਕੀ ਲੈ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ Adobe ਬਣਨ ਦੇ।
Adobe ਦਾ boxed-software ਦੌਰ ਉਸ ਦੁਨੀਆ ਲਈ ਬਣਿਆ ਸੀ ਜਿੱਥੇ ਉਤਪਾਦ ਡਿਸਕਾਂ 'ਤੇ ਰਿਲੀਜ਼ ਹੁੰਦੇ ਸਨ, ਅੱਪਡੇਟ ਘੱਟ ਹੁੰਦੇ ਸਨ, ਅਤੇ ਰੀਟੇਲ/ਰਿਸેલਰ ਚੈਨਲ ਸਾਫਟਵੇਅਰ ਵਰਗੇ ਹੀ ਮਹੱਤਵਪੂਰਨ ਸਨ। ਉਹ ਮਾਡਲ ਵੱਡੀਆਂ ਲਾਂਚਾਂ ਲਈ optimize ਕਰਦਾ ਸੀ—ਅਤੇ ਇਹ ਨਤੀਜੇ ਦਿਖਾਉਂਦਾ ਸੀ।
Boxed software ਲੰਬੇ ਰਿਲੀਜ਼ ਸਾਈਕਲਾਂ ਨੂੰ inaam ਦਿੰਦਾ ਸੀ। ਟੀਮਾਂ ਮਹੀਨਿਆਂ ਜਾਂ ਸਾਲਾਂ ਲੱਗਾ ਕੇ ਫੀਚਰਾਂ ਨੂੰ ਇਕ "ਮੁੱਖ ਵਰਜਨ" ਵਿੱਚ ਪੈਕ ਕਰ ਸਕਦੀਆਂ ਸਨ, ਫਿਰ ਅਪਗਰੇਡ ਨੂੰ ਇੱਕ ਇਵੈਂਟ ਵਾਂਗ ਪ੍ਰਚਾਰ ਕੀਤਾ ਜਾਂਦਾ। ਸੇਲਜ਼ ਵੀ ਉਸੀ ਰਿਥਮ 'ਤੇ ਚੱਲਦੇ: ਰਿਲੀਜ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਜ਼ੋਰ ਵਾਲੇ ਕਵਾਰਟਰ, ਭਾਰੀ ਚੈਨਲ ਪ੍ਰੋਮੋਸ਼ਨ, ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਮੁੜ-ਭੁਗਤਾਨ ਕਰਨ ਲਈ ਮਨਾਉਣ ਵਿੱਚ ਬਹੁਤ ਏਨਰਜੀ।
ਇਸ ਨਾਲ ਅਪਗਰੇਡ ਦਬਾਅ ਵੀ ਬਣਦਾ ਸੀ। ਨਵੇਂ ਟੂਲ, ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ, ਜਾਂ ਫਾਈਲ ਕੰਪੈਟਬਿਲਟੀ ਲਈ ਤੁਸੀਂ ਅਕਸਰ ਨਵੇਂ ਬਾਕਸ ਵੱਲ ਧਕੇਲੇ ਜਾਂਦੇ—ਅਕਸਰ Adobe ਦੀ ਟਾਇਮਲਾਈਨ ਉੱਤੇ ਜ਼ਿਆਦਾ ਅਤੇ ਗਾਹਕ ਦੀ ਉੱਤੇ ਘੱਟ।
ਗਾਹਕਾਂ ਲਈ ਦਰਦ ਮੁੱਖ ਤੌਰ 'ਤੇ ਅਗੇਦਾ ਖਰਚ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਸੀ। ਪੂਰੀ suite ਖਰੀਦਣ ਦਾ ਮਤਲਬ ਇੱਕ ਵੱਡਾ ਇਕ-ਵਾਰੀ ਖਰਚ—freelancers, students ਅਤੇ ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਜੱਟੀ ਸਮਝ ਨਹੀਂ ਆਉਂਦਾ।
ਫਿਰ ਆਉਂਦੀ ਹੈ ਵਰਜਨ fragmentation: ਇੱਕ ਵਰਜਨ ਵਿੱਚ ਬਣਾਈ ਫਾਈਲ ਦੂਜੇ ਵਿੱਚ ਹਮੇਸ਼ਾ ਠੀਕ ਨਾ ਚੱਲਣ, ਟੀਮਾਂ sync ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਣ, ਅਤੇ "ਤੁਸੀਂ ਕਿਹੜੇ ਵਰਜਨ 'ਤੇ ਹੋ?" ਵਰਗਾ ਪ੍ਰਸ਼ਨ ਅਸਲਵੌਰ 'ਤੇ ਵਰਕਫਲੋ ਵਿੱਚ ਆ ਜਾਣਾ।
ਕੰਪਲਾਇੰਸ ਵੀ ਇੱਕ ਸਿਰਦਰ ਦਰਦ ਸੀ। ਫ਼ਿਜ਼ੀਕਲ ਲਾਇਸੰਸ ਅਤੇ ਸੀਰੀਅਲ ਨੰਬਰ ਗਲਤ ਮੈਨੇਜ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਸੰਗਠਨਾਂ ਨੂੰ audits ਅਤੇ ਕੰਟਰੋਲਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਪੈਂਦਾ ਸੀ।
Adobe ਲਈ ਆਮਦਨੀ ਲਹਿਰਾਂ-ਲਹਿਰਾਂ ਵਾਲੀ ਸੀ। ਮੁੱਖ ਰਿਲੀਜ਼ਾਂ ਨੇ spike ਬਣਾਏ, ਫਿਰ ਸ਼ਾਂਤ ਸਮੇਂ ਆਉਂਦੇ—ਜਿਸ ਨਾਲ ਫੋਰਕਾਸਟਿੰਗ ਮੁਸ਼ਕਲ ਅਤੇ ਯੋਜਨਾ ਬਣਾਉਣਾ ਖਤਰਨਾਕ ਹੋ ਗਿਆ।
ਇਸੇ ਸਮੇਂ, ਮੁਕਾਬਲਾ ਬਦਲ ਰਿਹਾ ਸੀ। ਘੱਟ-ਕੀਮਤ ਵਾਲੇ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਰ ਰਹੇ ਸਨ, ਅਤੇ piracy ਨੇ paid upgrades ਨੂੰ ਘਟਾਇਆ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਗਾਹਕ "ਬਾਕਸ" ਨੂੰ ਇਕ-ਵਾਰੀ ਖਰੀਦ ਵਾਂਗ ਵੇਖਦੇ।
ਇਹ ਸਾਰਾ ਮੌਕਾ ਬਣਾਉਂਦਾ ਹੈ: continuous delivery (ਜਦ ਮੁੱਲ ਤਿਆਰ ਹੁੰਦੀ ਭੇਜੋ) ਅਤੇ predictable recurring revenue (ਜੋ ongoing ਸੁਧਾਰਨਾ ਫੰਡ ਕਰੇ ਅਤੇ ਗਾਹਕ ਨਤੀਜਿਆਂ ਨਾਲ aligned ਰਹੇ)।
Adobe ਦਾ boxed ਤੋਂ subscriptions ਵੱਲ ਜਾਣਾ صرف ਇੱਕ ਪ੍ਰੋਡਕਟ ਫੈਸਲਾ ਨਹੀਂ ਸੀ—ਇਹ ਸਾਰੀ ਕੰਪਨੀ ਦਾ ਓਪਰੇਟਿੰਗ ਬਦਲਾਅ ਸੀ। Narayen ਦਾ ਯੋਗਦਾਨ ਇੱਕ ਇਕਲੌਤੇ "ਦ੍ਰਿਸ਼ਟੀ" ਤੋਂ ਘੱਟ ਅਤੇ ਬਹੁਤ ਸਾਲਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਸਥਿਰ ਚੋਣਾਂ ਕਰਨ ਦੇ ਲਾਇਕ ਸਥਿਤੀਆਂ ਬਣਾਉਣ ਵੱਧ ਬਾਰੇ ਸੀ।
Subscription ਸਵਿੱਚ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਸਜ਼ਾ ਦਿੰਦੀ ਹੈ (ਆਮਦਨੀ ਦੀ ਸਮਾਂ-ਲਾਗਤ, ਰਿਪੋਰਟਿੰਗ ਓਪਟਿਕਸ, ਸੇਲਜ਼ ਡਿਸਰਪਸ਼ਨ) ਫਿਰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ। ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਇਹ ਇੱਕ ਕਈ ਸਾਲਾਂ ਦੀ ਸ਼ਰਤ ਵਜੋਂ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਦੇ ਨਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ ਮੀਲ-ਪੱਥਰ ਹੋਣ—ਨ ਕਿ ਇਕ ਕਵਾਰਟਰ-ਟੁ-ਕਵਾਰਟਰ ਪ੍ਰਯੋਗ। ਇਹ ਮਨੋਰਥ ਟੀਮਾਂ ਨੂੰ ਬੁਨਿਆਦੀ ਨਿਵੇਸ਼ (ਕਲਾਊਡ ਡਿਲਿਵਰੀ, identity, ਬਿਲਿੰਗ, ਟੈਲੀਮੈਟਰੀ) ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਇਹ ਸੋਚਣ ਦੇ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਨਤੀਜੇ ਬਿਹਤਰ ਹੀ ਨਜ਼ਰ ਆਉਣਗੇ।
ਕਿਸੇ ਇਕਸੇ ਰਣਨੀਤੀ ਨੂੰ ਦੋ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਨਿਵੇਸ਼ਕਾਂ ਲਈ: ਦੱਸੋ ਕਿ recurring revenue income statement ਕਿਵੇਂ ਬਦਲੇਗਾ ਅਤੇ ਕਿਉਂ ਨਜ਼ਦੀਕੀ ਵਿੱਚ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਆਮ ਹੈ। ਮਕਸਦ ਭਰੋਸੇਯੋਗਤਾ ਹੈ—ਸਾਫ਼ ਗਾਈਡੈਂਸ, ਲਗਾਤਾਰ ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਘੱਟ ਹੈਰਾਨੀਆਂ।
ਕਰਮਚਾਰੀਆਂ ਲਈ: ਦਰਸਾਓ ਕਿ "subscription" ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਿੱਚ ਕੀ ਮਾਣਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਕੀਮਤ ਨਹੀਂ; ਇਹ onboarding, ਅੱਪਡੇਟ, ਭਰੋਸੇਯੋਗਤਾ, ਅਤੇ ਗਾਹਕ ਨਤੀਜਿਆਂ ਲਈ ਜਵਾਬਦੇਹੀ ਹੈ।
Subscriptions ਨੇ ਪ੍ਰੋਡਕਟ, ਫਾਇਨੈਂਸ, ਅਤੇ ਸੇਲਜ਼ ਨੂੰ ਅਲੱਗ ਅਲੱਗ optimize ਕਰਨਾ ਰੋਕ ਦਿੱਤਾ।
ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਅਭਿਆਸ ਇਹ ਹੈ ਕਿ tradeoffs ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਇਆ ਜਾਵੇ—ਕੌਣ ਕਿਸ ਮੈਟ੍ਰਿਕ ਦਾ ਮਾਲਿਕ ਹੈ, handoffs ਕਿਵੇਂ ਹੁੰਦੇ, ਅਤੇ ਕੀ deprioritize ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਮਾਡਲ ਸਵਿੱਚ ਦੌਰਾਨ, ਨੇਤਾ ਅਕਸਰ "ਚੰਗਾ ਲੱਗਣਾ" ਅਤੇ "ਸਹੀ ਹੋਣਾ" ਵਿਚੋਂ ਚੋਣ ਕਰਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ discounting ਨੂੰ ਰੋਕਣਾ ਜੋ ਗਾਹਕਾਂ ਨੂੰ انتظار ਸਿੱਖਾ ਦੇਵੇ, customer success ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਭਾਵੇਂ ਲਾਗਤ ਵਧੇ, ਜਾਂ reliability ਠੀਕ ਕਰਨ ਲਈ ਫੀਚਰ ਕੰਮ ਨੂੰ ਰੋਕਨਾ।
ਟਿਕਾਊ ਚਾਲ ਇਹ ਹੈ ਕਿ trust ਅਤੇ retention ਦੀ ਰੱਖਿਆ ਕਰੋ, ਕਿਉਂਕਿ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਵਿੱਚ ਗਾਹਕ ਹਰ ਮਹੀਨੇ ਵੋਟ ਕਰਦੇ ਹਨ।
ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਉਸ ਵੇਲੇ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਗਾਹਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਕਿ ਮੁੱਲ ਲਗਾਤਾਰ ਨਵਾਂ ਹੋ ਰਿਹਾ ਹੈ। Adobe ਦਾ ਦਾਅ ਇਹ ਨਹੀਂ ਸੀ "ਸਾਡੇ ਲਈ ਸਦਾ ਪੈਸਾ ਦਿਓ ਉਸੇ ਟੂਲ ਲਈ।" ਇਹ ਇੱਕ ਸਾਫ਼ ਮੁੱਲ-ਬਦਲੇ ਦਾ ਵਾਅਦਾ ਸੀ: ਲਗਾਤਾਰ ਉਤਪਾਦ ਸੁਧਾਰਾਂ ਨਾਲ ਨਾਲ ਉਹ ਸੇਵਾਵਾਂ ਜੋ ਸਿਰਫ਼ ਹਮੇਸ਼ਾ ਚਲਦੀਆਂ ਰਹਿਣ 'ਤੇ ਹੀ ਮੱਤ ਬਣਦੀਆਂ ਹਨ।
Creative Cloud ਹੇਠ, ਵਾਅਦਾ ਬਣਿਆ ਕਿ ਲਗਾਤਾਰ ਫਾਇਦਾ ਮਿਲੇਗਾ—ਨਵੇਂ ਫੀਚਰ, bug fixes, security patches, ਅਤੇ compatibility ਕੰਮ ਸਾਲ ਭਰ ਆਉਂਦਾ ਰਹੇਗਾ।
ਇਸੇ ਤਰ੍ਹਾਂ ਮਹੱਤਵਪੂਰਨ ਸਨ ਕਲਾਊਡ ਸੇਵਾਵਾਂ: ਡਿਵਾਈਸਾਂ ਦਰਮਿਆਨ ਫਾਈਲਾਂ ਅਤੇ ਸੈਟਿੰਗਸ ਦਾ sync, shared libraries, ਫੋਂਟ ਪਹੁੰਚ, collaboration ਵਰਕਫਲੋ, ਅਤੇ ਟੀਮਾਂ ਲਈ ਖਾਤਾ-ਸਤਹ ਮੈਨੇਜਮੈਂਟ। ਸਪੋਰਟ ਅਤੇ ਐਡਮਿਨ ਕੰਟਰੋਲ ਵੀ ਹੁਣ ਉਸਦੀ ਭੁਗਤਾਨ ਦਾ ਹਿੱਸਾ ਬਣ ਗਏ, ਨਾ ਕਿ ਇਕ-ਵਾਰੀ ਐਡ-ਆਨ।
Bundles ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਨੂੰ ਜਾਇਜ਼ ਬਣਾਉਣ ਵਿੱਚ ਆਸਾਨੀ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਇੱਕ suite (Creative Cloud) ਪ੍ਰਤੀਤ ਮੁੱਲ ਵਧਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਪਭੋਗੀਆਂ ਨੂੰ ਅਗਲੇ ਮਹੀਨੇ ਕਿਹੜੀ ਐਪ ਦੀ ਲੋੜ ਪਵੇਗੀ ਇਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲੱਗਣਾ ਪੈਂਦਾ। ਡਿਜ਼ਾਈਨਰ ਮੁੱਖ ਤੌਰ 'ਤੇ Photoshop ਵਰਤ ਸਕਦੇ ਹਨ, ਪਰ Illustrator, InDesign, ਅਤੇ After Effects ਦਾ "ਲਭਣਯੋਗ ਹੋਣਾ" ਯੋਜਨਾ ਨੂੰ creative ਕੰਮ ਲਈ ਇਕ ਬੀਮਾ ਬਣਾਉਂਦਾ ਹੈ।
ਇਹ suite ਮੁੱਲ ਇੱਕਲ-ਐਪ ਦੀ ਕੀਮਤ ਨੂੰ ਪਿਛਲੇ ਇਕ-ਵਾਰੀ ਖਰੀਦ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਦਾ ਦਰਦ ਘਟਾਉਂਦਾ ਹੈ।
Subscriptions ਸ਼ੁਰੂਆਤੀ ਰੁਕਾਵਟ ਘਟਾਉਂਦੇ ਹਨ। ਵੱਡੇ ਭੁਗਤਾਨ ਅਤੇ ਮੁੱਖ ਵਰਜਨ ਫੈਸਲੇ ਦੀ ਥਾਂ, ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ, ਮਹੀਨਾਵਾਰ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਜ਼ਰੂਰਤ ਮੁਤਾਬਿਕ ਵਧ ਜਾਂ ਘਟ ਕਰ ਸਕਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ students, freelancers, ਅਤੇ ਛੋਟੀ ਟੀਮਾਂ ਲਈ।
ਗਾਹਕ ਫਿਕਰ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਆਪਣਾ ਕੰਮ ਖੋ ਦੇਣਗੇ, ਫਾਈਲ ਫਾਰਮੈਟ ਵਿੱਚ ਫਸ ਜਾਣਗੇ, ਜਾਂ ਕੀਮਤ ਵਧੇਗੀ। ਉਲਟ-ਤੱਤ ਵਾਜਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: predictable billing, ਸਾਫ਼ cancellation ਰਸਤੇ, ਮਜ਼ਬੂਤ backward/forward compatibility, ਅਤੇ ਲਗਾਤਾਰ ਸੁਧਾਰ ਜੋ ਦਿੱਖਵਾਂ ਲੱਗਣ—ਗੁੰਝਲਦਾਰ ਨਿਕਾਰਾਤਮਕ ਨਹੀਂ।
Adobe ਸਿਰਫ਼ "ਬਾਕਸ ਨੂੰ ਇੰਟਰਨੈਟ 'ਤੇ ਰੱਖ" ਨਹੀਂ ਸਕਦੀ। ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੇ ਪੇਸ਼ਕਸ਼ ਦੀ ਸੁਧਾਰ ਲਿਆਈ: ਗਾਹਕ ਕੀ ਖਰੀਦ ਰਿਹਾ, ਕਿਵੇਂ ਵਿਕਲਪ ਤੁਲਨਾਤਮਕ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਉਹ ਸਮੇਂ ਨਾਲ ਅਪਗ੍ਰੇਡ ਕਰਦੇ ਹਨ।
Boxed ਦੌਰ ਵਿਚ ਮੁੱਲ ਅਕਸਰ ਵੱਡੇ suites ਵਿੱਚ ਬੰਨ੍ਹਿਆ ਹੁੰਦਾ ਸੀ (ਅਤੇ ਵੱਡੇ ਕੀਮਤ-ਟੈਗ). Creative Cloud ਨਾਲ, packaging ਇੱਕ ਛੋਟੀ-ਸੈੱਟ ਦੀ ਪਛਾਣਯੋਗ ਯੋਜਨਾ ਵੱਲ ਵਧੀ: single apps, all-apps suite, ਅਤੇ students, individuals, teams, enterprise ਵਰਗੀਆਂ audiences ਲਈ tailored ਵਰਜਨ।
ਚਾਲਾਕੀ ਇਹ ਹੈ ਕਿ ਸਾਦਗੀ ਅਤੇ ਲਚੀਲਾਪਨ ਵਿਚ ਸਾਂਤੁਲਨ ਰੱਖੋ। ਇਕ ਸਾਫ਼ tier structure ਪਹਿਲਾ ਸਵਾਲ ਪੁੱਛਦਾ—"ਮੇਰੇ ਲਈ ਕਿਹੜਾ ਪਲਾਨ ਹੈ?"—ਜਦਕਿ add-ons ਦੂਜਾ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦੇ—"ਮੈਂ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਕਿਵੇਂ ਵਧਾ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?" Add-ons ਉਹ ਲੋੜਾਂ ਕਵਰ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਹਰ ਟੀਅਰ ਵਿਚ ਨਹੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ (ਜਿਵੇਂ extra storage, advanced admin controls, collaboration features, stock assets), ਤਾਂ ਕਿ ਬੇਸ ਪਲਾਨ ਸਾਦੇ ਰਹਿਣ।
Subscriptions ਉਸ ਵੇਲੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦ ਲੋਕ ਛੋਟੀ ਸ਼ੁਰੂਆਤ ਕਰ ਸਕਣ। free trials ਅਤੇ ਘੱਟ-ਕੀਮਤ ਐਂਟਰੀ ਪਲਾਨ switching ਦਾ ਖ਼ਤਰਾ ਘਟਾਉਂਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਲਈ ਜੋ perpetual licenses ਵਰਤਣ ਦੇ ਆਦੀ ਹਨ।
Trials ਵਿਕਰੀ ਨੂੰ persuasion ਤੋਂ experience ਵੱਲ ਖੁਸਲ ਕਰਦੇ ਹਨ: ਉਤਪਾਦ ਨੇ ਆਪਣੀ ਕੀਮਤ ਤੇਜ਼ੀ ਨਾਲ ਸਾਬਤ ਕਰਨੀ ਹੁੰਦੀ ਹੈ।
ਕਦਰ-ਬਦਲਾਅ ਗਾਹਕਾਂ ਨੂੰ ਸਜ਼ਾ ਲਾਉਂਦੇ ਹਨ ਜੇ Loyal customers ਨੂੰ ਸਜ਼ਾ ਮੰਹੂਸ ਹੋਵੇ। ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦੇ ਹਨ: grace periods, migration ਲਈ ਸਮੇਂ-ਬੱਧ incentives, ਅਤੇ ਸਾਫ਼ credit/discount ਨੀਤੀਆਂ।
ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ conversion 'ਚ ਜੀਤੇ; ਇਹ ਹੈ ਰਿਸ਼ਤਾ ਬਣਾਈ ਰੱਖਣਾ ਜਦ ਗਾਹਕ ਆਪਣੇ ਬਜਟਿੰਗ ਅਤੇ ਵਰਕਫਲੋ ਅਨੁਕੂਲ ਕਰਦੇ ਹਨ।
ਜਿਵੇਂ ਟੀਮਾਂ ਟੀਅਰ, ਬੰਡਲ, ਅਤੇ ਪ੍ਰੋਮੋਸ਼ਨ ਸ਼ਾਮਿਲ ਕਰਦੀਆਂ ਹਨ, SKU sprawl ਅਸਾਨੀ ਨਾਲ ਸਪਸ਼ਟਤਾ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। ਵਰਤੋਂ ਯੋਗ ਗਾਰਡਰੇਲ: ਹਰ ਨਵੇਂ ਪਲਾਨ ਦਾ ਨਿਸ਼ਾਨਾ ਕਿਸੇ ਵਿਲੱਖਣ ਸੈਗਮੈਂਟ ਜਾਂ job-to-be-done ਨਾਲ ਖ਼ਾਸ ਹੋਵੇ, ਅਤੇ ਜੋ ਕੁਝ ਇਕ ਪੈਰਾ ਲਿਖਕੇ ਸਮਝਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਉਹ ਸ਼ਾਇਦ add-on ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਜਾਂ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
Boxed software ਤੋਂ subscription ਮਾਡਲ ਵੱਲ ਜਾਣ ਨਾਲ ਉਤਪਾਦ ਬਣਾਉਣ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੀ ਮੁੜ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ। ਇਕ ਵਾਰ ਸਾਲਾਨਾ "ਵੱਡੀ ਰਿਲੀਜ਼" ਤੇ ਨਿਵੇਸ਼ ਕਰਨ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਨੂੰ ਛੋਟੇ, ਵਾਰੀ-ਵਾਰੀ increments 'ਚ ਮੁੱਲ ਪਹੁੰਚਾਉਣਾ ਪੈਂਦਾ ਹੈ—ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਅਸਲ ਰਹਿਣ ਬਿਨਾਂ ਗਾਹਕਾਂ ਦਾ ਭਰੋਸਾ ਤੋੜੇ।
ਵੱਡੀ-ਰਿਲੀਜ਼ ਦੀ ਦੁਨੀਆ ਵਿੱਚ, roadmap ਇੱਕ ਲੰਮਾ ਚੱਕਰ ਹੁੰਦਾ: features ਦਾ ਵੱਡਾ ਸੈੱਟ scope ਕਰੋ, ਓਹਨਾਂ ਨੂੰ lock ਕਰੋ, ਫਿਰ ਜਾਂਚੋ ਅਤੇ ship ਕਰੋ। continuous delivery ਇਸ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਰੋਡਮੈਪ ਜੀਵੰਤ ਦਸਤਾਵੇਜ਼ ਬਣ ਜਾਂਦਾ ਹੈ, ਕੰਮ ਨੂੰ shippable ਟੁਕੜਿਆਂ ਵਿੱਚ ਤੋੜਿਆ ਜਾਂਦਾ ਹੈ ਜੋ test, release, refine, ਜਾਂ rollback ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਇਸ ਨਾਲ ਟੀਮਾਂ ਲਈ success ਦੀ ਪਰਿਭਾਸ਼ਾ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਹੁਣ ਸਵਾਲ ਹੁੰਦਾ ਹੈ: "ਕੀ ਗਾਹਕਾਂ ਨੂੰ ਲਗਾਤਾਰ ਮੌਲਿਕ ਸੁਧਾਰ ਮਿਲ ਰਹੇ ਹਨ—ਅਤੇ ਕੀ ਉਹ ਸਥਿਰ ਹੋ ਰਹੇ ਹਨ?" ਨਾ ਕਿ "ਕੀ ਅਸੀਂ ਨਵਾਂ ਵਰਜਨ ਸਮੇਂ ਤੇ ship ਕੀਤਾ?"
ਜਦ ਸਾਫਟਵੇਅਰ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਅਤੇ ਲਗਾਤਾਰ ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ, reliability ਦੀ ਉਮੀਦ ਵਧ ਜਾਂਦੀ ਹੈ। ਗਾਹਕ ਸਿਰਫ਼ ਫੀਚਰਾਂ ਨੂੰ ਨਹੀਂ ਝਾਂਕਦੇ—ਉਹ uptime, performance, ਅਤੇ ਬਦਲਾਅ ਦੀ ਪੈਟਰਨ ਨੂੰ ਮੁੱਲਾਂਕਣ ਕਰਦੇ ਹਨ।
ਇਸ ਨਾਲ engineering ਨੂੰ ਬਿਹਤਰ release discipline ਵੱਲ ਧਕੇਲਿਆ ਜਾਂਦਾ ਹੈ (feature flags, staged rollouts, quick rollbacks) ਅਤੇ ਬਦਲਾਅ ਬਾਰੇ ਸਪਸ਼ਟ ਸੰਚਾਰ।
Subscriptions ਨਾਲ ਗਾਹਕਾਂ ਦਾ ਵਰਤੋਂ ਦਾ ਡੇਟਾ real time ਵਿੱਚ ਮਿਲਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰੋਡਕਟ ਫੈਸਲੇ usage data 'ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਅਨੁਮਾਨਾਂ 'ਤੇ। ਟੈਲੀਮੈਟਰੀ—ਕਿੰਨੀ ਵਾਰ ਫੀਚਰ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਲੋਕ ਕਿੱਥੇ ਫਸਦੇ ਹਨ, ਕੀ crash ਹੁੰਦਾ—ਇੱਥੇ ਮੁੱਖ ਇਨਪੁੱਟ ਬਣ ਜਾਂਦਾ ਹੈ।
ਗੁਣਾਤਮਕ ਫੀਡਬੈਕ (support tickets, community forums, enterprise account input) ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ ਇਹ ਇੱਕ ਤੰਗ ਲੂਪ ਬਣਾਉਂਦਾ ਹੈ: ship → measure → learn → adjust. ਮਕਸਦ surveillance ਨਹੀਂ; friction ਘਟਾਉਣਾ ਅਤੇ ਨਤੀਜੇ ਸੁਧਾਰਨਾ ਹੈ।
SaaS ਪੱਧਰ 'ਤੇ continuous delivery ਲਈ ਗ਼ੈਰ-ਦਿੱਖਣਯੋਗ ਪਰ ਗਹਿਰੇ platform ਨਿਵੇਸ਼ਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਗਾਹਕ ਵੱਖ-ਵੱਖ ਨਹੀ ਦੇਖਦੇ—ਜਦ ਤੱਕ ਕੁਝ fail ਨਾ ਹੋ ਜਾਵੇ। identity ਅਤੇ access management, billing systems, entitlements (ਕੌਣ ਕੀ ਵਰਤ ਸਕਦਾ ਹੈ), ਅਤੇ ਭਰੋਸੇਯੋਗ update mechanisms ਮੁੱਖ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇਹ ਸਮਰੱਥਾਵਾਂ packaging ਦੀ ਲਚੀਲਾਪਨ, trials, upgrades, downgrades, ਅਤੇ enterprise administration ਨੂੰ ਸੰਭਾਲਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਸਦਾ-ਕਨੈਕਟਿਡ ਉਤਪਾਦ ਨੂੰ ਸੁਰੱਖਿਆ ਅਤੇ ਗੋਪਨੀਯਤਾ ਇੱਕ ਇੱਕ-ਵਾਰੀ ਚੈੱਕਲਿਸਟ ਨਹੀਂ ਮੰਨਣੀ ਚਾਹੀਦੀ। ਇਸ ਵਿੱਚ secure authentication, ਧਿਆਨਪੂਰਵਕ ਡੇਟਾ ਹੈਂਡਲਿੰਗ, ਪਾਰਦਰਸ਼ੀ ਕੰਟਰੋਲ, ਅਤੇ compliance ਤਿਆਰੀ ਸ਼ਾਮਿਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਿਵੇਂ enterprise ਅਪਣਾਉਣ ਵੱਧਦਾ ਹੈ।
Boxed software ਤੋਂ subscriptions ਤੱਕ ਜਾਣ ਨੇ Adobe ਨੂੰ ਸੋਚਣ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਕਿ ਉਹ ਗਾਹਕਾਂ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ—ਅਤੇ "ਵੇਚਣਾ" ਦਾ ਮਤਲਬ ਹੁਣ ਕੀ ਹੈ। ਚੈਨਲ-ਭਾਰੀ ਯੁੱਗ ਵਿੱਚ, ਆਮਦਨੀ ਅਕਸਰ ਖਰੀਦ ਦੇ ਸਮੇਂ ਜਿੱਤੀ ਜਾਂਦੀ ਸੀ: ਇੱਕ ਰੀਟੇਲ ਬਾਕਸ, ਰੀਸੇਲਰ ਡੀਲ, ਜਾਂ ਵੱਡੀ ਅਪਗਰੇਡ ਸਾਈਕਲ। Creative Cloud ਅਤੇ subscriptions ਨਾਲ, ਕੇਂਦਰ ਗਾਹਕਾਂ ਨਾਲ ਡਾਇਰੈਕਟ ਰਿਸ਼ਤਿਆਂ ਵੱਲ ਸਧ ਗਿਆ ਜਿੱਥੇ ਮੁੱਲ ਮਹੀਨੇ-ਬ-ਮਹੀਨੇ ਸਾਬਤ ਹੋਣਾ ਲਾਜ਼ਮੀ ਸੀ।
Subscriptions ਉਹ ਵੇਲੇ ਸਭ ਤੋਂ ਚੰਗੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦ ਕੰਪਨੀ ਵਰਤੋਂ ਨੂੰ ਸਮਝ ਸਕੇ, ਗਾਹਕਾਂ ਨੂੰ ਤੇਜ਼ onboard ਕਰ ਸਕੇ, ਅਤੇ friction ਨੂੰ ਜਲਦੀ ਠੀਕ ਕਰ ਸਕੇ। ਇਸ ਨੇ Adobe ਨੂੰ ਵੱਧ direct ਰਸਤੇ ਵੱਲ ਧੱਕ ਦਿੱਤਾ—online ਖਰੀਦ, in-product prompts, account-based motions—ਜਦਕਿ partners ਵੱਧ ਤਰ services, implementation, ਅਤੇ enterprise procurement 'ਤੇ ਕੇਂਦਰਿਤ ਹੋ ਗਏ।
Direct relationships ਨਾਲ feedback loops ਛੋਟੇ ਹੋ ਗਏ। ਨਿਵੇਸ਼ ਕਰਨ ਲਈ ਅਗਲੀ ਮੁੱਖ ਰਿਲੀਜ਼ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਥਾਂ, Adobe ਵੇਖ ਸਕਦਾ ਸੀ ਕਿ ਕਿਹੜੇ ਫੀਚਰ ਅਪਨਾਏ ਜਾ ਰਹੇ, ਕਿੱਥੇ users churn ਕਰ ਰਹੇ, ਅਤੇ ਕਿਹੜੀਆਂ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਵਧੇਰੇ ਸਿੱਖਿਆ ਦੀ ਲੋੜ ਹੈ।
Subscription ਮਾਡਲ sales compensation ਅਤੇ ਯੋਜਨਾ ਨੂੰ ਮੁੜ-ਤਾਰਕੀਬੱਧ ਕਰਦਾ ਹੈ। ਕੋਟਾ ਅਤੇ incentives ਨੂੰ Annual Recurring Revenue (ARR), renewals, ਅਤੇ expansion—ਨਾ ਕਿ ਸਿਰਫ਼ new bookings—ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ:
ਜਦ incentives recurring outcomes ਨਾਲ ਮਿਲਦੇ ਹਨ, sales ਟੀਮ ਉਹ ਗਾਹਕ ਪ੍ਰਾਇਰਿਟਾਈਜ਼ ਕਰਦੀਆਂ ਹਨ ਜੋ ਰਹਿਣ ਅਤੇ ਵੱਧਣਗੇ—ਨਾ ਕਿ ਸਿਰਫ਼ ਉਹ ਜੋ ਅੱਜ ਖਰੀਦਣਗੇ।
Subscriptions ਵਿੱਚ renewals ਆਮਦਨੀ ਹਨ, ਨਾ ਕਿ ਇਕ ਬਾਦ ਦੀ ਗੱਲ। Customer success support-as-cost-center ਤੋਂ growth ਲਈ ਇੱਕ ਲੀਵਰ ਬਣ ਜਾਂਦੀ ਹੈ—onboarding, adoption, ਅਤੇ proactive ਮਦਦ ਜੋ churn ਦੇ ਖ਼ਤਰੇ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਪ੍ਰਸਾਰ ਆਮਤੌਰ 'ਤੇ ਪਿਰਤੀ-ਵਧਦਾ ਹੈ: ਜਦ ਟੀਮਾਂ ਸਿੱਖ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਵਰਕਫਲੋ ਜਿਸ ਵਿਚ ਉਨ੍ਹਾਂ ਦੀ ਰੁਚੀ ਬਣ ਜਾਂਦੀ ਹੈ, ਸੀਟਾਂ ਜੋੜਨਾ ਜਾਂ ਉੱਚੇ ਪਲਾਨ ਤੇ ਜਾਣਾ ਕੁਦਰਤੀ ਨਿਰਗਮ ਬਣ ਜਾਂਦਾ ਹੈ।
Boxed software marketing launches ਅਤੇ version numbers 'ਤੇ ਬਣੀ ਹੋਈ ਸੀ। Subscription marketing ਨਤੀਜਿਆਂ 'ਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਦਿੰਦੀ: ਤੇਜ਼ workflow, ਵਧੀਆ collaboration, ਨਵੀਆਂ ਸਮਰੱਥਾਵਾਂ ਤੱਕ ਪਹੁੰਚ, ਅਤੇ ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਸਹੂਲਤ। ਮੈਸੇਜ ਹੁੰਦਾ ਹੈ "ਕਾਇਮ ਰਹੋ ਕੀਮਤ ਲੈ ਰਹੇ ਹੋ" ਨਾ ਕਿ "ਅਗਲਾ ਅਪਗਰੇਡ ਖਰੀਦੋ"।
Adobe ਨੂੰ ਇਕੱਠੇ ਦੋ ਹਕੀਕਤਾਂ ਨੂੰ ਸੇਵਾ ਦੇਣੀ ਪਈ: ਵਿਅਕਤੀਗਤ creators ਜੋ ਸਧਾਰਣ self-serve plans ਅਤੇ ਤੁਰੰਤ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ enterprise ਖਰੀਦਦਾਰ ਜੋ governance, security, compliance, ਅਤੇ predictable budgeting ਚਾਹੁੰਦੇ ਹਨ।
ਇਕ ਸਫਲ go-to-market reset ਦੋਹਾਂ ਦਾ ਸੰਤੁਲਨ ਰੱਖਦਾ ਹੈ—creators ਲਈ ਆਸਾਨ ਐੰਟਰੀ, ਅਤੇ enterprise ਲਈ ਮਾਨਯੋਗ motion ਜੋ ਸਮਿਆਂ ਦੇ ਨਾਲ ਖਾਤੇ ਵਧਾਉਂਦਾ ਹੈ।
ਲਾਇਸੰਸ ਤੋਂ subscriptions 'ਤੇ ਸਵਿੱਚ ਕਰਨ ਨਾਲ "ਚੰਗੀ ਪ੍ਰਦਰਸ਼ਨ" ਦੀ ਵਿਆਖਿਆ ਬਦਲ ਜਾਂਦੀ ਹੈ। Adobe ਦੀ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਦੌਰਾਨ, ਕੰਪਨੀ ਨੂੰ ਇੱਕ-ਵਾਰੀਆਂ bookings ਨੂੰ ਮੁੱਖ ਸਾਬਤ ਨੁਕਤੇ ਵਜੋਂ ਦੇਖਣਾ ਛੱਡਣਾ ਪਿਆ ਅਤੇ recurring engine ਦੇ ਸਿਗਨਲਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਸਿੱਖਿਆ।
ਘੱਟੋ-ਘੱਟ ਟੀਮਾਂ ਨੂੰ ਇਹਨਾਂ ਲਈ ਸਾਂਝੇ ਪਰਿਭਾਸ਼ਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਵਿੱਚ ਦੇ ਪਹਿਲੇ ਕਵਾਰਟਰਾਂ ਵਿੱਚ, revenue ਘਟਦੀ ਹੋਈ ਲੱਗ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਗਾਹਕ ਤੇ momentum ਮਜ਼ਬੂਤ ਹੋਵੇ। perpetual license ਇੱਕ ਵੱਡੀ ਰਕਮ ਤੁਰੰਤ ਬੁੱਕ ਕਰਦਾ ਹੈ, ਜਦਕਿ subscription ਉਸ ਮੁੱਲ ਨੂੰ ਸਮੇਂ 'ਤੇ ਵੰਡਦਾ ਹੈ।
ਤੁਸੀਂ ਵਧ ਰਹੇ ਯੂਨਿਟ ਵੀ ਵੇਚ ਸਕਦੇ ਹੋ, ਪਰ ਮਾਨਤਾ ਪ੍ਰਾਪਤ revenue ਘੱਟ ਲੱਗ ਸਕਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜੇ migration ਤੇ discounting ਵਰਤੀ ਜਾ ਰਹੀ ਹੋਵੇ।
Cohort analysis ਗੁੰਝਲ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਸ਼ੁਰੂ ਮਹੀਨੇ (ਜਾਂ migration ਮਹੀਨਾ) ਅਨੁਸਾਰ ਗਰੁੱਪਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ ਅਤੇ ਵੇਖੋ 3, 6, ਅਤੇ 12 ਮਹੀਨਿਆਂ 'ਚ ਉਹ ਕਿਵੇਂ ਵਰਤਦੇ ਹਨ: renewal rates, expansion, product usage, ਅਤੇ support ਭਾਲ।
ਸਿਹਤਮੰਦ cohorts ਜੋ ਸਮੇਂ ਨਾਲ ਸੁਧਰ ਰਹੇ ਹਨ, headline revenue noisy ਹੋਣ ਵੇਲੇ ਵੀ ਰਸਤਾ ਦਿਖਾ ਸਕਦੇ ਹਨ।
ਜਿਵੇਂ renewal ਪੈਟਰਨ ਬਣਦੇ ਹਨ, forecasting "ਅਗਲਾ ਵੱਡਾ ਡੀਲ ਕਿਹੜਾ ਆਵੇਗਾ" ਤੋਂ "renewals + expansion ਮਾਡਲ" ਵਾਲੀ ਸੂਚਨਾ ਵੱਲ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਇਹ ਪੇਸ਼ਗੀ ਯੋਜਨਾ ਪ੍ਰਬੰਧਨ, hiring, infrastructure, ਅਤੇ ਪ੍ਰੋਡਕਟ ਨਿਵੇਸ਼ ਬਿਹਤਰ ਬਣਾਉਂਦੀ ਹੈ।
Monthly: ARR ਮੂਵਮੈਂਟ (ਨਵਾਂ, expansion, churn), activation/usage ਸਿਗਨਲ, support ਅਤੇ incident ਦਰਾਂ, early-renewal ਅਤੇ cancellation ਕਾਰਨ।
Quarterly: net revenue retention, CAC payback ਅਤੇ channel efficiency, cohort renewal curves, ਅਤੇ plan/package mix ਵਿੱਚ ਹੋਏ ਬਦਲਾਅ ਜੋ ਲੰਬੇ ਸਮੇਂ ਦਾ ਮੁੱਲ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਲਾਇਸੰਸ ਤੋਂ subscriptions 'ਤੇ ਸਵਿੱਚ ਸਿਰਫ਼ ਬਿਲਿੰਗ ਨਹੀਂ ਬਦਲਦਾ—ਇਹ ਗਾਹਕਾਂ ਨਾਲ ਮਨੋਵੈੱਜ਼ਾਨਕ ਸੋਹਦਾ ਬਦਲਦਾ ਹੈ। ਲੁਕ ਲੋਕ ਸਿਰਫ਼ ਉਤਪਾਦ ਨੂੰ ਨਹੀਂ ਅਨੁਮਾਨ ਕਰਦੇ; ਉਹ ਇਹ ਵੀ ਦੇਖਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ongoing access ਨੂੰ ਨਿਭਾਉਣ 'ਤੇ ਉਹਨਾਂ ਦੇ ਨਾਲ ਇਮਾਨਦਾਰ ਹੋਵੋਗੇ ਜਾਂ ਨਹੀਂ।
ਕੀਮਤ-ਬਦਲਾਅ churn ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਜਦ ਗਾਹਕਾਂ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ ਹੈਰਾਨ ਕੀਤੇ ਗਏ ਹਨ। ਇਲਾਜ ਪਾਰਦਰਸ਼ਤਾ ਹੈ: ਦੱਸੋ ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ, ਕਿਉਂ ਬਦਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਇਸ ਨਾਲ ਕੀ ਮਿਲੇਗਾ।
ਕਹਾਣੀ ਸਧੀ ਰੱਖੋ: ਇਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਮਹੀਨੇ-ਬ-ਮਹੀਨੇ ਦਿੱਤੀ ਜਾ ਰਹੀ ਮੁੱਲ ਨਾਲ ਜੋੜੋ (ਲਗਾਤਾਰ ਅੱਪਡੇਟ, ਨਵੀਆਂ ਸਮਰੱਥਾਵਾਂ, ਸੇਵਾਵਾਂ)। "ਬਾਰੀਕੀ ਵਾਲਾ ਮੁੱਲ" ਠੇਸ ਨਹੀਂ ਪਹੁੰਚਾਉਣਾ ਚਾਹੀਦਾ। ਜੇ ਤੁਸੀਂ ਪੁਰਾਣੇ ਪਲਾਨ ਰਿਟਾਇਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਾਫ਼ migration path ਦਿਓ, timeline ਪਬਲਿਸ਼ ਕਰੋ, ਅਤੇ grace periods ਦਿਓ। ਗਾਹਕ ਬਦਲਾਅ ਸੰਭਾਲ ਲੈਂਦੇ ਹਨ; ਉਹ ambiguity ਨਹੀਂ ਸੰਭਾਲਦੇ।
ਬਹੁਤ ਸਾਰਾ churn ਮਾਡਲ ਸਵਿੱਚ ਵਿੱਚ "regret churn" ਹੁੰਦਾ ਹੈ—ਗਾਹਕ ਉਹ ਮੋੜ ਨਹੀਂ ਪਾਂਚਦੇ ਜਿੱਥੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਕਾਬਲ-ਏ-ਤਲਾਬ ਮਹਿਸੂਸ ਹੋਵੇ।
ਪ੍ਰਾਇਕਟਿਕਲ ਲੇਵਰ:
ਮਕਸਦ ਭੁਗਤਾਨ ਅਤੇ ਨਤੀਜੇ ਵਿਚਕਾਰ ਦਾ ਸਮਾਂ ਘਟਾਉਣਾ ਹੈ।
ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਇੱਕ ਖ਼ਾਸ ਝੱਲ ਹੈ: "ਜੇ ਮੈਂ ਭੁਗਤਾਨ ਰੋਕ ਦਿੱਤਾ ਤਾਂ—ਕੀ ਮੈਂ ਆਪਣਾ ਕੰਮ ਗੁਵਾਂ ਦਿਆਂਗਾ?" ਤੁਸੀਂ ਇਸ ਡਰ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਬਿਜ਼ਨਸ ਮਾਡਲ ਨੂੰ ਕਮਜ਼ੋਰ ਕੀਤੇ।
ਹੁਣੇ-ਹਕੀਕਤ ਸੁਰੱਖਿਆ ਦਿਓ ਜਿਵੇਂ ਕਿ ਸੀਮਤ ਸਮੇਂ ਲਈ offline ਮੋਡ, ਸੌਖਾ local backups, ਅਤੇ portable export formats। ਜਦ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਰੁਕੀ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ (read-only access, export windows, data retention periods) ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਜੋ ਗਾਹਕ ਯੋਜਨਾ ਬਣਾ ਸਕਣ।
ਵਿਰੋਧ ਉਮੀਦ ਰੱਖੋ। ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਪਨੀਆਂ ਇਸਨੂੰ signal ਸਮਝਦੀਆਂ ਹਨ, noise ਨਹੀਂ: listening channels ਬਣਾਓ (support tags, community threads, customer advisory groups), ਨਿਰਧਾਰਿਤ ਜਵਾਬ ਦਿਓ, ਅਤੇ ਜੇ ਅਸਲੀ ਦਰਦ-ਬਿੰਦੂ ਮਿਲਦੇ ਹਨ ਤਾਂ policy (packaging, grace periods, ਜਾਂ add-ons) 'ਤੇ iterate ਕਰਨ ਲਈ ਤਿਆਰ ਰਹੋ।
ਭਰੋਸਾ ਉਸ ਅੰਧੇਰੇ ਵਿੱਚ ਕਮਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਗਾਹਕਾਂ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਲੰਬੇ-ਸਮੇਂ ਦਾ ਰਿਸ਼ਤਾ ਵਧਾਉਣ ਲਈ optimize ਕਰ ਰਹੇ ਹੋ, ਨਾ ਕਿ ਛੋਟੇ-ਸਮੇਂ ਦੀ conversion ਲਈ।
ਇੱਕ subscription ਨੂੰ ਰੱਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦ ਉਤਪਾਦ ਇੱਕ platform ਬਣ ਜਾਂਦਾ ਹੈ। Adobe ਲਈ, ਟਿਕਾਊਤਾ ਸਿਰਫ਼ ਜ਼ਿਆਦਾ ਫੀਚਰ ship ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਐਸਾ ਮਾਹੌਲ ਬਣਾਉਣ ਬਾਰੇ ਸੀ ਜਿੱਥੇ ਗਾਹਕ ਘੱਟ friction ਨਾਲ ਵਧੇਰੇ ਕੰਮ ਕਰ ਸਕਦੇ ਅਤੇ ਛੱਡਣ ਲਈ ਘੱਟ ਹੁੰਦੇ।
ਜਿਵੇਂ Creative Cloud default ਬਣ ਗਈ, ਆਸ-पਾਸ ਦਾ ecosystem ਕੋਰ apps ਵਰਗਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਗਿਆ। ਉਹ tools ਜਿਨ੍ਹਾਂ ਨਾਲ ਟੀਮਾਂ ਪਹਿਲਾਂ ਤੋਂ ਵਰਤ ਰਹੀਆਂ ਹਨ (cloud storage, project management, review/approval workflows) ਨਾਲ integrations, ਅਤੇ ਤੀਸਰੇ-ਪੱਖ plugin market, subscription ਦਾ ਮੁੱਲ ਵਧਾਉਂਦੇ ਹਨ।
APIs ਇੱਥੇ ਇੱਕ ਸ਼ਾਂਤ ਤਾਕਤ ਹਨ। ਜਦ agencies ਅਤੇ partners scripts, extensions, templates, ਅਤੇ automations ਪਲੈਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹਨ, ਉਹ ਸਿਰਫ਼ ਫੀਚਰ ਨਹੀਂ ਜੋੜਦੇ—ਉਹ ਸਵਿੱਚਿੰਗ ਲਾਗਤਾਂ ਜੋੜਦੇ ਹਨ ਜੋ ਬਚਾਏ ਗਏ ਸਮੇਂ ਅਤੇ embed ਕੀਤੀਆਂ ਵਰਕਫਲੋਜ਼ ਰੂਪ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਮਾੜੀ ਕਿਸਮ ਦਾ lock-in ਨਹੀਂ, ਪਰ ਵਿਹਾਰਕ ਕਿਸਮ: "ਇਹ اسی ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਾਂ।"
Creator tools ਨੂੰ ਨਰਮ network effects ਮਿਲ ਸਕਦੇ ਹਨ। ਫਾਈਲ ਫਾਰਮੈਟ ਜਿਹੜੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਉਦਯੋਗਾਂ ਅਤੇ ਟੀਮਾਂ ਵਿਚ ਡੀ-ਫੈਕਟੋ ਮਾਨਕ ਬਣ ਜਾਂਦੇ ਹਨ। ਜੇ clients ਤੁਹਾਨੂੰ ਕੁਝ ਫਾਰਮੈਟ ਭੇਜਦੇ ਹਨ, ਜਾਂ collaborators ਕਿਸੇ ਵਰਕਫਲੋ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ, ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਰਹਿਣਾ ਹੀ ਹੈ।
Collaboration ਇਸਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। shared libraries, consistent color/type systems, ਅਤੇ design-to-video ਟੀਮਾਂ ਦਰਮਿਆਨ ਆਸਾਨ ਹandoff platform ਨੂੰ ਵਧੇਰੇ ਕੀਮਤੀ ਬਣਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਸਿਰਫ਼ ਸਾਫਟਵੇਅਰ ਲਈ ਪੈਸਾ ਨਹੀਂ ਦੇ ਰਹੇ; ਤੁਸੀਂ ਚੰਗੀ coordination ਲਈ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ।
Enterprise subscriptions ਇੱਕ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਦਾ ਸੈੱਟ ਮੰਗਦੀਆਂ ਹਨ: admin controls, role-based access, compliance requirements, audit logs, SSO, ਅਤੇ predictable procurement। centralized billing ਅਤੇ license management "ਕੌਣ ਕੋਲ ਕੀ installed ਹੈ?" ਨੂੰ IT ਲਈ govern ਕਰਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਇਹ ਸਮਰੱਥਾਵਾਂ retention ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਜੋਸ਼ ਨਾਲ ਨਹੀਂ—ਭਰੋਸੇ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਹੋਂਦ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ। ਫਿਰ ਵੀ, ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ—platform ਫਾਇਦੇ ਕਿਵੇਂ ਟਿਕਦੇ ਹਨ ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਗਾਹਕ ਲਗਾਤਾਰ ਮੁੱਲ ਅਤੇ ਨਿਆਈ ਕੀਮਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਟੀਮਾਂ ਨੇ ਅਮਲ ਵਿੱਚ ਇਸਨੂੰ ਕਿਵੇਂ ਟਰੈਕ ਕੀਤਾ, ਉਸ ਲਈ ਵੇਖੋ blog/saas-retention-metrics।
ਇੱਕ subscription ਸਵਿੱਚ ਇਕ ਕੀਮਤ-ਬਦਲਾਅ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਕੰਪਨੀ ਓਪਰੇਟਿੰਗ ਬਦਲਾਅ ਹੈ। ਸਵਿੱਚ ਓਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਸਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਾਂਗ ਵਰਤੋ: ਡਿਮਾਂਡ ਨੂੰ validate ਕਰੋ, ਅਨੁਭਵ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਅਤੇ ਫਿਰ scale ਕਰੋ।
ਇੱਕ pilot cohort (ਇੱਕ ਸੈਗਮੈਂਟ ਜਾਂ ਇੱਕ ਜਿਓਗ੍ਰਾਫੀ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਦੋ-ਤਿੰਨ ਸਪਸ਼ਟ-ਨਾਂ ਵਾਲੇ ਪਲਾਨਾਂ ਨਾਲ pricing ਅਤੇ packaging ਟੈਸਟ ਚਲਾਓ।
ਅਗਲੇ, ਇੱਕ migration communication sequence ਬਣਾਓ: ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ, ਕੀ ਰਹੇਗਾ, ਡੇਡਲਾਈਨ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਕੀ ਮਿਲੇਗਾ। ਇੱਕ ਬ੍ਰਿਜ਼ (credits, loyalty pricing, extended support) ਦਿਓ ਤਾਂ ਕਿ migration upgrade ਵਰਗੀ ਮਹਿਸੂਸ ਹੋਵੇ, ultimatum ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਉਤਪਾਦ ਅਨੁਭਵ ਨੂੰ ਮਾਡਲ ਬਦਲਣ ਦੇ ਨਾਲ ਬਣਾਉਂਦੇ ਜਾਂ ਸੁਧਾਰਦੇ ਹੋ, ਤਾਂ ਰਫ਼ਤਾਰ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ subscription-ਤਿਆਰ web apps quickly prototype ਅਤੇ ship ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ (React frontends, Go backends, PostgreSQL), ਇੱਕ chat-driven workflow ਨਾਲ planning mode ਅਤੇ snapshots/rollback ਲਈ ਸਹਾਇਕ—ਇਹ ਮਦਦਗਾਰ ਹੈ ਜਦ ਤੁਸੀਂ onboarding, entitlements, ਅਤੇ tier gating ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ ਬਿਨਾਂ ਲੰਮੇ build cycle ਨੂੰ commit ਕੀਤੇ।
ਜੇ ਤੁਸੀਂ plan structure ਸੁਧਾਰ ਰਹੇ ਹੋ, ਤਾਂ pricing ਨੂੰ ਤੁਲਨਾ ਕਰਨ ਲਈ pricing ਵੇਖੋ।
ਵੱਡੀਆਂ ਗਲਤੀਆਂ: ਅਸਪਸ਼ਟ packaging (ਬਹੁਤ ਸਾਰੇ tiers, ਗੁੰਝਲਦਾਰ limits), billing/support 'ਤੇ ਘੱਟ ਨਿਵੇਸ਼, ਅਤੇ ਸਿਰਫ਼ revenue ਮਾਪਣਾ ਬਦਲੇ activation ਅਤੇ churn drivers ਨੂੰ ਨਾ ਦੇਖਣਾ।
ਜੇ ਗਾਹਕ ਤੁਰੰਤ "ਪਹਿਲੀ ਕਦਰ" ਤੱਕ ਨਹੀਂ ਪੁੱਜ ਸਕਦੇ, ਤਾਂ subscriptions ਨਰਸੰਬੰਧ ਦੀ ਬਜਾਏ ਨਾਰਾਜ਼ਗੀ ਵਧਾਉਂਦੀਆਂ ਹਨ।
Adobe ਦਾ ਟਿਕਾਊ SaaS ਨਤੀਜਾ "ਕਿਵੇਂ" ਕੇਵਲ ਕੀਮਤ-ਬਦਲਾਅ ਨਹੀਂ ਸੀ। ਇਹ ਉਤਪਾਦ ਡਿਲਿਵਰੀ, ਪੈਕੇਜਿੰਗ, ਓਪਰੇਸ਼ਨ, ਅਤੇ ਗਾਹਕ ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਲਗਾਤਾਰ ਮੁੱਲ ਵੱਲ align ਕਰਨ ਦਾ ਸਮੂਹ ਪ੍ਰਭਾਵ ਸੀ। Shantanu Narayen ਦੀ ਲਗਾਤਾਰ ਯੋਗਦਾਨ ਇਹ ਸੀ ਕਿ ਉਸਨੇ ਸਵਿੱਚ ਨੂੰ ਇੱਕ ਅੰਤ-ਤੱਕ-ਅੰਤ ਕਾਰੋਬਾਰੀ ਪੁਨਰਡਿਜ਼ਾਈਨ ਮੰਨਿਆ, ਨਾ ਕਿ ਫਾਇਨੈਂਸ ਦਾ ਫੈਸਲਾ।
ਗਾਹਕ ਭੁਗਤਾਨ ਜਾਰੀ ਰੱਖਦੇ ਰਹੇ ਕਿਉਂਕਿ subscription ਹੀ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਬਣ ਗਿਆ ਸਤਿਰ ਰਹਿਣ ਦਾ: ਨਿਯਮਤ ਸੁਧਾਰ, ਕਲਾਊਡ-ਸਮਰੱਥ ਵਰਕਫਲੋ, ਅਤੇ ਡਿਵਾਈਸਾਂ ਅਤੇ ਟੀਮਾਂ ਵਿੱਚ ਪਹੁੰਚ।
ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, recurring revenue ਤੇਜ਼ iteration, ਬਿਹਤਰ telemetry, ਅਤੇ ਗਹਿਰੀ customer support ਨੂੰ ਫੰਡ ਕਰਦਾ—ਇੱਕ ਚੱਕਰ ਬਣਦਾ ਜੋ retention ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ।
Transformation = product + pricing + operations।
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਖੁਦ ਦੀ ਸਵਿੱਚ ਨਕਸ਼ਾ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ blog ਪੜ੍ਹੋ ਜਾਂ pricing 'ਤੇ plan design patterns ਦੀ ਤੁਲਨਾ ਕਰੋ।
Adobe ਦੇboxed ਮਾਡਲ ਨੇ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਵਾਲੀ ਆਮਦਨੀ ਪੈਦਾ ਕੀਤੀ (ਵੱਡੀਆਂ ਰਿਲੀਜ਼ਾਂ ਵਕਤ ਆਮਦਨੀ ਉੱਪਰ-ਚੜ੍ਹਦੀ ਸੀ) ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਛੇਤੀ-ਛੇਤੀ ਅਪਗਰੇਡ ਨਹੀਂ ਕਰਨ ਦੀ ਆਦਤ ਦਿਵਾਈ। ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮਾਡਲ لانਚ-ਚਲਿਤ ਆਮਦਨੀ ਦੀ ਜਗ੍ਹਾ ਮੁੱਲ-ਤਕਰੀਰ ਆਮਦਨੀ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਲਗਾਤਾਰ ਕੀਮਤ-ਸੁਧਾਰਨ ਅਤੇ ਭਵਿੱਖੀ ਨਿਰਧਾਰਤਾ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ—ਜੇ ਰੀਟੇਨਸ਼ਨ ਮਜ਼ਬੂਤ ਰਹੇ।
ਸਭ ਤੋਂ ਵੱਡੇ ਖਤਰੇ ਹਨ:
ਇਸ ਲਈ ਇਸ ਨੂੰ ਇੱਕ ਕਈ ਸਾਲਾਂ ਵਾਲਾ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਸਮਝੋ ਜਿਸਦੇ ਮਿਆਰੀ ਨਿਸ਼ਾਨੇ ਹੋਣ।
ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਗਾਹਕਾਂ ਵੱਲੋਂ ਨਵੀਂ ਕਦਰ ਦੇ ਤੌਰ 'ਤੇ ਵੇਖਿਆ ਜਾਣਾ ਜ਼ਰੂਰੀ ਹੈ—ਸਿਰਫ਼ ਉਸੇ ਐਪ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ। ਪ੍ਰੈਕਟਿਕਲ ਤੱਤ:
ਜੇ ਗਾਹਕ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਅਗਲੇ 30–90 ਦਿਨਾਂ ਵਿੱਚ ਕੀ ਸੁਧਰੇਗਾ, ਤਾਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਤੱਕਲੂਫ਼ ਜਿਹਾ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਬੰਡਲ ਕੀਮਤ-ਤੁਲਨਾ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਕਵਰੇਜ ਦੀ ਭਾਵਨਾ ਵਧਾਉਂਦੇ ਹਨ:
ਮੁੱਢਲੀ ਗੱਲ: ਬੰਡਲਸ ਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਰੱਖੋ ਅਤੇ ਗੁੰਝਲਦਾਰ ਓਵਰਲੈਪ ਤੋਂ ਬਚੋ।
ਲੋਕਾਂ ਨੂੰ ਗੁੰਝਲ ਨਾ ਹੋਵੇ—ਇਸ ਲਈ ਥੋੜ੍ਹੇ ਹੀ ਪਲਾਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ “ਮੇਰਾ ਪਲਾਨ ਕਿਹੜਾ ਹੈ?” ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ:
ਆਮ SaaS ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਮਿੱਤ:
ਅਗੇਈ-ਸੂਚਕ ਵੀ ਟਰੈਕ ਕਰੋ ਜਿਵੇਂ ਕਿ , usage depth, time-to-first-success, ਅਤੇ ਸਪੋਰਟ/incident ਦਰਾਂ।
ਕਿਉਂਕਿ revenue recognition ਬਦਲਦਾ ਹੈ:
ਇਸ ਲਈ ਤੁਸੀਂ ਗਾਹਕ ਅਤੇ momentum ਜਿੱਤ ਰਹੇ ਹੋ ਸਕਦੇ ਹੋ ਪਰ ਮਾਨਤਾ ਪ੍ਰਾਪਤ ਆਮਦਨੀ ਕਮਜ਼ੋਰ ਲੱਗ ਸਕਦੀ ਹੈ। cohort analysis (ਸ਼ੁਰੂਆਤੀ ਮਹੀਨੇ/ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਹੀਨੇ ਦੁਆਰਾ) ਵਰਤੋ ਤਾਂ ਕਿ 3–12 ਮਹੀਨੇ ਵਿਚ renewal, expansion, usage, ਅਤੇ support ਰੁਝਾਨ ਵੇਖੇ ਜਾ ਸਕਣ।
Telemetry ਨਾਲ “ship → measure → learn” ਚੱਕਰ ਸੰਭਵ ਹੁੰਦਾ ਹੈ:
ਮਾਤਰ ਗਿਣਤੀਕ ਸਿਗਨਲਾਂ ਨਾਲ qualitative ਫੀਡਬੈਕ (support tickets, community feedback, enterprise input) ਮਿਲਾ ਕੇ ਫ਼ੈਸਲੇ ਲਵੋ।
ਭਰੋਸਾ ਘਟਾਉਣ ਲਈ ਸਪੱਸ਼ਟ ਅਤੇ ਇਮਾਨਦਾਰ ਰਵਈਆ ਦਿਖਾਓ:
ਭਰੋਸਾ ਉਨ੍ਹਾਂ ਨੀਤੀਆਂ ਨਾਲ ਬਣਦਾ ਹੈ ਜੋ ਗਾਹਕਾਂ ਲਈ ਸਮਝਣਯੋਗ ਹੁੰਦੀਆਂ ਹਨ ਉਸ ਵੇਲੇ ਵੀ ਜਦ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਾਲ਼ ਸਾਹਮਣਾ ਹੁੰਦਾ ਹੈ।
ਮੁੱਖ ਬਦਲਾਅ:
ਸਾਥੀ ਆਮਤੌਰ 'ਤੇ "units ਹਿਲਾਉਣ" ਤੋਂ ਵੱਧ services, implementation, ਅਤੇ enterprise procurement ਸਹਾਇਤਾ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।