B2B ਸਥਾਪਕਾਂ ਲਈ ਵਿਕਰੀ ਪਾਈਪਲਾਈਨ ਸਕੀਮਾ: ਘੱਟੋ-ਘੱਟ ਫੀਲਡ, ਸਟੇਜ ਅਤੇ ਐਕਟਿਵਿਟੀ ਟ੍ਰੈਕਿੰਗ ਤਾਂ ਜੋ ਸਪਸ਼ਟ ਫੋਰਕਾਸਟ ਮਿਲੇ ਅਤੇ CRM ਬਲੋਟ ਤੋਂ ਬਿਨਾਂ ਡੀਲਾਂ ਚਲਦੀਆਂ ਰਹਿਣ।

ਸ਼ੁਰੂ ਵਿੱਚ ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ ਸਾਫ਼ ਲੱਗਦੀ ਹੈ ਕਿਉਂਕਿ ਸਿਰਫ਼ ਕੁਝ ਡੀਲਾਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਜਿਆਦਾਤਰ ਸੰਦਰਭ ਤੁਹਾਡੇ ਮਨ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਫਿਰ ਸੂਚੀ ਵਧਦੀ ਹੈ, ਤੁਸੀਂ ਇੱਕ ਫਾਲੋਅਪ ਖੋ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਪਾਈਪਲਾਈਨ ਹਕੀਕਤ ਨਾਲੋਂ ਹੋਰ ਵਧੀਆ ਕਹਾਣੀ ਦੱਸਣ ਲੱਗਦੀ ਹੈ। ਇਹੀ "ਪਾਈਪਲਾਈਨ ਲਾਇੰਗ" ਹੈ: ਮਨ ਤੋਂ ਨਹੀਂ, ਪਰ ਕਿਸੇ ਵੀ ਵਿਧੀ ਨੇ ਸੱਚ ਨੂੰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਬਣਾਇਆ।
ਇਹ ਇੱਕੋ ਜਿਹੇ ਰੁਝਾਨਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਔਸਤ ਪ੍ਰਤਿਕਿਰਿਆ ਸਾਰਥਕ CRM ਵਧਾਉਣਾ ਹੁੰਦਾ ਹੈ: ਹੋਰ ਫੀਲਡ, ਹੋਰ ਕਸਟਮ ਸਟੇਜ, ਲੰਬੀਆਂ ਨੋਟਾਂ। ਵਿਡੰਬਨਾ ਇਹ ਹੈ ਕਿ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਫੋਰਕਾਸਟਿੰਗ ਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਅੱਪਡੇਟ ਕਰਨਾ ਭਾਰੀ ਲੱਗੇ, ਲੋਕ ਘੱਟ ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਪਾਈਪਲਾਈਨ ਚੁੱਪਚਾਪ ਸੜ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਮਿਨੀਮਮ ਵਾਇਐਬਲ ਵਿਕਰੀ ਪਾਈਪਲਾਈਨ ਸਕੀਮਾ ਉਲਟ ਕਰਦਾ ਹੈ। ਇਹ ਫੈਸਲੇ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਢਾਂਚਾ ਹੈ। ਇਹ ਹਰ ਚੀਜ਼ ਕੈਪਚਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਓਹੋ ਘੱਟ ਗੱਲਾਂ ਪਕੜਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਖੁਦ ਨੂੰ ਧੋਖਾ ਦੇਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਨਿਯਮ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਰਤੋ: ਹਰ ਖੁਲੇ ਡੀਲ ਕੋਲ ਹੋਣਾ ਜਰੂਰੀ ਹੈ (1) ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਐਕਸ਼ਨ, (2) ਉਸ ਐਕਸ਼ਨ ਲਈ ਇੱਕ ਤਾਰੀਖ, ਅਤੇ (3) ਇੱਕ ਕਲੋਜ਼ ਤਾਰੀਖ ਜੋ ਕਿਸੇ ਅਸਲ ਖਰੀਦਦਾਰ ਟਾਈਮਲਾਈਨ (ਇੱਕ ਮੀਟਿੰਗ, ਇੱਕ ਲੀਗਲ ਕਦਮ, ਇੱਕ ਬਜਟ ਰਿਵਿਊ) ਨਾਲ ਜੋੜੀ ਹੋਈ ਹੋਵੇ। ਜੇ ਇਨ੍ਹਾਂ ਵਿਚੋਂ ਕੋਈ ਵੀ ਗਾਇਬ ਹੈ, ਡੀਲ ਸਰਗਰਮ ਨਹੀਂ ਹੈ।
ਸਟੇਜਾਂ ਦਾ ਵੀ ਕੋਈ ਮਤਲਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਡੀਲ ਅੱਗੇ ਤਦ ਹੀ ਵਧਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਠੋਸ ਹੋਵੇ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਇਹ ਚੰਗਾ ਲੱਗਦਾ ਹੈ। ਲੱਕੜੀ ਨਹੀਂ, ਨਜ਼ਾਰਾ ਸੁੰਦਰ ਡੈਸ਼ਬੋਰਡ ਨਹੀਂ — ਮਕਸਦ ਇੱਕ ਇਮਾਨਦਾਰ ਨਜ਼ਾਰਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕਾਰੋਬਾਰ ਚਲਾ ਸਕੋ।
ਇੱਕ ਵਿਕਰੀ ਪਾਈਪਲਾਈਨ ਸਕੀਮਾ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਹਰ ਕੋਈ ਇਸਨੂੰ ਇਕੋ ਤਰ੍ਹਾਂ ਵਰਤੇ। ਫੀਲਡ ਜੋੜਨ ਜਾਂ ਸਟੇਜਾਂ ਬਾਰੇ ਵਾਦ-ਵਿਵਾਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇੱਕ ਪਾਈਪਲਾਈਨ ਆਈਟਮ ਦੱਸਦਾ ਕੀ ਹੈ।
B2B ਲਈ ਇੱਕ ਸਾਫ਼ ਡਿਫ਼ਾਲਟ ਇਹ ਹੈ: ਇੱਕ ਡੀਲ = ਇੱਕ ਖਰੀਦ ਫੈਸਲਾ। ਜੇ ਇਕੋ ਕੰਪਨੀ ਦੁਬਾਰਾ ਖਰੀਦ ਸਕਦੀ ਹੈ (ਦੋ ਟੀਮਾਂ, ਦੋ ਉਤਪਾਦ, ਦੋ ਬਜਟ), ਤਾਂ ਉਹ ਦੋ ਵੱਖਰੇ ਡੀਲ ਹਨ, ਇੱਕ ਗੁੰਝਲਦਾਰ ਰਿਕਾਰਡ ਨਹੀਂ।
ਆਬਜੈਕਟ ਸਧਾਰਨ ਰੱਖੋ। ਤੁਸੀਂ ਲੀਡ (ਇੱਕ ਵਿਅਕਤੀ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸੰਪਰਕ ਕਰ ਸਕੋ), ਇੱਕ ਅਕਾਉਂਟ (ਕੰਪਨੀ), ਅਤੇ ਇੱਕ ਡੀਲ (ਉਹ ਖਰੀਦ ਜੋ ਤੁਸੀਂ ਬੰਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ) ਨਾਲ ਕਾਫ਼ੀ ਅੱਗੇ ਜਾ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਸਿੰਗਲ ਹੋ, ਤਾਂ ਫੌਰਮਲ ਲੀਡ ਅਤੇ ਅਕਾਉਂਟ ਰਿਕਾਰਡ ਛੱਡ ਕੇ ਸਿਰਫ਼ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਡੀਲ ਵਿੱਚ ਕੰਪਨੀ ਅਤੇ ਮੁਖ ਸੰਪਰਕ ਦਾ ਨਾਮ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿੱਤਾ ਗਿਆ ਹੈ।
ਕੁਝ ਆਪਰੇਟਿੰਗ ਨਿਯਮ ਲਿਖੋ, ਖਾਸ ਕਰਕੇ ਜੇ ਤੁਹਾਡੇ ਤੋਂ ਸਿਵਾਏ ਹੋਰ ਕੋਈ ਪਾਈਪਲਾਈਨ ਨੂੰ ਛੂਹਦਾ ਹੈ:
ਉਦਾਹਰਣ: ਤੁਸੀਂ Northwind ਦੀਆਂ Alex ਨਾਲ ਫ਼ਾਈਨੈਂਸ ਟੀਮ ਲਈ ਪਾਇਲਟ ਬਾਰੇ ਗੱਲ ਕੀਤੀ। ਉਹ ਇੱਕ ਡੀਲ ਹੈ। ਜੇ ਇੱਕ ਮਹੀਨਾ ਬਾਅਦ ਪ੍ਰੋਡਕਟ ਵੱਖਰਾ ਕੰਟਰੈਕਟ ਚਾਹੁੰਦਾ ਹੈ, ਦੂਜੀ ਡੀਲ ਬਣਾਓ। ਇਕ ਰਿਕਾਰਡ ਨੂੰ ਦੋ ਫੈਸਲਿਆਂ ਨੂੰ ਸਮੇਟਣ ਲਈ ਖਿੱਚੋ ਨਾ।
ਜਦੋਂ ਹਰ ਡੀਲ ਕੋਲ ਉਹੀ ਕੁਝ ਫੀਲਡ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਹਰ ਹਫਤੇ ਜਾਂਚਦੇ ਹੋ, ਪਾਈਪਲਾਈਨ ਲਾਭਦਾਇਕ ਰਹਿੰਦੀ ਹੈ। "ਬਸ-ਇਹ-ਹੋ ਸਕਦਾ-ਹੈ" ਫੀਲਡ ਜੋੜੋ ਅਤੇ ਉਹ ਸਜਾਵਟ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਡੁਪਲਿਕੇਟ ਰੋਕਣ ਵਾਲੇ ਡੀਲ ਨਾਂ ਦਾ ਇੱਕ ਫਾਰਮੈਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਪੈਟਰਨ ਕੰਮ ਕਰਦਾ ਹੈ: ਕੰਪਨੀ - ਉਤਪਾਦ/ਦਾਇਰਾ - ਤਿਮਾਹੀ/ਮਹੀਨਾ। ਉਦਾਹਰਣ: “Acme - Team plan - Mar 2026.” ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ “Acme - Demo” ਅਤੇ “Acme - Follow-up” ਅਕਸਰ ਇੱਕੋ ਡੀਲ ਹੀ ਹੁੰਦੇ ਹਨ।
ਹਰ ਡੀਲ ਨੂੰ ਸਾਫ਼ ਪਹਿਚਾਣ ਵੀ ਚਾਹੀਦੀ ਹੈ:
ਭੂਮਿਕਾ ਅਹੰਕਾਰਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਬਦਲ ਦਿੰਦੀ ਹੈ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ। ਇੱਕ ਚੈਂਪੀਅਨ ਨੂੰ enablement ਦੀ ਲੋੜ ਹੈ। ਫੈਸਲਾ ਕਰਨ ਵਾਲੇ ਨੂੰ ਬਿਜਨੈਸ ਕੇਸ ਚਾਹੀਦਾ ਹੈ।
ਦਾਇਤਵ ਫੀਲਡ ਜੋੜੋ:
ਫਿਰ ਸਿਰਫ਼ ਉਹੀ ਪੈਸਾ ਅਤੇ ਸਮਾਂ ਜੋ ਤੁਸੀਂ ਵਰਤੋਂਗੇ:
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਫੀਲਡ ਬਾਰੇ ਅਨਿਸ਼ਚਿਤ ਹੋ, ਤਾਂ ਛੱਡ ਦਿਓ। ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹੋ। ਫੀਲਡਾਂ ਨੂੰ ਹਟਾਉਣਾ ਆਦਤ ਬਣਨ ਤੋਂ ਬਾਅਦ ਕਠਿਨ ਹੁੰਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ "ਵੱਡੇ" ਪਾਈਪਲਾਈਨ ਵਾਸਤਵ ਵਿੱਚ ਵੱਡੇ ਨਹੀਂ ਹੁੰਦੇ। ਉਹਨਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਐਸੀਆਂ ਡੀਲਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਦੇਖਣ ਵਿੱਚ ਵਧੀਆ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਜ਼ਰੂਰੀ ਰਸਤਾ ਨਹੀਂ ਹੁੰਦਾ।
ਇੱਕ ਫੀਲਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਪਸ਼ਟਤਾ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰੇ: Use case (scope)। ਖਰੀਦਦਾਰ ਕੀ ਹਾਸਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ "ਮੁਕੰਮਲ" ਹੋਣ ਦਾ ਕੀ ਅਰਥ ਹੈ, ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਨਤੀਜਾ ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਡੀਲ ਨੂੰ ਅਜੇ ਤੱਕ ਸਮਝਦੇ ਨਹੀਂ।
ਅਗਲਾ, ਨਿਰਣਯ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਥਾਂ ਤੇ ਕੈਪਚਰ ਕਰੋ। ਇਹ ਸੰਪਰਕਾਂ ਦੀ ਭਰਮਾਰ ਨਹੀਂ ਹੈ। ਇਹ ਬਤਾਉਂਦਾ ਹੈ ਕਿ ਫੈਸਲਾ ਕਿਵੇਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਕੌਣ ਸਾਈਨ ਕਰਦਾ ਹੈ, ਕੌਣ ਰੁਕਾਵਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਕਦਮ ਲੋੜੀਂਦੇ ਹਨ (ਸੁਰੱਖਿਆ ਰਿਵਿਊ, ਲੀਗਲ, ਪ੍ਰੋਕਯੂਰਮੈਂਟ)। ਜੇ ਤੁਸੀਂ ਸਾਈਨਰ ਨੂੰ ਨਹੀਂ ਜਾਣਦੇ, ਡੀਲ ਨੂੰ ਅਰੰਭਿਕ ਮੰਨੋ।
ਇੱਕ ਮੂੱਲ-ਫਿੱਟ ਸਿਗਨਲ ਜ਼ਰੂਰ ਰੱਖੋ, ਭਾਵੇਂ ਅੰਦਾਜ਼ਾ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ। ਰੇਂਜਾਂ ("<$5k", "$5-25k", "$25k+") ਠੀਕ ਹਨ, ਜਾਂ Likely / Unclear / Unlikely ਜਿਵੇਂ ਸਧਾਰਨ ਸਿਗਨਲ। ਮਕਸਦ ਉਹ ਡੀਲਾਂ ਅੱਗੇ ਨਾ ਵਧਾਉਣਾ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਤੁਹਾਡੇ ਲਈ ਬਜਟ ਹੀ ਨਹੀਂ।
ਆਖ਼ਰਕਾਰ, ਲਾਲ ਝੰਡਾ ਫੀਲਡ ਇੱਕ ਲਾਈਨ ਤੱਕ ਰੱਖੋ। ਜੇ ਇਹ ਇੱਕ ਪੈਰਾਗ੍ਰਾਫ ਬਣ ਜਾਏ, ਤਾਂ ਉਹ ਨੋਟਾਂ ਵਿੱਚ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅਕਸਰ ਵਰਤਣ ਯੋਗ ਇੱਕ ਸੰਕੁਚਿਤ ਸੈੱਟ:
ਉਦਾਹਰਣ: "Renewal ਤੋਂ ਪਹਿਲਾਂ CRM ਸਫਾਈ ਚਾਹੀਦੀ, ਸਾਈਨਰ VP Sales, ਸੁਰੱਖਿਆ ਰਿਵਿਊ ਲਾਜ਼ਮੀ, ਬਜਟ ਸੰਭਵ $10-20k, ਮੁਕਾਬਲਾ: ਕੁਝ ਵੀ ਨਾ ਕਰਨਾ, ਲਾਲ ਝੰਡਾ: ਚੈਂਪੀਅਨ ਪ੍ਰੋਜੈਕਟ ਦਾ ਮਾਲਕ ਨਹੀਂ।" ਇਹ ਇਕ ਰਿਕਾਰਡ ਤੁਹਾਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ دھੋਖਾ ਦੇਣਾ ਮੁਸ਼ਕਿਲ ਕਰ ਦੇਵੇਗਾ।
ਪਾਈਪਲਾਈਨ ਉਸ ਵੇਲੇ ਹੀ ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਇੱਛਾ-ਸੂਚੀ ਬਣ ਜਾਂਦਾ ਹੈ। ਠੀਕ ਕਰਨ ਲਈ ਜ਼ਰੂਰਤ ਹੋਰ ਫੀਲਡ ਨਹੀਂ, ਬਲਕਿ ਕੁਝ ਐਕਟਿਵਿਟੀ ਸਿਗਨਲ ਹਨ ਜੋ ਹਰ ਡੀਲ ਨੂੰ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ: ਅਗਲਾ ਕੀ ਹੈ?
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਸਕੀਮਾ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਪਰਤ ਜੋੜੋ, ਤਾਂ ਇਹ ਐਕਟਿਵਿਟੀ ਫੀਲਡਜ਼ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਇੱਕ ਵਿਅਵਹਾਰਕ ਨਿਯਮ: ਜੇ ਕਿਸੇ ਡੀਲ ਕੋਲ ਨੇਕਸਟ-ਸਟੈਪ ਜਾਂ ਡਿਊ-ਡੇਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹ ਅਸਲੀ ਡੀਲ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਪਾਰਕ ਕਰੋ ਜਾਂ ਬੰਦ ਕਰ ਦਿਓ। ਇਹ ਕਿਸੇ ਵੀ ਸਕੋਰਿੰਗ ਮਾਡਲ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਫੋਰਕਾਸਟ ਸਹੀ ਕਰਦਾ ਹੈ।
"Reason lost" ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਅਸਲੀਵੀਂ ਵਰਤੋ: price, no budget, no decision, chose competitor, timing, not a fit.
ਇਹ ਕਿਸ ਤਰ੍ਹਾਂ ਲੱਗਦਾ ਹੈ: ਤੁਹਾਡੇ ਕੋਲ ਮੰਗਲਵਾਰ ਨੂੰ ops ਲੀਡ ਨਾਲ ਇੱਕ ਡੈਮੋ ਹੈ। ਕਾਲ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਤੁਸੀਂ last activity date = ਮੰਗਲਵਾਰ, last touch channel = meeting, next step = "2 case studies ਭੇਜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੌਣ ਸਾਈਨ ਕਰੇਗਾ", next step due date = ਵੀਰਵਾਰ। ਜੇ ਵੀਰਵਾਰ ਨੂੰ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਆਉਂਦਾ, ਡੀਲ ਬਿਨਾਂ ਕਿਸੇ ਵਕਾਲਤ ਦੇ ਲਾਲ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕੋਈ ਨਿਰਕਸ਼ਣ ਨਹੀਂ ਹੁੰਦਾ ਕਿ "ਪਾਈਪਲਾਈਨ ਅੱਗੇ ਵਧਿਆ"।
ਇੱਕ ਚੰਗਾ ਸਟੇਜ ਮਾਡਲ ਇੱਕ ਕੰਮ ਕਰਦਾ ਹੈ: ਇਹ ਹਰ ਡੀਲ ਦੀ ਸਥਿਤੀ ਬੇਨਕਾਬ ਕਰਦਾ ਹੈ, ਬਿਨਾਂ ਤੁਸੀਂ ਦਹਾਕੇ-ਦਹਾਕੇ ਛੋਟੇ ਕਦਮਾਂ ਦੀ ਦੇਖਭਾਲ ਕਰਨ ਦੇ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਕਹਿ ਸਕਦੇ ਕਿ ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ ਹੋਣ 'ਤੇ ਕਿਸ ਗੱਲ ਦਾ ਸੱਚ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਸਟੇਜ ਇੱਕ ਅਹਿਸਾਸ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇਹ ਛੇ-ਸਟੇਜ ਸੈਟਅਪ ਬਹੁਤ B2B ਸਥਾਪਕਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ:
New: ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਨਾਮ ਅਤੇ ਸੰਪਰਕ ਕਰਨ ਦਾ ਕਾਰਨ ਹੈ। ਪਹਿਲਾ ਸੰਪਰਕ ਕੀਤਾ ਗਿਆ ਜਾਂ ਸਕੈਸ਼ੂਲ ਕੀਤਾ ਗਿਆ ਹੈ।
Qualified: ਮੂਲ ਫਿੱਟ ਪੁਸ਼ਟੀ ਹੋ ਚੁਕੀ ਹੈ। ਸਮੱਸਿਆ ਅਸਲੀ ਹੈ, ਗਾਹਕ ਤੁਹਾਡੇ ICP ਨਾਲ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਖਰੀਦ ਦਾ ਰਾਸਤਾ ਵਾਜਬ ਹੈ।
Discovery done: ਤੁਸੀਂ ਇੱਕ ਅਸਲ ਗੱਲਬਾਤ ਕੀਤੀ; ਤੁਸੀਂ use case, success criteria ਅਤੇ ਸ਼ਰੀਕ ਪਹਚਾਨ ਲੈ ਲਈ ਹੈ।
Proposal sent: ਕੀਮਤ ਅਤੇ ਦਾਇਰਾ ਗਾਹਕ ਦੇ ਹੱਥਾਂ ਵਿੱਚ ਹੈ। ਇੱਕ ਅਗਲਾ ਕਦਮ ਬੁੱਕ ਕੀਤਾ ਗਿਆ ਜਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਮੰਗਿਆ ਗਿਆ ਹੈ।
Negotiation/Legal: ਪ੍ਰੋਕਯੂਰਮੈਂਟ, ਸੁਰੱਖਿਆ, ਬਜਟ ਦੀ ਮਨਜ਼ੂਰੀ ਜਾਂ ਠੇਕੇ ਦੇ ਸੰਸ਼ੋਧਨ ਚੱਲ ਰਹੇ ਹਨ।
Closed won / Closed lost: ਨਤੀਜਾ ਮਾਰਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕਾਰਨ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਫਰਕ ਇਹ ਹੈ: ਇੱਕ ਡੀਲ ਤਦ ਹੀ ਅੱਗੇ ਵਧੇ ਜਦੋਂ ਅਸਲ ਦੁਨੀਆਂ ਵਿੱਚ ਕੁਝ ਹੋਇਆ ਹੋਵੇ (ਮੀਟਿੰਗ ਪੂਰੀ, ਪ੍ਰਸਤਾਵ ਭੇਜਿਆ ਗਿਆ, ਲੀگل ਸ਼ੁਰੂ ਹੋਇਆ)। ਜੇ ਕੁਝ ਨਹੀਂ ਹੋਇਆ, ਸਟੇਜ ਜਿਆਦਾ ਨਹੀਂ ਬਦਲਦਾ।
ਕੇਵਲ ਸਟੇਜ ਨਾਂ ਲਿੱਖਣਾ ਕਾਫ਼ੀ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ "Qualified" ਜਾਂ "Negotiation" ਲਿਖੋ ਗੇ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਐਸੀਆਂ ਡੀਲਾਂ ਵੇਖੋਗੇ ਜੋ ਓਥੇ ਬੈਠੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਇਹ ਨਹੀਂ ਸਮਝਦਾ ਕਿ "ਮੁਕੰਮਲ" ਕੀ ਹੈ।
ਸਟੇਜ ਰੂਲ ਸਧਾਰਨ true/false ਚੈਕ ਵਾਂਗ ਲਿਖੋ। ਜਦੋਂ ਹਰ ਡੀਲ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਤੱਥ ਹੋਣਗੇ, ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ ਭਰੋਸੇਯੋਗ ਰਹੇਗੀ।
ਐਂਟਰੀ ਮਿਆਰ ਦੱਸਦਾ ਹੈ ਕਿ ਸਟੀਜ ਵਿੱਚ ਪ੍ਰਵੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਐਕਜ਼ਿਟ ਮਿਆਰ ਦੱਸਦਾ ਹੈ ਕਿ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਬਦਲਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਦੋਹਾਂ ਨੂੰ ਛੋਟੇ ਅਤੇ ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ ਰੱਖੋ।
ਉਦਾਹਰਣ:
ਜੇ ਤੁਸੀਂ "ਚੰਗਾ", "ਮਜ਼ਬੂਤ" ਜਾਂ "ਦਿਲਚਸਪ" ਵਰਗੇ ਸ਼ਬਦਾਂ ਤੋਂ ਬਿਨਾਂ ਮਿਆਰ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਸਟੇਜ ਬਹੁਤ ਧੁੰਦਲੀ ਹੈ।
ਹਰ ਸਟੇਜ ਲਈ ਇੱਕ ਅਧਿਕਤਮ ਉਮਰ ਨਿਰਧਾਰਤ ਕਰੋ ਜਿਵੇਂ ਕਿ ਇਕ ਅੱਗਾਹੀ ਨਿਸ਼ਾਨ, ਸਜ਼ਾ ਲਈ ਨਹੀਂ। ਉਦਾਹਰਣ: Discovery ਮੈਕਸ 14 ਦਿਨ, Proposal ਮੈਕਸ 21 ਦਿਨ। ਜਦੋਂ ਕੋਈ ਡੀਲ ਹੱਦ ਪਾਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਰੀਸੈੱਟ ਚਲਾਓ: ਅਗਲਾ ਕਦਮ ਬੁੱਕ ਕਰੋ, ਪਿੱਛੇ ਲਿਜਾਓ, ਜਾਂ ਬੰਦ ਕਰੋ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਡੀਲ ਮਿਆਰ ਪੂਰਾ ਨਾ ਹੋਣ 'ਤੇ ਮੂਲ ਕਾਰਵਾਈ ਕੀ ਹੋਵੇਗੀ:
ਇਹ "ਜ਼ੋੰਬੀ ਡੀਲਾਂ" ਨੂੰ ਤੁਹਾਡੇ ਫੋਰਕਾਸਟ ਨੂੰ ਫਸਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਤੁਸੀਂ ਕੁਝ ਘੰਟਿਆਂ ਵਿੱਚ sales pipeline ਸਕੀਮਾ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇੱਕ ਛੋਟੇ ਉਤਪਾਦ ਵਾਂਗ ਜੋTreat ਕਰੋ: ਪਹਿਲਾਂ ਨਿਯਮ, ਫਿਰ ਕੇਵਲ ਉਹ ਜੋ ਨਿਯਮਾਂ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ।
ਖਾਲੀ ਪੰਨੇ 'ਤੇ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਸੇ ਟੂਲ ਦੇ ਅੰਦਰ ਨਹੀਂ। ਆਪਣੇ ਸਟੇਜ ਅਤੇ ਐਂਟਰੀ/ਐਕਜ਼ਿਟ ਮਿਆਰ ਸਿੱਧੀ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਟੇਜ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਇਹ ਦੋ ਸਟੇਜ ਹਨ (ਜਾਂ ਕੋਈ ਸਟੇਜ ਹੀ ਨਹੀਂ)।
ਇਕ ਸਧਾਰਨ ਬਿਲਡ ਫਲੋ:
ਸੈਟਅਪ ਦੌਰਾਨ ਇੱਕ ਹਕੀਕਤੀ ਟੈਸਟ ਕਰੋ: ਇੱਕ ਐਕਟਿਵ ਡੀਲ ਲਵੋ ਅਤੇ ਇਸਨੂੰ ਸਟੇਜ ਤੋਂ ਸਟੇਜ ਭਰਤੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਗੈਸ ਕਰਦੇ ਰਹਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਮਿਆਰ ਬਹੁਤ ਧੁੰਦਲੇ ਹਨ।
ਇੱਕ ਨਿਯਮ ਜਲਦੀ ਲਾਗੂ ਕਰੋ: ਜੇ next activity date ਖਾਲੀ ਹੈ, ਡੀਲ active ਸਟੇਜ ਵਿੱਚ ਨਹੀਂ ਰਹਿ ਸਕਦੀ।
ਜ਼ਿਆਦਾਤਰ CRM ਬਲੋਟ ਚੰਗੀ ਨੀਅਤ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਹੋਰ ਸਹੀ ਚਾਹੁੰਦੇ ਹੋ, ਇਸ ਲਈ ਹੋਰ ਫੀਲਡ, ਹੋਰ ਸਟੇਜ, ਅਤੇ ਵਧੇਰੇ ਨੋਟਾਂ ਜੋੜ ਦਿੰਦੇ ਹੋ। ਨਤੀਜਾ ਉਲਟ ਹੁੰਦਾ ਹੈ। ਲੋਕ ਅਪਡੇਟ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ ਇੱਕ ਠਿਕਾਣਾ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਡੀਲ ਪੁਰਾਣੇ ਹੋਣ ਆਉਂਦੀਆਂ ਹਨ।
ਜੇ ਦੋ ਸਟੇਜ ਇੱਕੋ ਜਿਹੇ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਉਹ ਇੱਕੋ ਹੀ ਢੰਗ ਨਾਲ ਵਰਤੇ ਜਾਣਗੇ। “Discovery”, “Deep discovery”, ਅਤੇ “Discovery follow-up” ਅਕਸਰ ਸਿਰਫ਼ "ਸਾਨੂੰ ਗੱਲ ਕੀਤੀ" ਦਾ ਹੀ ਅਰਥ ਰੱਖਦੇ ਹਨ, ਬਿਨਾਂ ਸਾਫ਼ ਅਗਲੇ ਘੱਟੋ-ਘੱਟ ਕਾਰਵਾਈ ਦੇ। ਸਟੇਜਾਂ ਨੂੰ ਸਿਰਫ਼ ਤਦ ਬਦਲੋ ਜਦੋਂ ਕੁਝ ਅਸਲ ਬਦਲੇ।
ਤੁਰੰਤ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਟੇਜ ਵਿੱਚ ਪ੍ਰਵੇਸ਼ ਕਰਨ ਲਈ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਉਹ ਸੰਭਵ ਹੈ ਕਿ ਅਤਿਰਿਕਤ ਹੈ।
ਕਲੋਜ਼ ਤਾਰੀਖ ਸਿਰਫ਼ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਇਹ ਕਿਸੇ ਕਾਰਨ ਨਾਲ ਜੁੜੀ ਹੋਵੇ। ਇਸਨੂੰ ਅਗਲੇ ਨਿਰਣਯ ਬਿੰਦੂ ਤਾਰੀਖ ਵਜੋਂ ਸੰਭਾਲੋ (ਬਜਟ ਮਨਜ਼ੂਰੀ, ਪ੍ਰੋਕਯੂਰਮੈਂਟ ਮੀਟਿੰਗ, ਸਾਈਨਿੰਗ ਡੇਡਲਾਈਨ), ਅਤੇ ਜਦੋਂ ਉਹ ਘਟਨਾ ਹਿਲਦੀ ਹੈ ਤਾਂ ਇਸਨੂੰ ਅਪਡੇਟ ਕਰੋ।
ਲੰਬੀਆਂ ਨੋਟਾਂ ਉਹ ਇੱਕ ਚੀਜ਼ ਛੁਪਾ ਲੈਂਦੀ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ: ਆਖ਼ਰੀ ਵਿੱਚ ਕੀ ਹੋਇਆ ਅਤੇ ਅਗਲਾ ਕੀ ਹੈ। ਨੋਟਾਂ ਛੋਟੀਆਂ ਰੱਖੋ, ਅਤੇ ਸਰਗਰਮੀ ਨੂੰ last activity date ਅਤੇ next step (ਇੱਕ ਮਾਲਿਕ ਅਤੇ ਇੱਕ ਡਿਊ ਡੇਟ ਦੇ ਨਾਲ) ਨਾਲ ਟ੍ਰੈਕ ਕਰੋ।
ਪਰਿਭਾਸ਼ਾ ਬਿਨਾਂ, "qualified" ਦਾ ਮਤਲਬ ਬਣ ਜਾਂਦਾ ਹੈ "ਉਹ ਨੇ ਵਧੀਆ ਲੱਗਿਆ"। 3-4 ਚੈੱਕ ਪੱਕੇ ਕਰੋ (ਸਮੱਸਿਆ, ਖਰੀਦਦਾਰ, ਟਾਈਮਲਾਈਨ, ਅਤੇ ਕੁਝ ਬਜਟ)। ਜੇ ਇੱਕ ਵੀ ਗੁੰਢੀ ਚੀਜ਼ ਗਾਇਬ ਹੈ, ਤਾਂ ਇਹ qualified ਨਹੀਂ ਹੈ।
ਜੋ ਪਾਈਪਲਾਈਨ ਸਿਰਫ਼ ਵਧਦੇ ਰਹਿੰਦੇ ਹਨ ਉਹ ਪਾਈਪਲਾਈਨ ਬਣਨਾ ਛੱਡ ਕਰ ਕਬਰਸਤਾਨ ਬਣ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਡੀਲ ਗੈਰ-ਸਰਗਰਮ ਹੋ ਜਾਂਦੀ ਜਾਂ ਫਿੱਟ ਗਲਤ ਹੋਵੇ, ਤੁਰੰਤ close lost ਕਰੋ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਨ ਕੈਪਚਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਿੱਖ ਸਕੋ।
ਹਰੇਕ ਹਫ਼ਤੇ ਇੱਕ ਸਮਾਂ ਚੁਣੋ (30 ਮਿੰਟ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ) ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਭਵਿੱਖ ਦੇ ਖੁਦ ਨਾਲ ਮਿਲਣ ਵਾਲੀ ਮੀਟਿੰਗ ਸਮਝੋ। ਪਾਈਪਲਾਈਨ ਸਫਾਈ ਫੀਲਡ ਜੋੜਨ ਤੋਂ ਵੱਧ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਹਰ ਡੀਲ ਅਜੇ ਵੀ ਅਸਲੀ ਰਸਤੇ 'ਤੇ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਸਮੀਖਿਆ ਪ੍ਰਵਾਹ:
ਠੋਸ ਉਦਾਹਰਣ: ਜੇ ਇੱਕ ਡੀਲ "Proposal sent" ਹੈ ਪਰ ਇਸਦੀ ਕੋਈ ਸਮੀਖਿਆ ਮੀਟਿੰਗ ਬੁੱਕ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ proposal-ਸਟੇਜ ਡੀਲ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਪਿੱਛੇ ਲਿਜਾਓ, ਅਗਲਾ ਕਦਮ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਗਾਹਕ ਦੁਬਾਰਾ ਰੁਚਸਪਰ ਹੋਣ ਤੱਕ ਇਸਨੂੰ ਗਿਣਤੀ ਵਿੱਚ ਨਾ ਗਿਣੋ।
ਤੁਸੀਂ ਇੱਕ B2B ਐਨਾਲਿਟਿਕਸ ਟੂਲ ਵੇਚਦੇ ਹੋ ਇੱਕ 50-ਅਦਦ ਦੀ e-commerce ਕੰਪਨੀ ਨੂੰ। ਪਹਿਲੀ ਕਾਲ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਇੱਕ ਡੀਲ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਭਰਦੇ ਹੋ ਜੋ ਤੂੰ ਅੱਗਲੇ ਹਫਤੇ ਲਈ ਵਰਤੇਂਗੇ। ਇੱਕ ਸਰਲ ਸਕੀਮਾ ਇੱਥੇ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ paperwork ਨਹੀਂ, ਸਪਸ਼ਟਤਾ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ।
ਕਾਲ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਰਿਕਾਰਡ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:
ਡੀਲ Discovery ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਤਦ ਹੀ ਅੱਗੇ ਵਧਾਉਂਦੇ ਹੋ ਜਦੋਂ ਕੈਲੰਡਰ ਇਨਵਾਇਟ ਮਨਜ਼ੂਰ ਹੋ ਜਾਂਦਾ (ਜਦੋਂ ਕਿਸੇ ਨੇ "ਤਿਆਰ ਹਾਂ" ਨਹੀ ਕਿਹਾ)। ਡੈਮੋ ਤੋਂ ਬਾਅਦ, ਮੂਲ ਚਿੰਨ੍ਹ ਇਸ ਗੱਲ ਦਾ ਹੁੰਦਾ ਹੈ ਕਿ ਗਾਹਕ ਨੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਤਕਨੀਕੀ ਜਾਂ ਲੋੜੀਦਾ ਪੁੱਛਿਆ (ਉਦਾਹਰਣ: "ਕੀ ਤੁਸੀਂ Shopify ਅਤੇ ਸਾਡੇ ਵేర్-ਹਾਊਸ ਡੇਟਾ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹੋ?") ਅਤੇ ਫਿਰ ਇਕ ਤਕਨੀਕੀ ਜਾਂਚ ਤੈਅ ਕੀਤੀ ਗਈ।
ਹੁਣ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ: CFO ਕਿਸਮਤ ਦੀ ਕੀਮਤ ਦੇ ਬਾਅਦ ਸੁੰਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡਾ ਲਾਗ ਦਿਖਾਉਂਦਾ ਹੈ ਦੋ ਫਾਲੋਅਪ, ਕੋਈ ਜਵਾਬ ਨਹੀਂ, ਅਤੇ ਨੇਕਸਟ-ਸਟੈਪ ਦੀ ਤਾਰੀਖ ਲੰਘ ਜਾਂਦੀ ਹੈ। ਨਿਯਮ ਸਧਾਰਨ ਹੈ: ਜੇ ਕੋਈ ਸਹਿਮਤ ਆਗਲਾ ਕਦਮ ਨਹੀਂ ਹੈ, ਡੀਲ Proposal ਵਿਚ ਨਹੀਂ ਰਹਿ ਸਕਦੀ।
ਤਦ ਤੁਸੀਂ ਇਮਾਨਦਾਰ ਚੋਣ ਕਰੋ: ਜਾਂ ਤਾ evaluation ਵੱਲ ਪਿੱਛੇ ਜਾ (ਜੇ ਤੁਹਾਨੂੰ ਨਵੇਂ sponsor ਜਾਂ ਗੁੰਝਲਦਾਰ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੈ) ਜਾਂ close lost (ਜੇ ਫੈਸਲਾ ਕਰਨ ਵਾਲਾ ਨਿਰਧਾਰਿਤ ਤਾਰੀਖ ਤੱਕ ਸ਼ਾਮਿਲ ਨਹੀਂ ਹੋਵੇ)। ਇਸ ਉਦਾਹਰਣ ਵਿਚ, ਤੁਸੀਂ ਪਿੱਛੇ ਕਰੋ, stakeholder ਨੋਟ ਅਪਡੇਟ ਕਰੋ (Ops ਨੇ finance manager ਨੂੰ ਖਿੱਚਿਆ), ਨਵਾਂ next step date ਸੈਟ ਕਰੋ, ਅਤੇ CFO ਇੱਕ ਫੈਸਲਾ ਮੀਟਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੱਕ Proposal 'ਤੇ ਵਾਪਸ ਨਾ ਲਿਆਂਦੇ।
ਇੱਕ sales pipeline ਸਕੀਮਾ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰੋ। ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਥੇ ਪਹੁੰਚਣ ਦਾ ਇਹ ਹੈ ਕਿ ਘੱਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ 30 ਦਿਨ ਇਸਦੇ ਨਾਲ ਜੀਓ। ਇਸ ਨਾਲ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਵਰਤਦੇ ਹੋ, ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਪਹਿਲੇ ਮਹੀਨੇ ਲਈ ਕੜਾਈ ਨਾਲ ਰਹੋ: ਜੇ ਇੱਕ ਫੀਲਡ ਕਿਸੇ ਫੈਸਲੇ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ, ਓਹਨੂੰ ਹਟਾ ਦਿਓ। ਜੇ ਕੋਈ ਫੈਸਲਾ ਮੁੜ-ਮੁੜ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ pipeline ਤੋਂ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਓਸ ਖ਼ਾਸ ਗੈਪ ਲਈ ਬਿਲਕੁਲ ਇੱਕ ਫੀਲਡ ਜੋੜੋ।
ਕਿਸੇ ਨਵੇਂ ਫੀਲਡ ਨੂੰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ: "ਜੇ ਇਹ ਖਾਲੀ ਹੋਵੇ, ਤਾਂ ਅਸੀਂ ਫੈਸਲਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ___।"
ਜੇ ਤੁਸੀਂ ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ, ਕਸਟਮ CRM ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਬਜਾਏgeneric ਇੱਕ ਨੂੰ ਜਬਰਦਸਤੀ ਫੋਰਸ ਕਰਨ ਦੇ, ਤਾਂ Koder.ai (koder.ai) ਵਰਗੇ ਟੂਲ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਸਟੇਜ, ਲਾਜ਼ਮੀ ਫੀਲਡ ਅਤੇ ਵੇਰੀਫਿਕੇਸ਼ਨ ਨਿਯਮ ਲਿਖ ਚੁੱਕੋ। ਸਕੀਮਾ ਸਾਫ਼ ਹੋਣ 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਐਪ ਬਣਾਉਣਾ ਅਤੇ ਇਸ 'ਤੇ ਤਬਦੀਲੀ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਪਾਈਪਲਾਈਨ "ਝੂਠ" ਦੱਸਦਾ ਹੈ ਜਦੋਂ ਉਹ ਅਸਲ ਖਰੀਦਦਾਰ ਦੀ ਕਾਰਵਾਈ ਨਾਲ ਪਿੱਛੇ ਨਹੀਂ ਹੁੰਦਾ ਪਰ ਫਰੰਤ ਪ੍ਰਗਟੀ ਦਿੰਦਾ ਹੈ। ਆਮ ਕਾਰਨ ਹਨ: ਨੇਕਸਟ-ਸਟੈਪ ਨਾ ਹੋਣਾ, ਅਖੀਰਲੀ ਸਰਗਰਮਤਾ ਦੀ تاريخ ਸਟੇਲ ਹੋ ਜਾਣੀ, ਅਤੇ ਕਲੋਜ਼ ਤਾਰੀਖਾਂ ਨੂੰ ਖਰੀਦਦਾਰ-ਪੱਕੀ ਟਾਈਮਲਾਈਨ ਦੇ ਬਗੈਰ ਅੱਗੇ ਧੱਕ ਦਿੱਤਾ ਜਾਣਾ।
ਹਰ ਖੁਲੇ ਡੀਲ ਲਈ ਤਿੰਨ ਫੀਲਡ ਲਾਜ਼ਮੀ ਕਰੋ: ਇੱਕ ਨਿਖਰਿਆ ਹੋਇਆ ਅਗਲਾ ਕਦਮ, ਉਸ ਐਕਸ਼ਨ ਲਈ ਇੱਕ ਡਿਊ-ਡੇਟ, ਅਤੇ ਇੱਕ ਕਲੋਜ਼ ਤਾਰੀਖ ਜੋ ਕਿਸੇ ਅਸਲ ਖਰੀਦਦਾਰ ਇਵੈਂਟ (ਮੀਟਿੰਗ, ਰਿਵਿਊ, ਸਾਇਨਿੰਗ) ਨਾਲ ਜੁੜੀ ਹੋਵੇ। ਜੇ ਇਹਨਾਂ ਵਿਚੋਂ ਕੋਈ ਵੀ ਖਾਲੀ ਹੈ, ਡੀਲ ਨੂੰ ਗੈਰ-ਸਰਗਰਮ ਮੰਨੋ।
ਮੂਲ ਨਿਯਮ ਇਹ ਹੈ: "ਇੱਕ ਡੀਲ = ਇੱਕ ਖਰੀਦ ਫੈਸਲਾ।" ਜੇ ਇੱਕੋ ਕੰਪਨੀ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ, ਉਤਪਾਦਾਂ ਜਾਂ ਬਜਟਾਂ ਰਾਹੀਂ ਦੁਬਾਰਾ ਖਰੀਦ ਸਕਦੀ ਹੈ, ਤਾਂ ਵੱਖ-ਵੱਖ ਡੀਲ ਬਣਾਓ ਤਾਂ ਜੋ ਇੱਕੋ ਰਿਕਾਰਡ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਟਾਈਮਲਾਈਨਾਂ ਅਤੇ ਸਟੇਕਹੋਲਡਰ ਗੁੰਥੇ ਨਾ ਹੋਣ।
ਸਟਾਰਟ ਕਰਨ ਲਈ ਇੱਕ ਅਚਛਾ ਡੇਟਾ ਸੈੱਟ: ਡੀਲ ਨਾਂ ਦਾ ਸਾਰਣੀ ਫਾਰਮੈਟ (ਦੂਜਿਆਂ ਨਾਲ ਡੁਪਲਿਕੇਟ ਤੋਂ ਬਚਾਉਂਦਾ), ਕੰਪਨੀ, ਪ੍ਰਾਈਮਰੀ ਸੰਪਰਕ, ਡੀਲ ਮਾਲਿਕ, ਉਮੀਦਤ ਮੁੱਲ, ਨਿਸ਼ਾਨਾ ਕਲੋਜ਼ ਤਾਰੀਖ ਅਤੇ ਇੱਕ ਸਾਫ਼ ਸੋਰਸ। ਫਿਰ ਜ਼ਰੂਰਤ ਮੁਤਾਬਕ ਕੁਝ ਯੋਗਤਾ (use case, decision process, pricing fit) ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਡੀਲ ਬੰਦ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ-ਸਟੇਂਟ use case ਅਤੇ success criteria ਇਹ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਨਤੀਜੇ ਨੂੰ ਸਮਝਦੇ ਹੋ, ਸਿਰਫ਼ ਖਰੀਦਦਾਰ ਦੀ ਦਿਲਚਸਪੀ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਨਤੀਜੇ ਨੂੰ ਸਾਫ਼ ਇਕ-ਵਾਕ੍ਯ ਵਿੱਚ ਵਖਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਡੀਲ ਅਕਸਰ ਹਨੇਰੀ ਰਹਿੰਦੀ ਹੈ।
ਨਿਰਣਯ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਛੋਟੀ ਕਹਾਣੀ ਵਾਂਗ ਲਿਖੋ: ਕੌਣ ਸਾਈਨ ਕਰਦਾ ਹੈ, ਕੌਣ ਰੁਕਾਵਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਕਦਮ ਲੋੜੀਂਦੇ ਹਨ (ਸੁਰੱਖਿਆ, ਲੀਗਲ, ਪ੍ਰੋਕਯੂਰਮੈਂਟ)। ਜੇ ਸਾਈਨ ਕਰਨ ਵਾਲਾ ਅਜੇ ਪਤਾ ਨਹੀਂ ਤਾਂ ਡੀਲ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਸਟੇਜ 'ਚ ਰੱਖੋ ਅਤੇ ਆਪਣਾ ਅਗਲਾ ਕਦਮ ਉਸ ਬੰਦੇ/ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਲੱਭਣਾ ਬਣाओ।
ਬਜਟ ਟ੍ਰੈੱਕ ਕਰਨ ਦਾ ਸਰਲ ਤਰੀਕਾ: ਇੱਕ ਅੰਦਾਜ਼ੀ ਰੇਂਜ ਜਾਂ Likely/Unclear/Unlikely। ਮਕਸਦ ਪਰਫੈਕਟ ਪਰਾਈਸਿੰਗ ਨਹੀਂ, ਬਲਕਿ ਉਹ ਡੀਲ ਅੱਗੇ ਨਾ ਵਧਾਈਏ ਜੋ ਤੁਹਾਡੀ ਕੀਮਤ ਉਪਰ ਬੈਠਦੀ ਹੀ ਨਹੀਂ।
ਹਫਤੇ-ਦਰ-ਹਫਤੇ ਮਹੱਤਵਪੂਰਨ ਫੀਲਡ: last activity date, next step, next step due date, ਅਤੇ ਜਦੋਂ ਡੀਲ ਖਤਮ ਹੋਵੇ ਤਾਂ short close reason। ਨੋਟਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਸਰਗਰਮੀ ਫੀਲਡ ਡੀਲਾਂ ਨੂੰ ਡ੍ਰਿਫਟ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
ਸਟੇਜਾਂ ਨੂੰ ਸਿਰਫ਼ ਤਦ ਹੀ ਅੱਗੇ ਵਧਾਓ ਜਦੋਂ ਕੁਝ ਅਸਲ ਹੋਇਆ ਹੋਵੇ — ਜਿਵੇਂ discovery call ਪੂਰਾ ਹੋਣਾ, ਪ੍ਰਸਤਾਵ ਭੇਜੇ ਜਾਣਾ, ਜਾਂ ਲੀਗਲ ਪੇਸ਼ ਕੀਤਾ ਜਾਣਾ। ਜੇ ਸਟੇਜ ਸਿਰਫ਼ "ਚੰਗਾ ਲੱਗਣ" ਕਾਰਨ ਬਦਲ ਸਕਦੀ ਹੈ, ਤਾਂ ਉਸਦੀ ਪਰਿਭਾਸ਼ਾ ਬਹੁਤ ਧੁੰਦਲੀ ਹੈ।
ਹਰ ਸਟੇਜ ਲਈ ਇੱਕ ਅਧਿਕਤਮ ਦਿਨਾਂ ਦੀ ਹੱਦ ਰੱਖੋ। ਜਦੋਂ ਕੋਈ ਡੀਲ ਉਸ ਹੱਦ ਨੂੰ ਪਾਰ ਕਰੇ, ਤਾਂ ਰੀਸੈੱਟ ਦਾ ਨਿਯਮ ਚੱਲੋ: ਅਗਲਾ ਨਿਯਤ ਕਦਮ ਬੁੱਕ ਕਰੋ, ਡੀਲ ਨੂੰ ਪਿੱਛੇ ਲਿਜਾਓ, ਜਾਂ ਇੱਕ ਸਾਫ਼ ਫਾਲੋਅਪ ਨਿਯਮ ਤੋਂ ਬਾਅਦ close lost ਕਰੋ। ਇਹ 'ਜ਼ੋੰਬੀ ਡੀਲ' ਨੂੰ ਤੁਹਾਡੇ ਫੋਰਕਾਸਟ ਨੂੰ ਫਸਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।