ਸਿੱਖੋ ਕਿ Marc Benioff ਅਤੇ Salesforce ਨੇ ਕਿਵੇਂ SaaS CRM ਨੂ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਅਤੇ ਐਪਇਕਸਚੇਂਜ਼/ਪਲੇਟਫਾਰਮ ਇਕੋਸਿਸਟਮ ਬਣਾਕੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਾਫਟਵੇਅਰ ਨੂੰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਯੂਟੀਲਿਟੀ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲ ਦਿੱਤਾ।
Salesforce ਦੀ ਸ਼ੁਰੂਅਾਤ ਦੀ ਕਹਾਣੀ ਵਰਤੋਂਯੋਗ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕੰਪਨੀਆਂ ਸਾਫਟਵੇਅਰ ਖਰੀਦਣ, ਚਲਾਉਣ ਅਤੇ ਵਧਾਉਣ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਕਿਵੇਂ ਇੱਕ ਨਿਰਧਾਰਤ ਬਦਲਾਵ ਆਇਆ: ਇੱਕ ਵਾਰੀ ਖਰੀਦਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ (ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਇਨਸਟਾਲ ਅਤੇ ਮੇੰਟੇਨੈਂਸ ਕਰਦੇ ਹੋ) ਤੋਂ, ਉਹ ਸੇਵਾਵਾਂ ਜਿਹਨਾਂ ਦੀ ਤੁਸੀਂ ਸਬਸਕ੍ਰਾਇਬ ਕਰਦੇ ਹੋ ਅਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲਗਾਤਾਰ ਬੇਹਤਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇਹ ਲੇਖ CRM ਨੂੰ ਇੱਕ ਲੈਂਸ ਵਜੋਂ ਵਰਤਦਾ ਹੈ—ਨਾ ਕਿ CRM ਖੁਦ ਰੋਮਾਂਚਕ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਇਹ ਰੇਵਨਿਊ ਦੇ ਕੋਲ ਬੈਠਦਾ ਹੈ। ਜਦੋਂ ਉਹ ਸਿਸਟਮ ਜੋ ਲੀਡਜ਼, ਡੀਲਜ਼ ਅਤੇ ਗਾਹਕ ਇਤਿਹਾਸ ਦਾ ਟ੍ਰੈਕ ਰੱਖਦਾ ਹੈ, ਅਪنانੇ ਲਈ ਅਸਾਨ ਅਤੇ ਅਪ-ਟੂ-ਡੇਟ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵੇਚ ਸਕਦੀਆਂ ਹਨ, ਸੇਵਾ ਦੇ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਰਿਪੋਰਟ ਕਰ ਸਕਦੀਆਂ ਹਨ।
Marc Benioff ਦੀ ਭੂਮਿਕਾ ਇਸ ਬਦਲਾਵ ਵਿੱਚ CRM ਖੋਜਣ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਇਹ ਸ਼ੁਰੂਆਤੀ ਫੈਸਲਿਆਂ ਦਾ ਇੱਕ ਸੈਟ ਸੀ—CRM ਨੂੰ ਵੈੱਬ 'ਤੇ ਦੇਣਾ, ਇਸ ਨੂੰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਵਜੋਂ ਦਰਜਾ ਦੇਣਾ, ਅਤੇ ਅਪਗ੍ਰੇਡਜ਼ ਨੂੰ ਵੇਂਡਰ ਦੀ ਕੇਂਦਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਬਣਾਉਣਾ। ਸਮਾਂ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ ਸੀ: ਇੰਟਰਨੇਟ ਐਕਸੈਸ ਕੰਮ 'ਤੇ ਆਮ ਹੋ ਰਿਹਾ ਸੀ, ਅਤੇ ਕਾਰੋਬਾਰ ਮਹਿੰਗੇ, ਧੀਮੇ ਸਾਫਟਵੇਅਰ ਰੋਲਆਉਟ ਤੋਂ ਥੱਕ ਚੁੱਕੇ ਸਨ।
ਤੁਸੀਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਂਗੇ:
ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਯੂਟੀਲਿਟੀ ਉਹ ਸਾਫਟਵੇਅਰ ਹੈ ਜੋ ਬਕਾਇਦਾ ਬਿਜਲੀ ਵਾਂਗ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਇਸਦੇ ਮਾਲਿਕ ਨਹੀਂ ਬਣਦੇ, ਤੁਸੀਂ ਇਸ ਤੱਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚਦੇ ਹੋ। ਤੁਸੀਂ ਉਮੀਦ ਰੱਖਦੇ ਹੋ ਕਿ ਇਹ ਉਪਲਬਧ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਮੇਂ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦਾ ਰਹੇਗਾ—ਜਦਕਿ ਵੇਂਡਰ ਪਿਛੋਕੜ ਵਿੱਚ ਇਨਫਰਾਸਟਰੱਕਚਰ, ਅਪਡੇਟ ਅਤੇ ਸਕੇਲਿੰਗ ਚਲਾਉਂਦਾ ਹੈ।
Customer Relationship Management (CRM) ਉਹ ਸਿਸਟਮ ਹੈ ਜਿੱਥੇ ਕੰਪਨੀ ਗਾਹਕ ਵਿਲੱਖਣਤਾ, ਕੀ ਕਿਹਾ ਗਿਆ, ਕੀ ਵਾਅਦਾ ਕੀਤਾ ਗਿਆ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ—ਇਹ “ਜੀਂਦਾ ਰਿਕਾਰਡ” ਰੱਖਦੀ ਹੈ। ਲੋਕ ਆਕਸਰ CRM ਨੂੰ ਡੇਟਾਬੇਸ ਵਜੋਂ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਪਰ ਗਾਹਕ ਇਸਨੂੰ ਇਕ ਪ੍ਰਯੋਗਿਕ ਮਕਸਦ ਲਈ ਖਰੀਦਦੇ ਹਨ: ਘੱਟ ਛੁੱਟੀਆਂ ਗਈਆਂ ਗੱਲਾਂ ਅਤੇ ਵਾਧੂ ਜ਼ਿੰਮੇਵਾਰੀ।
Sales ਟੀਮਾਂ CRM ਨੂੰ pipeline ਟਰੈਕ ਕਰਨ ਲਈ ਵਰਤਦੀਆਂ ਹਨ: ਲੀਡਜ਼, ਡੀਲਜ਼, ਟੇਜ, ਅਗਲੇ ਕਦਮ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਬੰਦ੍ਹੀ ਦੀ ਤਾਰੀਖ। ਇੱਕ ਰੈਪ ਆਪਣੀਆਂ ਅਕਾਊਂਟਾਂ ਦੇਖ ਸਕਦਾ ਹੈ, ਕਾਲਾਂ ਅਤੇ ਈਮੇਲ ਲਾਗ ਕਰ ਸਕਦਾ ਹੈ, ਫਾਲੋਅਪ ਲਗਾ ਸਕਦਾ ਹੈ ਅਤੇ ਯਾਦ ਤੋਂ ਜਾਂ ਫੈਲੀਆਂ ਨੋਟਾਂ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ।
Service ਟੀਮਾਂ CRM ਨੂੰ ਕੇਸ ਅਤੇ ਜਵਾਬਾਂ ਨੂੰ ਮੈਨੇਜ ਕਰਨ ਲਈ ਵਰਤਦੀਆਂ ਹਨ। ਜਦੋਂ ਗਾਹਕ ਸੰਪਰਕ ਕਰਦਾ ਹੈ, ਤਦ ਸਹਾਇਤਾ ਪਹਿਲਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਖਰੀਦਾਂ ਅਤੇ ਗੱਲਬਾਤ ਵੇਖ ਸਕਦੀ ਹੈ—ਤਾਂ ਜੋ ਗਾਹਕ ਨੂੰ ਦੁਹਰਾਉਣਾ ਨਾ ਪਵੇ।
Marketing ਟੀਮਾਂ CRM ਡੇਟਾ ਨੂੰ ਦਰੁਸਤ ਸੈਗਮੈਂਟ ਬਣਾਉਣ ਅਤੇ ਅਸਲ ਰੇਵਨਿਊ 'ਤੇ ਪ੍ਰਭਾਵਕੈਂਦਰ ਮੁਹਿੰਮਾਂ ਦੀ ਮਾਪ ਕਰਨ ਲਈ ਵਰਤਦੀਆਂ ਹਨ (ਸਿਰਫ਼ ਕਲਿਕ ਨਹੀਂ)।
ਰਿਵਾਇਤੀ ਇੰਸਟਾਲ ਕੀਤਾ ਗਿਆ CRM ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ ਖਰੀਦਣ, ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਸ਼ਡਿਊਲ ਕਰਨ ਅਤੇ ਬਦਲਾਅ ਲਈ IT ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਨ ਦਾ ਮਤਲਬ ਸੀ। ਅਪਗ੍ਰੇਡਜ਼ ਵੱਡੇ ਇਵੈਂਟ ਹੁੰਦੇ—ਅਕਸਰ ਮੁਲਤਵੀ ਹੋ ਜਾਂਦੇ ਕਿਉਂਕਿ ਉਹ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨਾਂ ਨੂੰ ਤੋੜ ਸਕਦੇ ਸਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਟੀਮਾਂ ਪੁਰਾਣੇ ਵਰਜ਼ਨਾਂ 'ਤੇ ਫਸ ਗਈਆਂ, ਡੇਟਾ ਗੁਣਵੱਤਾ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਅਸਰਦਰ ਕਾਰਵਾਈਆਂ ਨਾਲ।
ਨੇਤ੍ਰਿਤਵ ਨੂੰ ਵਿਜ਼ੀਬਿਲਿਟੀ ਚਾਹੀਦੀ ਹੈ: ਸਹੀ ਫੋਰਕਾਸਟ, ਕਨਵਰਜ਼ਨ ਦਰਾਂ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰਿਪੋਰਟਾਂ।
ਫਰੰਟਲਾਈਨ ਰੈਪਾਂ ਨੂੰ ਵਰਤਣ ਵਿਚ ਆਸਾਨੀ ਚਾਹੀਦੀ ਹੈ: ਤੇਜ਼ ਡੇਟਾ ਐਂਟਰੀ, ਘੱਟ ਲਾਜ਼ਮੀ ਖੇਤਰ ਅਤੇ ਸਾਫ਼ ਰੋਜ਼ਾਨਾ ਕੰਮ-ਸੂਚੀ।
Admins ਅਤੇ IT ਨੂੰ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ: ਪੇਸ਼ਗੀ ਅਨੁਮਤੀਆਂ, ਸਾਫ਼ ਡੇਟਾ ਨਿਯਮ ਅਤੇ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਜੋ ਲਗਾਤਾਰ ਮੇਂਟੇਨੈਂਸ ਦੀ ਲੋੜ ਨਾ ਬਣਾਏ।
ਚੰਗੇ CRM ਦੀ ਕਾਮਯਾਬੀ ਇਸ ਵਿੱਚ ਹੈ ਕਿ ਇਹ ਇਹਨਾਂ ਕੰਮਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਬਿਨਾਂ ਇਸਦੇ कि "CRM ਅਪਡੇਟ ਕਰਨਾ" ਅਸਲੀ ਕੰਮ ਬਣ ਜਾਵੇ।
SaaS (Software as a Service) ਉਹ ਸਾਫਟਵੇਅਰ ਹੈ ਜਿਸ ਤੱਕ ਤੁਸੀਂ ਬਰਾਊਜ਼ਰ ਜਾਂ ਐਪ ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹੋ, ਜਦਕਿ ਵੇਂਡਰ ਸਰਵਰਾਂ, ਸਟੋਰੇਜ, ਸੁਰੱਖਿਆ ਪੈਚਾਂ ਅਤੇ ਅਪਗ੍ਰੇਡਜ਼ ਚਲਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਲੌਗਇਨ ਕਰੋ, ਉਤਪਾਦ ਵਰਤੋ, ਅਤੇ ਪ੍ਰਦਾਤਾ ਪਿਛੋਕੜ ਦਾ ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਦਫ਼ਤਰ ਜਾਂ ਉਸ ਹੋਸਟਿੰਗ ਕਾਨ਼ਟ੍ਰੈਕਟ ਵਿੱਚ ਸੀ ਜਿਸਨੂੰ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਸਨ।
ਇੰਸਟਾਲ ਕੀਤਾ ਸਾਫਟਵੇਅਰ (ਪੁਰਾਣਾ ਮਾਡਲ) DVD ਪਲੇਅਰ ਖਰੀਦਣ ਵਰਗਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਵਰਜ਼ਨ ਲਈ ਅੱਗੇ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਆਪਣੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਇੰਸਟਾਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਅਪਗ੍ਰੇਡ ਵੱਖ-ਵੱਖ ਖਰੀਦ ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਹੁੰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰਿਆਂ ਨੂੰ ਵਧੀਕ ਹਾਰਡਵੇਅਰ, ਬੈਕਅੱਪ ਅਤੇ IT ਸਮਾਂ ਵੀ ਖਰੀਦਣਾ ਪੈਂਦਾ ਸੀ।
ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਾਫਟਵੇਅਰ ਬਿਜਲੀ ਜਾਂ ਜਿਮ ਮੈਂਬਰਸ਼ਿਪ ਦੇ ਭੁਗਤਾਨ ਵਰਗਾ ਹੈ: ਤੁਸੀਂ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਹਮੇਸ਼ਾਂ ਅਪ-ਟੂ-ਡੇਟ ਸੇਵਾ ਵਰਤ ਰਹੇ ਹੋ। ਮੁੱਲ ਅਕਸਰ ਪ੍ਰਤੀ ਯੂਜ਼ਰ, ਪ੍ਰਤੀ ਮਹੀਨਾ/ਸਾਲ ਹੁੰਦਾ ਹੈ, ਕਦੇ-ਕਦੇ ਫੀਚਰ ਜਾਂ ਸਟੋਰੇਜ ਲਈ ਲੇਅਰ ਹੁੰਦੇ ਹਨ।
SaaS ਤੇਜ਼ੀ ਨਾਲ ਚਾਲੂ ਹੋ ਸਕਦਾ ਹੈ—ਅਕਸਰ ਦਿਨਾਂ ਵਿੱਚ, ਮਹੀਨਿਆਂ ਦੀ ਬਜਾਏ। ਖ਼ਰਚੇ ਅਜ਼ਾਦ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਓਹਨਾਂ ਨੂੰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਪਡੇਟ ਲਗਾਤਾਰ ਆਉਂਦੇ ਹਨ ਬਿਨਾਂ ਵੱਡੇ “ਅਪਗ੍ਰੇਡ ਵੀਕਐਂਡ” ਦੇ। ਟੀਮਾਂ ਹਰ ਥਾਂ ਸਾਈਨ ਇਨ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਫ਼ੀਲਡ 'ਚ ਵਿਕਰੀ ਅਤੇ ਸੇਵਾ ਲਈ ਮਤਲਬ ਰੱਖਦਾ ਹੈ।
SaaS ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ friction‑free ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਇੰਟਰਨੇਟ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹੋ। ਕੁਝ ਉਦਯੋਗਾਂ ਦੇ ਡੇਟਾ ਰੈਜ਼ਿਡੈਂਸੀ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਹੜੀਆਂ ਡੇਟਾ ਸਟੋਰੇਜ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸੀਮਤ ਕਰਦੀਆਂ ਹਨ। ਅਤੇ ਵੇਂਡਰ ਲੌਕ‑ਇਨ ਦਾ ਜੋਖਮ ਹੈ: ਜਦੋਂ ਤੁਹਾਡਾ ਡੇਟਾ, ਵਰਕਫਲੋਜ਼ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਇਕ ਸਿਸਟਮ ਵਿੱਚ ਰਹਿ ਜਾਂਦੇ ਹਨ, ਤਦਾਲਤ ਤਬਦੀਲੀ ਮਹਿੰਗੀ ਹੋ ਸਕਦੀ ਹੈ—ਇਸ ਲਈ ਪਹਿਲੇ ਤੋਂ ਹੀ export, APIs ਅਤੇ ਅਨੁਬੰਧਕੀ ਸ਼ਰਤਾਂ ਬਾਰੇ ਪੁੱਛਣਾ ਫਾਇਦemand ਹੈ।
Salesforce ਇੱਕ ਵੱਡੇ ਬਦਲਾਵ ਦੇ ਨਾਲ ਵਧਿਆ: ਕਾਰੋਬਾਰ ਮਹੱਤਵਪੂਰਨ ਕੰਮਾਂ ਲਈ hosted web applications 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਸਨ, ਨਾਂ ਕਿ ਸਿਰਫ਼ “ਚੰਗੇ-ਹੋਣ ਵਾਲੇ” ਟੂਲਾਂ ਲਈ। ਬਾਕਸ ਵਿੱਚ ਸੌਫਟਵੇਅਰ ਖਰੀਦਣ ਅਤੇ ਹਰ ਕੁਝ ਸਾਲ ਬਾਅਦ ਅਪਗ੍ਰੇਡ ਕਰਨ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਬਰਾਊਜ਼ਰ ਰਾਹੀਂ ਲੌਗਇਨ ਕਰਦੀਆਂ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਫਾਇਦਾ ਲੈ ਸਕਦੀਆਂ।
ਜਾਣੀ-ਪਛਾਣੀ “no software” ਸੁਨੇਹਾ ਸਿਰਫ਼ ਮਾਰਕੀਟਿੰਗ ਨਹੀਂ ਸੀ—ਇਸ ਨੇ ਰੋਜ਼ਾਨਾ ਦਰਦ ਨੂੰ ਪ੍ਰਕਟ ਕੀਤਾ। ਰਿਵਾਇਤੀ CRM ਪ੍ਰੋਜੈਕਟ ਅਕਸਰ ਲੰਬੀਆਂ ਇੰਸਟਾਲੇਸ਼ਨ ਚਕਰ, IT ਟਿਕੱਟ, ਵਰਜ਼ਨ ਸੰਘਰਸ਼ ਅਤੇ ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਉੱਤੇ ਟ੍ਰੇਨਿੰਗ ਮੰਗਦੇ ਸਨ। ਵੈੱਬ-ਦਿੱਤਾ CRM ਇੱਕ ਸਧਾਰਣ ਰਸਤਾ ਪ੍ਰਭਾਵੀ ਤੌਰ 'ਤੇ ਪੁਸ਼ ਕਰਦਾ ਸੀ:
ਇਹ ਨੇ ਉਹਨਾਂ ਨੇਤਾਵਾਂ ਲਈ ਮਾਇਨੇ ਰੱਖਿਆ ਜੋ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ CRM ਇੱਕ ਕਈ-ਮਹੀਨੇ ਵਾਲੀ IT ਮੁਹਿੰਮ ਬਣ ਜਾਵੇ। ਉਹ ਇੱਕ ਐਸਾ ਟੂਲ ਚਾਹੁੰਦੇ ਸਨ ਜੋ ਵਿਕਰੀ ਦੀ ਤਿਮਾਹੀ চল ਰਹੇ ਹੋਣ ਵੇਲੇ ਵੀ ਅਪਣਾਇਆ ਜਾ ਸਕੇ।
ਸ਼ੁਰੂਆਂ ਵਿੱਚ Salesforce ਨੇ CRM ਨੂੰ ਉਸ ਗੱਲ 'ਤੇ ਕੇਂਦਰਿਤ ਕੀਤਾ ਜੋ sales ਟੀਮ ਤੁਰੰਤ ਸਮਝ ਸਕਦੀ ਸੀ: ਲੀਡ ਪ੍ਰਬੰਧਨ, ਅਵਸਰ ਟਰੈਕਿੰਗ, ਫਾਲੋਅਪ ਅਤੇ ਫੋਰਕਾਸਟ ਰਿਪੋਰਟਿੰਗ। sales automation 'ਤੇ ਪਹਿਲਾਂ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਕੇ—ਅਤੇ deployment ਨੂੰ ਹਲਕਾ ਰੱਖ ਕੇ—ਇਸਨੇ “ਪਹਿਲੀ ਜਿੱਤ ਤੱਕ ਦਾ ਸਮਾਂ” ਘਟਾਇਆ। ਇੱਕ ਰੈਪ ਤੁਰੰਤ ਸਰਗਰਮ ਹੋ ਕੇ activity ਲਾਗ ਕਰ ਸਕਦਾ ਸੀ ਅਤੇ ਮੈਨੇਜਰ pipeline ਰਿਪੋਰਟ ਦੇਖ ਸਕਦਾ ਸੀ ਬਿਨਾਂ ਲੰਬੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੇ।
ਇਸ ਸ਼ੁਰੂਆਤੀ ਬੇਟ ਨੇ ਉਮੀਦ ਪੈਦਾ ਕੀਤੀ ਕਿ ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਸੇਵਾ ਵਾਂਗ ਵਰਤ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਪੇਦਾਵਾਰ ਉਤਪਾਦ: ਹਰ ਥਾਂ ਪਹੁੰਚਯੋਗ, ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਅਤੇ ਅਸਾਨ ਅਪਡੇਟ।
Salesforce ਨੇ ਸਿਰਫ CRM ਨੂੰ ਇੰਟਰਨੇਟ 'ਤੇ ਨਹੀਂ ਰੱਖਿਆ—ਇਸਨੇ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਅਤੇ ਚਲਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। ਮੁੱਖ ਵਿਚਾਰ ਹੈ multi‑tenancy, ਅਤੇ ਇਕ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਜੋ ਅਪਡੇਟ ਨੂੰ ਇੱਕ ਨਾਰਮਲ, ਜਾਰੀ ਸੇਵਾ ਵਜੋਂ ਮੰਨਦੀ ਹੈ।
Multi‑tenant cloud ਵਿੱਚ, ਬਹੁਤ ਸਾਰੇ ਗਾਹਕ ਇੱਕੋ ਥੱਲੇ ਦੇ ਆਧਾਰਭੂਤ ਢਾਂਚੇ (ਉਹੀ “ਬਿਲਡਿੰਗ”) 'ਤੇ ਚੱਲਦੇ ਹਨ, ਜਦਕਿ ਹਰ ਗਾਹਕ ਦੀ ਜਾਣਕਾਰੀ ਵੱਖ-ਵੱਖ (ਤਾਲਾ ਲੱਗੇ ਕਮਰੇ) ਰੱਖੀ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਪਲੰਬਿੰਗ ਅਤੇ ਤਾਰ-ਕੰਮੀਨ ਸਾਂਝਾ ਕਰਦੇ ਹੋ, ਪਰ ਆਪਣੀਆਂ ਫਾਈਲਾਂ ਸਾਂਝੀਆਂ ਨਹੀਂ ਕਰਦੇ।
ਇਹ ਡਿਜ਼ਾਈਨ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਦਾਤਾ ਸੈਂਕੜਿਆਂ ਵੱਖ-ਵੱਖ ਇੰਸਟਾਲੇਸ਼ਨਾਂ ਨੂੰ ਸਮਝਣ ਦੀ ਥਾਂ ਇੱਕ ਮਿਆਰੀ ਸਿਸਟਮ ਚਲਾ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਵੇਂਡਰ ਇੱਕ ਕੇਂਦਰੀ ਕੋਰ ਸਿਸਟਮ ਚਲਾਉਂਦਾ ਹੈ, ਉਹ:
ਇਹ ਕਾਰਗੁਜ਼ਾਰੀ ਆਮਤੌਰ 'ਤੇ ਪ੍ਰਤੀ ਗਾਹਕ ਓਪਰੇਟਿੰਗ ਲਾਗਤ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਸਭ ਤੋਂ ਵੱਧ, ਇਹ ਨਵੇਂ ਸਮਰੱਥਾ ਜਲਦੀ ਜਾਰੀ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ: ਨਵੀਆਂ ਸ਼ਕਤੀਆਂ ਸੇਵਾ 'ਤੇ ਰੋਲ-ਆਉਟ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਹਰ ਕੰਪਨੀ ਦੇ ਅਪਗ੍ਰੇਡ ਦੀ ਉਡੀਕ ਕੀਤੀ।
ਪਾਰੰਪਰਿਕ ਇੰਸਟਾਲ ਕੀਤਾ ਸਾਫਟਵੇਅਰ ਅਕਸਰ ਦਰਦਨਾਕ ਅਪਗ੍ਰੇਡ ਮੰਗਦਾ ਸੀ: ਡਾਊਨਟਾਈਮ ਯੋਜਨਾ, IT ਪ੍ਰੋਜੈਕਟ, ਸੰਗਤਤਾ ਜਾਂਚ ਅਤੇ ਰੀ-ਟ੍ਰੇਨਿੰਗ। ਲਗਾਤਾਰ ਅਪਡੇਟਾਂ ਨਾਲ, ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ "ਵਰਜ਼ਨ ਖਰੀਦਣਾ" ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਸੁਧਾਰ ਲਗਾਤਾਰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। CRM ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਮਾਈਗਰੇਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਦੇ ਕਰੰਟ ਰਹਿੰਦਾ ਹੈ।
Multi‑tenancy ਸਿਰਫ਼ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਗਈ ਹੋਵੇ: ਗਾਹਕਾਂ ਵਿਚਕਾਰ ਮਜ਼ਬੂਤ ਅਲੱਗ-ਅਲੱਗ ਕਰਨਾ, ਹਰ org ਵਿੱਚ ਬਰੀਕ ਅਨੁਮਤੀਆਂ, ਅਤੇ ਸਪੱਸ਼ਟ ਐਡਮਿਨ ਕੰਟਰੋਲ ਕਿ ਕੌਣ ਡੇਟਾ ਵੇਖ ਸਕਦਾ, ਬਦਲ ਸਕਦਾ ਜਾਂ ਐക്സਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਕ ਸਾਂਝੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਭਰੋਸਾ ਫੀਚਰ ਨਹੀਂ—ਇਹ ਨੀਂਹ ਹੈ।
Salesforce ਨੇ ਸਿਰਫ CRM ਸੌਲਡ ਨਹੀਂ ਕੀਤਾ; ਇਸਨੇ ਲਗਾਤਾਰ ਸੇਵਾ ਵੇਚੀ। ਇਸ ਬਦਲਾਵ ਨੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਨੂੰ ਮਨਪਸੰਦ بنایا ਕਿਉਂਕਿ ਪੇਸ਼ ਬਦਲਿਆ: ਪੁਰਾਣਾ ਰਿਕਾਰਡ ਰਿਵਨੀਉ ਨਿਰੰਤਰ ਹੁੰਦਾ, ਕੰਪਨੀ ਨਿਯੁਕਤੀ, ਇਨਫਰਾਸਟਰੱਕਚਰ ਅਤੇ ਉਤਪਾਦ ਨਿਵੇਸ਼ ਦੀ ਯੋਜਨਾ ਘੱਟ ਅਣਇੱਛਤਤਾ ਨਾਲ ਕਰ ਸਕਦੀ ਸੀ।
ਗਾਹਕਾਂ ਲਈ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੇ ਖਰੀਦ-ਗੱਲ-ਬਾਤ ਨੂੰ ਵੀ ਬਦਲ ਦਿੱਤਾ। ਵੱਡੇ ਅੱਗੇ ਭੁਗਤਾਨ ਦੀ ਥਾਂ, CRM ਇੱਕ operating expense ਬਣ ਗਿਆ—ਬਜਟ ਬਣਾਉਣ ਲੀ ਆਸਾਨ, ਜਾਇਜ਼ ਕਰਨ ਲਈ ਆਸਾਨ, ਅਤੇ ਜੇ ਇਹ ਮੁੱਲ ਨਹੀਂ ਦਿੰਦਾ ਤਾਂ ਰੋਕਣਾ ਵੀ ਆਸਾਨ। ਜਿਨ੍ਹਾਂ ਹੀ ਪ੍ਰਭਾਵ: ਟੀਮ ਆਸਾਨੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀਆਂ—ਵੈੱਬ ਡਿਲਿਵਰੀ ਅਤੇ ਮਿਆਰੀ ਡਿਪਲੋਇਮੈਂਟ ਨਾਲ, ਤੁਸੀਂ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਲਾਈਵ ਹੋ ਸਕਦੇ ਹੋ, ਮਹੀਨਿਆਂ ਜਾਂ ਤਿਮਾਹਿਆਂ ਦੀ ਥਾਂ।
ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਕਾਰੋਬਾਰ renewals 'ਤੇ ਟਿਕਦਾ ਹੈ। ਇਸ ਕਾਰਨ ਵੇਂਡਰ ਨੂੰ contract ਸਾਈਨ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ ਤੇ ਧਿਆਨ ਦੇਣਾ ਪੈਦਾ ਹੈ:
ਫਲਾਈਵ੍ਹੀਲ ਨੂੰ ਚਾਰ ਜੁੜੇ ਮੋਸ਼ਨਾਂ ਵਜੋਂ ਸੋਚੋ:
ਜੇ Activation ਵਧਦੀ ਹੈ, ਤਾਂ Renewal ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ। ਜਦ Renewal ਮਜ਼ਬੂਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ Expansion ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵਧਦੀ ਹੈ। ਇਹੀ ਤਰੀਕੇ ਨਾਲ ਸਾਫਟਵੇਅਰ ਯੂਟੀਲਿਟੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ: ਹਮੇਸ਼ਾਂ ਚਾਲੂ, ਨਿਯਮਤ ਅਪਡੇਟ, ਅਤੇ ਜਿਸਦੇ ਲਈ ਤੁਸੀਂ ਦਿੱਤਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ।
ਇੱਕ “ਉਤਪਾਦ” CRM ਤੁਹਾਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਫੀਚਰ ਸੈੱਟ ਦਿੰਦਾ: accounts, contacts, opportunities, reports। ਇੱਕ “ਪਲੇਟਫਾਰਮ” CRM ਹੋਰ ਵੱਡੀ ਚੀਜ਼ ਜੋੜਦਾ ਹੈ: ਉਹ ਢੰਗ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਆਪਣੇ-ਆਪਣੇ ਐਪ ਉਸੇ ਸੇਅਰ ਕੀਤੇ ਸਰਵਿਸਾਂ ਤੇ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਨਵੀਂ ਇਮਾਰਤ ਬਣਾਏ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ।
ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੋਚੋ: ਇੱਕ ਇਕਲੋਤਾ ਕਮਰੇ ਦੀ ਖਰੀਦ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕ ਦਫ਼ਤਰ ਦੀ ਇਮਾਰਤ ਕਿਰਾਏ ਤੇ ਲੈਣਾ। ਤੁਸੀਂ ਮਿਆਰੀ CRM ਕਮਰੇ ਹੀ ਪਾਓਗੇ, ਪਰ ਜਦ ਵੀ ਤੁਸੀਂ ਨਵੇਂ ਕਮਰੇ ਜੋੜਦੇ ਹੋ ਤਾਂ ਉਸ ਦੇ ਲਈ ਪਲੰਬਿੰਗ, ਸੁਰੱਖਿਆ ਅਤੇ ਮੇਂਟੇਨੈਂਸ ਵੀ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਡੇ ਕਸਟਮ ਐਪ ਉਸੇ ਮਾਹੌਲ ਵਿੱਚ ਰਹਿਣਗੇ ਜਿੱਥੇ ਤੁਹਾਡਾ CRM ਡੇਟਾ, UI ਅਤੇ ਅਨੁਮਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਆਧੁਨਿਕ ਸਾਥੀ ਤਰਜਮਾ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਕਿ ਨਵੇਂ “build-by-chat” ਟੂਲਾਂ ਕਿਵੇਂ ਇੱਕ ਵਿਚਾਰ ਅਤੇ ਕੰਮ ਕਰਦੀ ਐਪ ਦਰਮਿਆਨ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਵੱਜੋਂ, Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ (React ਵੈੱਬ ਲਈ, Go + PostgreSQL ਬੈਕਐਂਡ ਲਈ, Flutter ਮੋਬਾਈਲ ਲਈ)। ਇਹ ਬਾਈ-ਡਿਫਾਲਟ CRM ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦਾ, ਪਰ ਇਹ ਉਨ੍ਹਾਂ ਅੰਤਰਵਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਬਹੁਤ موزوں ਹੈ ਜੋ CRM ਅਕਸਰ ਲੋੜਦੀਆਂ ਹਨ—intake ਫਾਰਮ, ਅਨੁਮੋਦਨ ਟੂਲ, ਲਾਈਟਵੇਟ ਪੋਰਟਲ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸਹਾਇਕ—ਖਾਸ ਕਰਕੇ ਜਦ ਤੇਜ਼ੀ ਅਤੇ ਸਰੋਤ-ਕੋਡ ਨਿਰਯਾਤ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ CRM ਪਲੇਟਫਾਰਮ ਕੁਝ ਦੁਹਰਾਏ ਜਾਂਦੇ ਪ੍ਰimitives 'ਤੇ ਬਣੇ ਹੁੰਦੇ ਹਨ:
ਮਕਸਦ ਨਵੀਂ ਚੀਜ਼ ਬਣਾਉਣ ਨਹੀਂ—ਇਹ ਇੱਕੋ ਜਿਹਾ ਹੋਣਾ ਹੈ। ਜਦ ਇਹ ਬਲੌਕ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਕਸਟਮ ਐਪ ਉਹੀ ਲਾਗਇਨ, ਰਿਪੋਰਟਿੰਗ, ਮੋਬਾਈਲ ਪਹੁੰਚ ਅਤੇ ਐਡਮਿਨ ਕੰਟਰੋਲ ਵਾਰਸਾਂ ਵਿਚਾਲੇ ਵਰਤਦਾ ਹੈ ਜੋ ਕੋਰ CRM ਦਿੰਦਾ ਹੈ।
ਮਿਆਰੀ CRM ਫੀਚਰ ਵੇਚਣ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਫੀਚਰ ਤੁਹਾਡੇ ਕੰਪਨੀ ਦੇ ਅਸਲੀ ਤਰੀਕੇ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ: ਭਾਈਦਾਰੀ ਪ੍ਰੋਗਰਾਮ, ਅਨੁਕੂਲਤਮ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਸੇਵਾ ਈਸਕਲੇਸ਼ਨ, renewals, onboarding ਅਤੇ ਅੰਦਰੂਨੀ ਬਿਨਤੀਆਂ। ਹਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ “opportunities” ਜਾਂ spreadsheets ਵਿੱਚ ਲੈ ਜਾਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਬਿਜ਼ਨਸ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਮਾਡਲ ਕਰੋ ਜਿਵੇਂ ਇਹ ਚਲਦਾ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ resellers ਨੂੰ onboarding ਕਰਨਾ ਹੈ। ਤੁਸੀਂ Partner Application ਨਾਂ ਦਾ ਇੱਕ ਕਸਟਮ ਆਬਜੈਕਟ ਬਣਾਉਂਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਫੀਲਡ Company Name, Territory, Tax ID, Risk Score ਅਤੇ Status ਹੋਣ।
ਫਿਰ ਤੁਸੀਂ ਇੱਕ approval flow ਜੋੜਦੇ ਹੋ: ਜਦ Status = “Submitted” ਹੋਵੇ, ਇਹ Legal, ਫਿਰ Finance, ਫਿਰ Partner Manager ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ। ਜੇ ਮਨਜ਼ੂਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਰਿਕਾਰਡ ERP ਵਿੱਚ partner ਬਣਾਉਣ ਲਈ API ਕਾਲ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ, ਅਤੇ CRM ਆਪਣੇ-ਆਪ ਨੂੰ training ਲਈ follow-up tasks ਬਣਾਉਂਦਾ ਹੈ।
ਇਹੀ ਪਲੇਟਫਾਰਮ ਦਾ ਵਾਅਦਾ ਹੈ: CRM ਸਿਰਫ਼ ਇੱਕ ਟੂਲ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਬੁਨਿਆਦ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ।
ਇੱਕ CRM “ਕੇਵਲ ਸਾਫਟਵੇਅਰ” ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹ ਇੱਕ ਹਬ ਬਣ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਹੋਰ ਕਾਰੋਬਾਰ—ਅਤੇ ਗਾਹਕ ਖ਼ੁਦ—ਇਸਦੇ ਫੰਕਸ਼ਨ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ। ਦੂਜਾ ਰਾਸ਼ਤਾ ਇਕ ਇਕੋਸਿਸਟਮ ਹੈ।
Salesforce ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਸ਼ਾਮِل ਹਨ:
ਇਹ ਸਮੂਹ ਤੇਖੇਖਤ ਦਾਖ਼ਲਾ ਨਹੀਂ ਹਨ। ਉਹ reusable ਹੱਲ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਅਪਣਾ ਸਕਦੀਆਂ ਹਨ, ਸਿਰਫ਼ ਇੱਕ-off custom ਕੰਮ ਨਹੀਂ।
ਗਾਹਕ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹਨ—ਤੇਜ਼ ਵਿਸ਼ਕਲਿਕ ਵਿਕਰੀ, ਸਾਫ਼ ਡੇਟਾ, ਚੰਗੀ ਰਿਪੋਰਟਿੰਗ—ਨਾਹ ਕਿ ਲੰਬਾ ਬਿਲਡ ਪ੍ਰੋਜੈਕਟ। ਮਾਰਕੀਟਪਲੇਸ ਮਾਡਲ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ add-ons ਚੁਣ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ।
파트ਨਰਾਂ ਲਈ ਫਾਇਦਾ ਵੀ ਸਾਦਾ ਹੈ: ਵਿਤਰਨ। ਹਰ ਸੌਦੇ ਨੂੰ ਨਵਾਂ ਇਨਕਮ ਸੁਰੂ ਕਰਨ ਦੀ ਥਾਂ, ਉਹ ਪਲੇਟਫਾਰਮ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਜੁੜੇ ਖਰੀਦਦਾਰਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਬਿਲਿੰਗ, ਟਰਾਇਲ ਅਤੇ ਸਮੀਖਿਆਵਾਂ ਖਰੀਦਦਾਰਾਂ ਦੀ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
AppExchange ਵਪਾਰਿਕ ਸਾਫਟਵੇਅਰ ਲਈ “ਐਪ ਸਟੋਰ” ਵਰਗਾ ਹੈ। ਕੰਪਨੀਆਂ add-ons—CPQ, e-signature, support ਟੂਲ, ਉਦਯੋਗ-ਖਾਸ ਵਰਕਫਲੋਜ਼—ਖੋਜ ਸਕਦੀਆਂ ਹਨ, ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ ਇੰਸਟਾਲ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਸਭ ਕੁਝ ਆਪਣੇ CRM ਡੇਟਾ ਨਾਲ ਜੋੜਿਆ ਰੱਖ ਸਕਦੀਆਂ ਹਨ।
ਜਦੋਂ ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਵੇਖਦੇ ਹੋ:
ਨਤੀਜਾ ਇੱਕ ਐਸਾ CRM ਹੈ ਜੋ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਨਾਲ ਵੱਧਦਾ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਇੱਕ ਵੇਂਡਰ ਤੋਂ ਹਰ ਫੀਚਰ ਦੀ ਉਡੀਕ ਕੀਤੇ।
CRM ਦੀ ਵਰਤੋਂ ਉਸ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਇਸ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਗਾਹਕ ਡੇਟਾ ਕਦੇ ਇਕ ਜਗ੍ਹਾ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦਾ: sales ਈਮੇਲ Outlook ਜਾਂ Gmail ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ, invoices ਇੱਕ ERP ਜਾਂ ਅਕਾਉਂਟਿੰਗ ਟੂਲ ਵਿੱਚ, support ਇਤਿਹਾਸ helpdesk ਵਿੱਚ, ਅਤੇ marketing ਸਰਗਰਮੀ ਕਿਸੇ ਹੋਰ ਸਿਸਟਮ ਵਿੱਚ ਟਰੈਕ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜਦ ਇਹ ਟੂਲ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਅਪਡੇਟ ਸ਼ੇਅਰ ਨਹੀਂ ਕਰਦੇ, ਟੀਮਾਂ ਨੰਬਰਾਂ 'ਤੇ ਤਕਰਾਰ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਸੇਵਾਵਾਂ ਮਿਲਦਿਆਂ ਟੁੱਟ-ਫੱਟ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਕੰਪਨੀਆਂ ਅਕਸidentalਯਤਨ "ਕਈ ਸੱਚਾਈਆਂ ਦੀਆਂ ਵਰਜਨਾਂ" ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ sales ਰੈਪ CRM 'ਚ ਫੋਨ ਨੰਬਰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, support ਟਿਕਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਵੱਖਰਾ ਨੰਬਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ finance ਦੇ ਕੋਲ billing ਨਾਲ ਜੁੜਿਆ ਹੋਰ contact record ਹੁੰਦਾ ਹੈ। ਨਤੀਜਾ ਡੂਪਲੀਕੇਟ ਕੰਮ, ਮੁੰਹ ਵੇਖਣ ਸਮੇਂ ਗੁਲਤੀਆਂ ਅਤੇ ਬੇਭਰੋਸੇ ਰਿਪੋਰਟਾਂ ਹਨ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਇਕ-ਦੂਜੇ ਨਾਲ ਕੰਟਰੋਲਡ ਤਰੀਕੇ ਨਾਲ ਗੱਲ ਕਰਨ ਦੇਣ ਸਮਝੋ। API ਦਰਾਜ਼ੇ ਅਤੇ ਨਿਯਮ ਹਨ ਜੋ ਇੱਕ ਐਪ ਹੋਰ ਐਪ ਨੂੰ ਡੇਟਾ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਲਈ ਦੇਂਦੇ ਹਨ—ਜਿਵੇਂ “create a lead”, “update an account” ਜਾਂ “fetch the latest invoice status”。Connectors ਉਸ ਕੰਮ ਨੂੰ ਤਿਆਰ‑ਬਨਾਏ ਲਿੰਕਾਂ ਵਿੱਚ ਪੈਕ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸ਼ੁਰੂ ਤੋਂ ਨਾ ਬਣਾਉ।
ਜਦ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੈੱਟ ਹੁੰਦੀਆਂ ਹਨ, CRM system of record ਬਣ ਜਾਂਦਾ ਹੈ: ਓਥੇ ਲੋਕ ਮੌਜੂਦਾ ਗਾਹਕ ਪ੍ਰੋਫਾਈਲ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਹੋਰ ਟੂਲ ਆਪਣੀਆਂ ਖ਼ਾਸ ਭੂਮਿਕਾਵਾਂ ਜਾਰੀ ਰੱਖਦੇ ਹਨ।
ਜਦ CRM ਈਮੇਲ, ਬਿਲਿੰਗ, ਸਹਾਇਤਾ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨਾਲ ਜੁੜ ਜਾਂਦਾ ਹੈ, ਇਹ "ਵਿਕਰੀ ਦਾ ਟੂਲ" ਰਹਿਣਾ ਛੱਡ ਦਿੰਦਾ ਅਤੇ workflow hub ਬਣ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਸਿਸਟਮ ਬਦਲਣਾ ਉਹਨਾਂ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਮੁੜ-ਵਾਇਰ ਕਰਨਾ, ਡੇਟਾ ਮਾਈਗਰੇਟ ਕਰਨਾ, ਟੀਮਾਂ ਨੂੰ ਦੁਬਾਰਾ ਟ੍ਰੇਨ ਕਰਨਾ ਅਤੇ ਡਾਊਨਟਾਈਮ ਨੂੰ ਜੋਖਣਾ ਬਣ ਜਾਂਦਾ ਹੈ—ਇਸ ਲਈ CRM ਨੂੰ ਬਦਲਨਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇੱਕ SaaS ਉਤਪਾਦ “enterprise‑ready” ਹੈ, ਉਹ ਅਕਸਰ ਇਹ ਮੱਤਲਬ ਹੈ: ਤੁਸੀਂ ਇਹਨੂੰ ਹਜ਼ਾਰਾਂ ਯੂਜ਼ਰਾਂ, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਅਤੇ ਸਖ਼ਤ ਅੰਦਰੂਨੀ ਨਿਯਮਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਹਰ ਐਡਜਸਟਮੈਂਟ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਦੇ।
ਪਹਿਲਾਂ, ਸੁਰੱਖਿਆ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਖਾਸ ਮਾਮਲਿਆਂ ਲਈ। ਇਸਦਾ ਅਰਥ ਮਜ਼ਬੂਤ authentication ਵਿਕਲਪ, ਸਪੱਸ਼ਟ permission ਮਾਡਲ, ਅਤੇ ਅਜਿਹੀ ਰੱਖਿਆ ਹੈ ਜੋ ਅਚਾਨਕ ਡੇਟਾ ਉਜਾਗਰ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਕਰੇ।
ਦੂਜਾ, compliance ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਤਾਕਤਵਰ ਨਿਯੰਤਰਣਾਂ ਬਾਰੇ ਹਨ: ਕੌਣ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ, ਅਨੁਮਤੀ ਕਿਵੇਂ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਕੀ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਹ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ।
ਵੱਡੇ ਪੱਧਰ 'ਤੇ, “ਐਡਮਿਨ ਕੰਟਰੋਲ” ਖੁਦ ਉਤਪਾਦ ਹੈ। Role‑based access control (RBAC) ਤੁਹਾਨੂੰ ਅਨੁਕੂਲਤਾ ਦੇ ਰੂਪ ਵਿੱਚ ਅਨੁਮਤੀਆਂ ਨਕਸ਼ਾ ਕਰਨ ਦਿੰਦਾ—sales reps, managers, support agents, contractors—ਤਾਂ ਜੋ ਲੋਕਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਵੇਖਣ ਨੂੰ ਮਿਲੇ ਜੋ ਉਹਨੂੜੀ ਹੈ।
ਆਡੀਟਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਗਲਤੀਆਂ ਅਤੇ ਵਿਵਾਦ ਹੁੰਦੇ ਹਨ। ਚੰਗੇ ਸਿਸਟਮ ਮੁੱਖ ਘਟਨਾਵਾਂ ਦਰਜ ਕਰਦੇ ਹਨ (ਲੌਗਇਨ, permission ਬਦਲਾਅ, ਡੇਟਾ ਐਕਸਪੋਰਟ, configuration ਸੋਧ) ਤਾਂ ਜੋ ਟੀਮਾਂ مسئਲਿਆਂ ਦੀ ਜਾਂਚ ਜਲਦੀ ਕਰ ਸਕਣ ਅਤੇ ਫੈਸਲੇ ਸਟੇਕਹੋਲਡਰਾਂ ਨੂੰ ਸਮਝਾ ਸਕਣ।
ਚੇਂਜ ਮੈਨੇਜਮੈਂਟ ਲਗਾਤਾਰ ਅਪਡੇਟਾਂ ਦੇ ਪਿੱਛੇ ਦੀ ਸ਼ਾਂਤ ਲੋੜ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੂੰ ਸੋਧ ਦੀ ਜਾਂਚ ਕਰਨ, ਕੌਣ configuration ਬਦਲ ਸਕਦਾ ਹੈ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਅਤੇ ਨਵੇਂ ਫੀਚਰਾਂ ਨੂੰ ਆਪਣੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਸਮੇਂ ਰੋਲ-ਆਉਟ ਕਰਨ ਦੇ ਤਰੀਕੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ subscription utility ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਇਹ ਉਪਲਬਧ ਰਹੇਗਾ। ਉਪਲਬਧਤਾ ਦੇ ਇਲਾਵਾ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਘਟਨਾ ਸੰਚਾਰ ਚਾਹੀਦਾ ਹੈ: ਕੀ ਹੋਇਆ, ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੈ, ਮੌਜੂਦਾ ਸਥਿਤੀ, ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ ਇਸਨੂੰ ਰੋਕਣ ਲਈ ਕੀ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਪਾਰਦਰਸ਼ੀ ਅਪਡੇਟਾਂ ਗਲਤਫਹਮੀਆਂ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਭਰੋਸਾ ਬਚਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਆਪਣਾ ਅੰਦਰੂਨੀ ਜਵਾਬ ਸਮਨਵਯ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
Salesforce ਸਿਰਫ CRM ਸੌਲਡ ਨਹੀਂ ਕੀਤਾ—ਇਸਨੇ ਇੱਕ ਥਾਂ ਬਣਾਈ ਜਿੱਥੇ ਹੋਰ ਕੰਪਨੀਆਂ ਇਸਨੂੰ ਵਧਾ ਸਕਦੀਆਂ। ਇਹ ਇਕੋਸਿਸਟਮ ਮੋਟ ਬਣ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਜਦ ਹੋਰ ਲੋਕ ਭਾਗ ਲੈਂਦੇ ਹਨ, ਮੁੱਲ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸਿਹਤਮੰਦ ਮਾਰਕੀਟਪਲੇਸ ਇੱਕ ਸਧਾਰਣ ਲੂਪ ਬਣਾਉਂਦਾ ਹੈ: ਹੋਰ ਐਪ ਅਤੇ ਪਾਰਟਨਰ ਪ੍ਰੋਡਕਟ ਨੂੰ ਜ਼ਿਆਦਾ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਜੋ ਹੋਰ ਗਾਹਕ ਖਿੱਚਦਾ ਹੈ, ਜੋ ਹੋਰ ਬਿਲਡਰਾਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਹੋਰ ਐਪ ਬਣਾਉਂਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਖਰੀਦਦਾਰ “ਇੱਕ CRM” ਦੀ ਜਾਂਚ ਕਰਨਾ ਛੱਡ ਕੇ “ਇਸ CRM ਨਾਲ ਅਸੀਂ ਜੋ ਕੁਝ ਕਰ ਸਕਦੇ ਹਾਂ” ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ।
ਪਲੇਟਫਾਰਮ ਦੀ ਗਹਿਰਾਈ ਰਿਸ਼ਤੇ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਜਦ ਕੰਪਨੀ ਦੀ ਵਿਕਰੀ ਪ੍ਰਕਿਰਿਆ, ਗਾਹਕ ਡੇਟਾ, automations, ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਤੀਜੀ-ਪੱਖ ਟੂਲ ਸਾਰੇ ਇੱਕ ਹੀ ਵਾਤਾਵਰਣ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਤਾਂ ਇਸ ਨੂੰ ਬਦਲਣਾ ਇੱਕ weekend ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਰਹਿੰਦਾ। ਲਾਗਤ ਸਿਰਫ਼ ਲਾਇਸੈਂਸਿੰਗ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਟੀਮਾਂ ਨੂੰ ਦੁਬਾਰਾ ਟ੍ਰੇਨ ਕਰਨ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੁਬਾਰਾ ਬਣਾਉਣ, ਅਤੇ ਸਾਲਾਂ ਦੀ ਸਾਂਝੀ ਗਿਆਨ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਲਾਗਤ ਹੁੰਦੀ ਹੈ। ਇਹ switching costs ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਗਾਹਕ ਦੀ ਉਮਰ ਲੰਬੀ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇਕੋਸਿਸਟਮ expansion ਨੂੰ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ। ਇੱਕ ਟੀਮ ਕੋਰ CRM ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ, ਫਿਰ marketing, service, analytics ਜਾਂ ਉਦਯੋਗ ਪੈਕੇਜ ਜੋੜ ਸਕਦੀ ਹੈ। ਜਾਂ ਉਹ ਵਿਸ਼ੇਸ਼ ਐਪ ਸ਼ਾਮਿਲ ਕਰ ਸਕਦੇ ਹਨ: CPQ, contract management, data enrichment, customer support add-ons। ਪਲੇਟਫਾਰਮ ਇੱਕ ਮੇਨੂ ਬਣ ਜਾਂਦਾ—ਅਪਸੇਲ ਅਗਲੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਵਾਲੀਆਂ ਉਤਪਾਦੀਆਂ ਰਾਹੀਂ ਹੁੰਦਾ ਹੈ।
ਇਕੋਸਿਸਟਮ ਪਿੱਛਾ ਫੇਰ ਕੇ ਨੁਕਸਾਨ ਵੀ ਦੇ ਸਕਦੇ ਹਨ। ਜਦ organization apps ਇਕੱਠੇ ਕਰ ਲੈਂਦੇ ਹਨ, ਐਡਮਿਨ ਕੰਮ ਵਧਦਾ ਹੈ, ਕਾਰਗੁਜ਼ਾਰੀ ਗਿਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ ਅਨੁਭਵ ਅਸੰਮੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਐਪ ਦੀ ਕੁਆਲਿਟੀ ਬਦਲਦੀ ਹੈ: ਸੁਰੱਖਿਆ ਅਭਿਆਸ, ਸਹਾਇਤਾ, ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਰਖਿਆ ਸਮਾਨ ਨਹੀਂ ਹੁੰਦੀ।
ਭਰੋਸਾ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ, ਪਲੇਟਫਾਰਮ ਮਾਲਕ ਨੂੰ ਮਜ਼ਬੂਤ ਗਵਰਨੈਂਸ ਚਾਹੀਦੀ ਹੈ—ਸਪਸ਼ਟ ਸਰਟੀਫਿਕੇਸ਼ਨ ਮਿਆਰ, ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਅਨੁਮਤੀਆਂ ਨਿਯੰਤਰਣ, ਅਤੇ ਬੁਰੇ ਕਾਰਜ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਨਤੀਜੇ—ਨਹੀਂ ਤਾਂ ਮੋਟ ਜਟਿਲਤਾ ਕ੍ਰੀਪ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ ਜੋ ਗਾਹਕ ਨੂੰ ਨਾਪਸੰਦ ਹੋਵੇ।
CRM ਇੱਕ "ਕੇਵਲ ਸਾਫਟਵੇਅਰ" ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤਕ ਇਹ ਰੋਜ਼ਾਨਾ ਕਾਰੋਬਾਰੀ ਪਰਤ ਨਹੀਂ ਬਣਦਾ। ਚੰਗੀ ਚੋਣ ਬ੍ਰੈਂਡ ਨਾਂ ਤੋਂ ਵੱਧ ਫਿੱਟ ਬਾਰੇ ਹੁੰਦੀ ਹੈ।
ਚਾਰ ਸਵਾਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਫਿਰ budget ਨੂੰ license ਕੀਮਤ ਤੋਂ ਅੱਗੇ ਧੱਕੋ: ਐਡਮਿਨ ਸਮਾਂ, ਟ੍ਰੇਨਿੰਗ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਕੋਈ ਭੁਗਤਾਨ ਕੀਤੀਆਂ marketplace apps।
ਜੇ ਤੁਸੀਂ ਕਈ ਕਸਟਮ ਵਰਕਫਲੋਜ਼ ਬਣਾਉਣ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਆਪਣੇ “build surface area” ਨੂੰ ਵੀ ਮੁਲਾਂਕਣ ਕਰੋ: ਕੀ ਤੁਸੀਂ CRM ਪਲੇਟਫਾਰਮ ਅੰਦਰ ਵਧਾਉਗੇ, ਐਪ ਖਰੀਦੋਗੇ, ਜਾਂ ਅਲੱਗ ਇੰਟਰਨਲ ਟੂਲ ਬਣਾਉਗੇ? ਜਿਹੜੀਆਂ ਟੀਮਾਂ ਬਣਾਉਣਾ ਚੁਣਦੀਆਂ ਹਨ ਉਹ ਅਕਸਰ ਤੇਜ਼ iteration ਅਤੇ ਨਿਯੰਤਣ ਲਈ ਦੇਖਦੀਆਂ ਹਨ—ਉਦਾਹਰਨ ਲਈ ਸਰੋਤ ਕੋਡ ਨਿਕਾਸ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, snapshots, ਅਤੇ rollback। (Koder.ai, ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, ਸਰੋਤ ਕੋਡ ਨਿਕਾਸ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, snapshots ਅਤੇ rollback ਦਾ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ—ਜਦ ਤੁਹਾਡਾ CRM ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਕਸਟਮ ਸਹਾਇਕ ਐਪ ਸ਼ਾਮਿਲ ਹੋਵੇ ਤਾਂ ਇਹ ਲੱਭਣਯੋਗ ਹੁੰਦਾ ਹੈ)।
ਇੱਕ rollout ਨੂੰ ਆਪਣੀ ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਆਪਣੇ ਉਤਪਾਦ ਲਾਂਚ ਵਾਂਗ ਸਮਝੋ:
ਜਦੋਂ ਤੁਸੀਂ ਮਾਰਕੀਟਪਲੇਸ (ਜਿਵੇਂ AppExchange‑style ecosystems) ਤੋਂ ਐਪਾਂ ਚੁਨ ਰਹੇ ਹੋ, ਤਾਂ ਜਾਂਚ ਕਰੋ:
ਹਰ ਪੁਰਾਣੀ spreadsheet ਨੂੰ ਦੁਹਰਾਉਣ ਦਾ ਮਨ ਹੋ ਸਕਦਾ ਹੈ। ਕੋਰ ਵਰਕਫਲੋਜ਼ (lead → opportunity → customer) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਉਦੋਂ ਜ਼ਿਆਦਾ ਜਟਿਲਤਾ ਜੋੜੋ ਜਾਂ ਲੋਕ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਨੂੰ ਵਰਤ ਰਹੇ ਹੋਣ।
Salesforce ਦੀ ਕਹਾਣੀ ਨੂੰ ਯਾਦ ਰੱਖਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ ਜਦ ਤੁਸੀਂ ਤਿੰਨ ਕੰਧੀਆਂ ਨੂੰ ਇਕੱਠੇ ਵੇਖੋ: SaaS delivery, ਕੁਝ ਵੱਡਾ CRM ਕੈਟਾਗਰੀ ਫੋਕਸ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਇਕੋਸਿਸਟਮ। SaaS ਨੇ ਵੰਡ ਅਤੇ ਅਪਡੇਟ friction ਘਟਾਇਆ। CRM ਨੇ ਉਤਪਾਦ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ “ਕੰਮ” ਦਿੱਤਾ (ਰਿਸ਼ਤੇ ਪ੍ਰਬੰਧਨ, ਰੇਵਨਿਊ ਫੋਰਕਾਸਟ, ਵਿਕਰੀ ਦਾ ਕੋਆਰਡੀਨੇਸ਼ਨ)। ਪਲੇਟਫਾਰਮ ਅਤੇ ਮਾਰਕੀਟਪਲੇਸ ਨੇ ਮੁੱਲ ਨੂੰ ਗੁਣਾ ਕੀਤਾ ਕਿਉਂਕਿ ਗਾਹਕ ਅਤੇ ਪਾਰਟਨਰ ਕੋਰ ਨੂੰ ਬਿਨਾਂ ਵੇਂਡਰ ਦੇ ਰੋਡਮੈਪ ਦੀ ਉਡੀਕ ਕੀਤੇ ਵਿਸਥਾਰ ਸਕਦੇ ਹਨ।
ਜਦ ਮਾਡਲ ਸਿਹਤਮੰਦ ਹੁੰਦਾ ਹੈ, ਸਾਫਟਵੇਅਰ ਇੱਕ ਵਾਰੀ ਖਰੀਦ ਵਾਲੀ ਚੀਜ਼ ਵਜੋਂ ਨਹੀਂ ਪਰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੇਵਾ ਵਾਂਗ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਸਬਸਕ੍ਰਾਇਬ ਕਰਦੇ ਹੋ, ਇਹ ਲਗਾਤਾਰ ਸੁਧਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਇਹ ਤੁਹਾਡੇ ਹੋਰ ਸਿਸਟਮਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਪ੍ਰਸ਼ਾਸਨ ਨਿਯਮਤ ਨਿਯੰਤਰਣ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਵੇਂਡਰ ਨੀਯਮਤ ਆਮਦਨੀ ਕਮਾਂਦਾ ਹੈ ਜੋ ਲਗਾਤਾਰ ਅਪਡੇਟਾਂ ਨੂੰ ਫੰਡ ਕਰਦੀ ਹੈ; ਗਾਹਕ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਪਾਉਂਦੇ ਹਨ ਜੋ ਕਰੰਟ ਰਹਿੰਦਾ ਹੈ; ਪਾਰਟਨਰ ਕਿਨਾਰੇ ਦੇ ਮਾਮਲੇ ਭਰ ਦਿੰਦੇ ਹਨ; ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਡੇਟਾ ਦੀ ਦੁਹਰਾਈ ਘਟਾਉਂਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਉਤਪਾਦ ਰੋਜ਼ਾਨਾ ਚਲਾਉਣ ਦੀ ਪਰਤ ਬਣ ਜਾਂਦਾ ਹੈ—ਕੇਵਲ ਇੱਕ ਐਪ ਨਹੀਂ।
ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ blueprint ਨੂੰ ਪੀੜ੍ਹਕ ਕਰੋ:
ਇੱਕ ਹੋਰ ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਜੋ SaaS ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਵੱਧ ਚੱਲਦਾ ਹੈ: ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਉਹ “edge workflows” ਬਣਾ (ਜਾਂ ਮੁੜ-ਬਣਾ) ਸਕਦੇ ਹੋ ਜੋ CRM ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬੈਠੇ ਹੁੰਦੇ ਹਨ? ਚਾਹੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ ਅੰਦਰ ਵਧਾਓ, ਮਾਰਕੀਟਪਲੇਸ ਤੋਂ ਖਰੀਦੋ, ਜਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਕਸਟਮ ਐਪ ਬਣਾਓ—ਸਪੀਡ‑ਟੂ‑ਸੋਲੂਸ਼ਨ ਅਤੇ ਗਵਰਨੈਂਸ (exports, deployments, rollback) ਅਕਸਰ CRM ਫੀਚਰ ਲਿਸਟ ਜਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਖੋਜ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ blog ਪੜ੍ਹੋ deeper comparisons ਲਈ, ਜਾਂ pricing ਵੇਖੋ ਤਾਂ ਕਿ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਡਿਜ਼ਾਈਨ ਕਿਵੇਂ ਕੁੱਲ ਖ਼ਰਚ 'ਤੇ اثر ਪਾਂਉਂਦਾ ਹੈ۔
ਇਹ ਉਹ ਸੋਫਟਵੇਅਰ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਮਾਲਕ ਨਹੀਂ ਬਣਦੇ ਪਰ ਲਗਾਤਾਰ ਵਰਤਦੇ ਹੋ। ਤੁਸੀਂ ਮੁੜ-ਮੁੜ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਅਤੇ ਵੇਂਡਰ ਇੰਫਰਾਸਟਰੱਕਚਰ, ਪੈਚ ਅਤੇ ਸਕੇਲਿੰਗ ਦੀ ਦੇਖਭਾਲ ਕਰਦਾ ਹੈ।
CRM ਗਾਹਕਾਂ ਨਾਲ ਹੋਈਆਂ ਗੱਲਬਾਤਾਂ ਅਤੇ ਅਗਲੇ ਕਦਮਾਂ ਦਾ ਜ਼ਿੰਦਾ ਰਿਕਾਰਡ ਹੁੰਦਾ ਹੈ। ਟੀਮ ਇਸਨੂੰ ਇਸ ਲਈ ਵਰਤਦੀ ਹੈ ਤਾਂ ਕਿ ਕੰਮ ਦੇ ਹੱਥ ਭਟਕਣ ਘਟਣ, ਜ਼ਿੰਮੇਵਾਰੀ ਸਾਫ਼ ਹੋਵੇ ਅਤੇ pipeline ਟਰੈਕਿੰਗ, ਕੇਸ ਇਤਿਹਾਸ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਰਾਹੀਂ ਵਿਕਰੀ ਦੀ ਗਤੀ ਸਪੱਸ਼ਟ ਹੋਵੇ।
On‑prem CRM ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸੇਰਵਰ, ਲੰਬੀਆਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਬਦਲਾਅ ਲਈ IT ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਪਗ੍ਰੇਡਜ਼ ਖਤਰਨਾਕ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨਾਂ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ, ਜਿਸ ਕਾਰਨ ਟੀਮਾਂ ਪੁਰਾਣੇ ਵਰਜ਼ਨਾਂ 'ਤੇ ਫਸ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਡੇਟਾ ਗੁਣਵੱਤਾ ਅਸਮਨਤ ਰਹਿੰਦੀ ਹੈ।
SaaS ਬਰاؤਜ਼ਰ ਜਾਂ ਐਪ ਰਾਹੀਂ ਐਕਸੈਸ ਕੀਤਾ ਜਾਣ ਵਾਲਾ ਸੋਫਟਵੇਅਰ ਹੈ ਜਿਸਦੇ ਹੋਸਟਿੰਗ, ਸੁਰੱਖਿਆ ਪੈਚ ਅਤੇ ਅਪਡੇਟ ਵੇਂਡਰ ਸੰਭਾਲਦਾ ਹੈ。
ਮੁੱਖ ਫਰਕ:
Multi‑tenancy ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਈ ਗਾਹਕ ਇੱਕੇ ਹੀ ਬੁਨਿਆਦੀ ਇਨਫਰਾਸਟਰੱਕਚਰ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਪਰ ਹਰ ਗਾਹਕ ਦਾ ਡੇਟਾ ਤਰਕੀਬੀ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਦਾਤਾ ਇੱਕ ਹੀ ਮਿਆਰੀ ਸਿਸਟਮ ਨੂੰ ਰੱਖ ਸਕਦਾ ਹੈ, ਬਗਜ਼ ਇੱਕ ਵਾਰੀ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਫੀਚਰ ਸਭ ਲਈ ਰੋਲ ਆਉਟ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਹਰ ਗਾਹਕ ਦੇ ਵੱਖ-ਵੱਖ ਅਪਗ੍ਰੇਡ ਦੀ ਉਡੀਕ ਕੀਤੇ।
ਲਗਾਤਾਰ ਅਪਡੇਟ ਗਾਹਕਾਂ ਲਈ “ਅਪਗ੍ਰੇਡ ਸੀਜ਼ਨ” ਦੇ ਬੋਝ ਨੂੰ ਘਟਾ ਦਿੰਦੇ ਹਨ: ਘੱਟ ਸੂਚਨਾ-ਯੋਜਨਾ, ਘੱਟ ਡਾਊਨਟਾਈਮ ਅਤੇ ਨਵੇਂ ਫੀਚਰ ਤੁਰੰਤ ਮਿਲਦੇ ਹਨ। ਟਰੇਡਆਫ਼ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਚੰਗੀ ਚੇਂਜ-ਮੈਨੇਜਮੈਂਟ (ਟੈਸਟਿੰਗ, ਅਨੁਮਤੀਆਂ, ਰਿਲੀਜ਼ ਨਿਯੰਤਰਣ) ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਅਪਡੇਟ ਅੰਦਰੂਨੀ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਵਿਘਟਿਤ ਨਾ ਕਰਨ।
ਇੱਕ ਪ੍ਰੋਡਕਟ CRM ਤੁਹਾਨੂੰ ਪੂਰਬ-ਨੀਰਧਾਰਤ ਫੀਚਰ ਦਿੰਦਾ ਹੈ (accounts, contacts, opportunities, reports)। ਇੱਕ ਪਲੇਟਫਾਰਮ reusable building blocks ਦਿੰਦਾ ਹੈ—ਕਸਟਮ ਡੇਟਾ ਆਬਜੈਕਟ, automation, ਸੁਰੱਖਿਆ ਮਾਡਲ ਅਤੇ APIs—ਤਾਂ ਜੋ ਤੁਸੀਂ ਵਿਲੱਖਣ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਉਦਾਹਰਨ ਵਜੋਂ onboarding, renewals, compliance) ਨੂੰ ਉਸੇ ਸਿਸਟਮ ਵਿੱਚ ਮਾਡਲ ਕਰ ਸਕੋ।
ਮਾਰਕੀਟਪਲੇਸ (ਜਿਵੇਂ AppExchange‑style ecosystem) ਪ੍ਰਮਾਣਿਤ add-ons ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਿਪੁੰਨਤਾ ਪੇਸ਼ ਕਰਕੇ ਮੁੱਲ ਵਧਾਉਂਦਾ ਹੈ।
ਇਨਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਲਾਸ਼ ਕਰੋ:
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸਿਸਟਮਾਂ ਨੂੰ ਇਕ ਦੂਜੇ ਨਾਲ ਨਿਯੰਤਰਿਤ ਢੰਗ ਨਾਲ ਗੱਲ ਕਰਨ ਦਿੰਦੇ ਹਨ। API ਦਰਵਾਜੇ ਅਤੇ ਨਿਯਮ ਹਨ ਜੋ ਇੱਕ ਐਪ ਹੋਰ ਐਪ ਨੂੰ ਡੇਟਾ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ—ਜਿਵੇਂ “lead ਬਣਾਓ”, “account ਅਪਡੇਟ ਕਰੋ” ਜਾਂ “ਆਖ਼ਰੀ invoice ਸਥਿਤੀ ਲਓ”。
ਵਿਹਾਰਕ ਚੈੱਕਲਿਸਟ:
“Enterprise‑ready” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਹਜ਼ਾਰਾਂ ਯੂਜ਼ਰ, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਅਤੇ ਸਖ਼ਤ ਨਿਯਮਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਹਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਦੇ।
ਮੁੱਖ ਤੱਤਾਂ ਵਿੱਚ ਸ਼ਾਮِل ਹਨ:
