AI-ਨਿਰਮਿਤ SaaS ਦੇ ਪਹਿਲੇ 30 ਦਿਨ: ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰੋ

ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਝੰਝਟ ਕਿਉਂ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ

ਲਾਂਚ ਦੇ ਪਹਿਲੇ 30 ਦਿਨ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਂਤ ਨਹੀਂ ਲੱਗਦੇ। ਤੁਸੀਂ ਸਾਫ਼ ਸੰਕੇਤ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਪਰ ਅਰੰਭਕ ਯੂਜ਼ਰ ਇਕੱਠੇ ਸਵਾਲ, ਬੱਗ, ਫੀਚਰ ਦੀਆਂ ਮੰਗਾਂ ਅਤੇ ਕੀਮਤ ਦੇ ਸਵਾਲ ਲਿਆ ਕੇ ਆਉਂਦੇ ਹਨ। ਸਾਰਾ ਕੁਝ ਇੱਕੋ ਜਿਹਾ ਮਹੱਤਵਪੂਰਨ ਲੱਗ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਨਹੀਂ ਹੁੰਦਾ।

ਇਸ ਸ਼ੋਰ ਦਾ ਹਿੱਸਾ ਯੂਜ਼ਰਾਂ ਵਿਚੋਂ ਆਉਂਦਾ ਹੈ।ਅਰੰਭਕ ਗ੍ਰਹਿਣਕਾਰ ਵੱਖ-ਵੱਖ ਚਾਹੁੰਦੇ ਹਨ। ਇੱਕ ਨੁਕਤਾ ਤੇਜ਼ੀ ਚਾਹੁੰਦਾ ਹੈ, ਦੂਜਾ ਪਾਲਿਸ਼, ਤੇ ਕੋਈ ਹੋਰ ਉਹ ਫੀਚਰ ਜੋ ਤੁਸੀਂ ਸੋਚਿਆ ਹੀ ਨਹੀਂ ਸੀ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਲਾਂਚ ਕੀਤਾ—ਖਾਸ ਕਰਕੇ ਕਿਸੇ AI ਟੂਲ ਜਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ—ਉਹ ਤੇਜ਼ੀ ਇੱਕ ਫਾਇਦਾ ਹੈ। ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਲੋਕ ਤੁਰੰਤ ਹੱਦਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲੱਗਦੇ ਹਨ।

ਛੋਟੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਵੱਡੀਆਂ ਲਗਦੀਆਂ ਹਨ। ਲੌਗਇਨ ਦਿੱਕਤ, ਟੁੱਟਿਆ ਬਟਨ, ਜਾਂ ਗੁੰਝਲਦਾਰ ਸੈਟਅਪ ਕਦਮ ਇੱਕ ਗੁੰਟੇ ਫੀਚਰ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਕਰ ਸਕਦੇ ਹਨ। ਨਵੇਂ ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਇਹ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਕਿ ਉਹ ਤੁਹਾਡੇ ਉਤਪਾਦ 'ਤੇ ਭਰੋਸਾ ਕਰਨਗੇ ਜਾਂ ਨਹੀਂ। ਜੇ ਕੋਈ ਮੂਲ ਚੀਜ਼ fail ਹੋ ਜਾਂਦੀ ਹੈ, ਉਹ ਸੋਚਦੇ ਨਹੀਂ, "ਇਹ ਇਕ ਛੋਟਾ ਬੱਗ ਹੈ।" ਉਹ ਸੋਚਦੇ ਹਨ, "ਸ਼ਾਇਦ ਇਹ ਟੂਲ ਤਿਆਰ ਨਹੀਂ ਹੈ।"

ਇਸੇ ਲਈ ਇਹ ਪੜਾਅ ਗੜਬੜਾਵਾਂ ਵਾਲਾ ਲੱਗਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਵਿਚਾਰ ਇਕੱਤਰ ਨਹੀਂ ਕਰ ਰਹੇ; ਤੁਸੀਂ ਸ਼ੋਰ ਵਿੱਚੋਂ ਸੰਕੇਤ ਨੂੰ ਛਾਂਟ ਰਹੇ ਹੋ ਅਤੇ ਸਿੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਕਿ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕੀ ਵਰਤਦੇ ਹਨ। ਵੱਡਾ ਰੋਡਮੈਪ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਇਹ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਤੋਂ ਮੁੱਲ ਲੈ ਸਕਦੇ ਹਨ। ਕੁਝ ਅਸਲ ਕਾਰਵਾਈਆਂ ਇੱਕ ਲੰਬੀ ਵਿਲ-ਲਿਸਟ ਤੋਂ ਜ਼ਿਆਦਾ ਮਤਲਬ ਰੱਖਦੀਆਂ ਹਨ।

ਕੀਮਤ ਇਕ ਹੋਰ ਪਹਲੂ ਜੋੜਦੀ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ, ਕੀਮਤ ਬਾਰੇ ਟਿੱਪਣੀਆਂ ਸਿਰਫ਼ ਆਮ ਐਤਿਰਾਜ ਵੱਗੋਂ ਲੱਗ ਸਕਦੀਆਂ ਹਨ। ਅਕਸਰ ਉਹ ਦਰਅਸਲ ਭਰੋਸੇ ਬਾਰੇ ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਯੂਜ਼ਰ ਪੁੱਛਦੇ ਹਨ ਕਿ ਇੱਕ ਯੋਜਨਾ ਦੀ ਕੀਮਤ ਕਿਉਂ ਹੈ, ਉਹ ਇਹ ਵੀ ਪੁੱਛ ਰਹੇ ਹੋ ਸਕਦੇ ਹਨ ਕਿ ਪ੍ਰੋਡਕਟ ਭਰੋਸੇਯੋਗ, ਲਾਭਕਾਰੀ ਅਤੇ ਸਪਸ਼ਟ ਹੈ ਜਾਂ ਨਹੀਂ।

ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ ਇਸਨੂੰ ਆਸਾਨ ਕਰ ਦੇਂਦੀ। ਜੇ ਤਿੰਨ ਅਰੰਭਕ ਯੂਜ਼ਰ ਵੱਖ-ਵੱਖ ਨਵੇਂ ਫੀਚਰ ਮੰਗਦੇ ਹਨ, ਪਰ ਦੋ ਹੋਰ onboarding ਦੇ ਦੌਰਾਨ ਫਸ ਗਏ ਸਨ, ਤਾਂ ਵੱਡੀ ਸਮੱਸਿਆ ਘੱਟ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹੈ। ਅਸਲ ਮਸਲਾ ਉਹ friction ਹੈ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮੁੱਲ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕ ਰਿਹਾ ਹੈ। ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਹਰ ਕਮਜ਼ੋਰੀ ਇਕੱਠੀ ਤਰ੍ਹਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ।

ਉਹ ਸਹਾਇਤਾ ਚੈਨਲ ਚੁਣੋ ਜੋ ਲੋਕ ਵਰਤਣਗੇ

ਜ਼ਿਆਦਾ ਚੈਨਲ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਵਧੀਆ ਸਹਾਇਤਾ ਨਹੀਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਕੱਠੇ ਲਾਈਵ ਚੈਟ, ਇਮੇਲ, ਕਮਿਊਨਿਟੀ, ਸੋਸ਼ਲ ਡੀਐਮਸ ਅਤੇ ਫਾਰਮ ਸਾਰੇ ਖੋਲ੍ਹ ਦਿੰਦੇ ਹੋ, ਸੁਨੇਹੇ ਗੁੰਮ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਖੋ ਦੇਂਦੇ ਹਨ।

ਇੱਕ ਜਾਂ ਦੋ ਜਗ੍ਹਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਲਈ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੋਣ। ਜ਼ਿਆਦਾਤਰ ਅਰੰਭਿਕ ਉਤਪਾਦਾਂ ਲਈ ਇਹ ਇਕ ਸਿੱਧਾ ਚੈਨਲ—ਜਿਵੇਂ ਇਮੇਲ ਜਾਂ in-app chat—ਅਤੇ ਇੱਕ ਸਵੈ-ਸੇਵਾ ਜਗ੍ਹਾ, ਜਿਵੇਂ ਇੱਕ ਸਧਾਰਨ help page ਜਾਂ FAQ, ਹੁੰਦੀ ਹੈ।

ਇਹ ਸੈੱਟਅਪ ਉਹ ਸਿੱਖਣ ਲਈ ਕਾਫ਼ੀ ਹੈ ਜੋ ਲੋਕ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਬੇਕਾਰ ਫੈਲਾਉਣ ਦੇ।

ਦਿਨ ਪਹਿਲੋਂ ਹੀ ਜਵਾਬ ਦੇ ਸਮੇਂ ਸਪਸ਼ਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਹਫਤੇ ਦੇ ਕੰਮ ਦਾ ਦਿਨ ਵਿੱਚ ਚਾਰ ਘੰਟਿਆਂ ਵਿੱਚ ਜਵਾਬ ਦੇਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਦੱਸੋ। ਜੇ weekends 'ਤੇ ਕਮ ਜਵਾਬ ਹੁੰਦਾ ਹੈ, ਉਹ ਵੀ ਦੱਸੋ। ਜਦੋਂ ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਉਮੀਦ ਕੀ ਹੈ ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਰਹਿੰਦੇ ਹਨ। ਉਹ ਉਸ ਵੇਲੇ ਬਹੁਤ ਨਾਰਾਜ਼ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਕਿਸਨੇ ਉਹਨਾਂ ਦਾ ਸੁਨੇਹਾ ਦੇਖਿਆ ਵੀ ਕਿ ਨਹੀਂ।

ਜਦੋਂ ਪੈਟਰਨ ਵਾਰ ਵਾਰ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਸੰਭਾਲ ਕੇ ਰੱਖੋ। ਤੁਹਾਨੂੰ ਹੋਰ ਵੱਡਾ knowledge base ਲੌੜੀਂਦਾ ਨਹੀਂ। ਸਿਰਫ਼ ਉਹਨਾਂ ਮੁੱਦਿਆਂ ਦੀ ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਰੱਖੋ ਜੋ ਯੂਜ਼ਰ ਮੁੜ-ਮੁੜ ਪੁੱਛਦੇ ਹਨ—ਜਿਵੇਂ ਲੌਗਇਨ ਸਮੱਸਿਆਵਾਂ, ਬਿੱਲਿੰਗ ਦੀ ਜਾਣਕਾਰੀ, ਜਾਂ ਕੋਈ ਫੀਚਰ ਜੋ ਉਮੀਦ ਦੇ ਮੁਤਾਬਿਕ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਇੱਕ ਆਸਾਨ ਨਿਯਮ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਇੱਕੋ ਪ੍ਰਸ਼ਨ ਤਿੰਨ ਵਾਰੀ ਜਵਾਬ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਲਿਖ ਲਓ।

ਕੇਵਲ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਨਾ ਦਿਓ ਕਿ ਲੋਕ ਕਿੱਥੇ ਮਦਦ ਮੰਗਦੇ ਹਨ; ਇਨ੍ਹਾਂ ਥਾਵਾਂ ਉਤੇ ਵੀ ਦਿਆਨ ਦਿਓ ਜਿੱਥੇ ਉਹ ਬਿਨਾਂ ਪੁੱਛੇ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਲੋਕ ਸੈਟਅਪ ਬਾਰੇ ਲਗਾਤਾਰ ਇਮੇਲ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ onboarding ਵਿੱਚ ਗੁੰਝਲ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਉਹ ਐਪ ਖੋਲ੍ਹਦੇ ਹਨ, ਕੁਝ ਕਲਿੱਕ ਕਰਦੇ ਹਨ ਅਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਉਹ ਸ਼ਾਇਦ ਉਹਨਾਂ ਦੇ ਪਹਿਲੇ ਸਵਾਲ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫਸ ਰਹੇ ਹਨ।

ਇਹ ਉਹਨਾਂ ਉਤਪਾਦਾਂ ਲਈ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੈ ਜੋ ਗੈਰ-ਟੈਕਨੀਕਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai 'ਤੇ, ਚੈਟ ਤੋਂ ਐਪ ਬਣਾਉਣ ਵਾਲਾ ਕੋਈ ਵਿਅਕਤੀ ਸ਼ਾਇਦ ਸਮੱਸਿਆ ਲਈ ਟੈਕਨੀਕਲ ਟਰਮ ਨਹੀਂ ਜਾਣਦਾ। ਉਹ ਕਹ ਸਕਦਾ ਹੈ, "ਮੇਰੀ ਐਪ ਮੋਬਾਈਲ 'ਤੇ ਠੀਕ ਨਹੀਂ ਲੱਗ ਰਹੀ" ਬਜਾਏ ਕਿ ਲੇਆਉਟ ਸਮੱਸਿਆ ਦਾ ਵਰਣਨ ਕਰਨ ਦੇ। ਤੁਹਾਡੀ ਸਹਾਇਤਾ ਪ੍ਰਣਾਲੀ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪੁੱਛਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।

ਉਹ ਪ੍ਰਸ਼ਨਾਂ ਟਰੈਕ ਕਰੋ ਜੋ ਮੁੜ-ਮੁੜ ਆਉਂਦੇ ਹਨ। ਹਰ ਸੁਨੇਹਾ ਨੂੰ ਫੀਚਰ ਮੰਗ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਦੁਹਰਾਏ ਗਏ ਸਹਾਇਤਾ ਮੁੱਦੇ ਅਕਸਰ ਬਿਹਤਰ ਲੇਬਲ, ਸਪਸ਼ਟ ਕਦਮ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਫਿਕਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ ਜੋ ਹਰ ਕਿਸੇ ਲਈ friction ਘਟਾ ਸਕਦਾ ਹੈ।

ਦਿਨ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਨੰਬਰ ਟ੍ਰੈਕ ਕਰੋ

Signups ਦਿੱਖਣ ਵਿੱਚ ਰੋਮਾਂਚਕ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਪ੍ਰੋਡਕਟ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸ਼ੁਰੂ ਵਿੱਚ ਲੁਭਾਉਣ ਵਾਲਾ ਸਵਾਲ ਸਧਾਰਨ ਹੈ: ਕੀ ਨਵੇਂ ਯੂਜ਼ਰੋਂ ਨੂੰ ਜਲਦੀ ਹੀ ਮੁੱਲ ਮਿਲਿਆ ਜਿਸ ਕਾਰਣ ਉਹ ਮੁੜ ਆਉਂਦੇ ਹਨ?

activation ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਆਰੰਭਕ ਕਾਰਵਾਈ ਨੂੰ ਪਰिभਾਸ਼ਿਤ ਕਰੋ ਜੋ ਦਿਖਾਏ ਕਿ ਯੂਜ਼ਰ ਨੇ ਪ੍ਰੋਡਕਟ ਦਾ ਮੁੱਖ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰ ਲਿਆ। ਕਿਸੇ SaaS ਲਈ ਇਹ ਪ੍ਰਾਜੈਕਟ ਬਣਾਉਣਾ ਹੋ ਸਕਦਾ ਹੈ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਲਈ ਇਹ ਇਕ ਚੈਟ ਪ੍ਰੌਂਪਟ ਨੂੰ ਵਰਕਿੰਗ ਐਪ ਡਰਾਫਟ ਵਿੱਚ ਬਦਲਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਲੋਕ ਸਾਈਨਅਪ ਕਰਦੇ ਹਨ ਪਰ ਉਹਨਾਂ ਨੇ ਉਹ ਫ਼ੈਸਲਾ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ ਵਧੇਰੇ ਟਰੈਫਿਕ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ।

Retention ਵੀ ਬਰਾਬਰ ਮਤਲਬ ਰੱਖਦਾ ਹੈ। ਦੇਖੋ ਕਿ ਪਹਿਲੀ ਸੈਸ਼ਨ ਤੋਂ ਬਾਅਦ ਕਿੰਨੇ ਯੂਜ਼ਰ ਮੁੜ ਆਉਂਦੇ ਹਨ, ਕਈ ਦਿਨਾਂ ਬਾਅਦ ਅਤੇ ਇੱਕ ਹਫ਼ਤਾ ਬਾਅਦ। ਤੁਹਾਨੂੰ ਹੁਣ ਵੱਡੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਸਾਦਾ ਹਫਤਾਵਾਰੀ ਟੇਬਲ ਕਾਫ਼ੀ ਹੈ ਜੇ ਇਹ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਕੌਣ ਸਾਈਨਅਪ ਕੀਤਾ, ਕੌਣ activated ਹੋਇਆ, ਅਤੇ ਕੌਣ ਮੁੜ ਆਇਆ।

ਇਕ ਹੋਰ ਨੰਬਰ ਜੋ ਦੇਖਣ ਯੋਗ ਹੈ ਉਹ failed actions ਹਨ। ਇਹ ਉਹ ਘੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਕੋਈ ਮਹੱਤਵਪੂਰਨ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਅਤੇ ਫਸ ਜਾਂਦੇ ਹਨ। ਇਹ ਕਿਸੇ ਟੁੱਟੀ ਹੋਈ onboarding ਚरण, failed publish flow, generation ਦਾ timeout ਹੋਣਾ, ਜਾਂ billing ਦੌਰਾਨ ਪਰੇਸ਼ਾਨੀ ਹੋ ਸਕਦੀ ਹੈ। failed actions ਅਕਸਰ ਬੁਰੇ ਰਿਵਿਊਜ਼ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸਮੱਸਿਆ ਨੂੰ ਸਮਝਾਉਂਦੇ ਹਨ।

ਇਹ ਵੀ ਮਦਦਗਾਰ ਹੈ ਕਿ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰੋ ਕਿ ਲੋਕ ਕਿੱਥੇ ਮਦਦ ਮੰਗਦੇ ਹਨ। ਜੇ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਸ਼ਨ ਇੱਕੋ ਸਕਰੀਨ ਜਾਂ ਸੈਟਅਪ ਕਦਮ ਤੋਂ ਆ ਰਹੇ ਹਨ, ਉਦੋਂ ਉਸ ਖੇਤਰ ਨੂੰ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ। ਸਹਾਇਤਾ ਸੁਨੇਹੇ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਵੱਖਰੇ ਨਹੀਂ ਹਨ—ਉਹ ਪ੍ਰੋਡਕਟ ਸੰਕੇਤ ਦਾ ਹਿੱਸਾ ਹਨ।

ਪਹਿਲਾ ਸਕੋਰਕਾਰਡ ਛੋਟਾ ਰੱਖੋ:

• ਨਵੇਂ signups
• activated ਯੂਜ਼ਰ
• returning/ਮੁੜ ਆਉਣ ਵਾਲੇ ਯੂਜ਼ਰ
• ਮੁੱਖ failed actions
• ਵਿਸ਼ਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ help requests

ਹਫਤਾਵਾਰੀ ਸਮੀਖਿਆ ਵਿੱਚ ਦੋ ਹੋਰ ਟੈਗ ਜੋੜੋ: churn reasons ਅਤੇ refund requests. "ਕੰਗਾਲੀ ਮਹਿੰਗੀ ਹੈ" ਲਿਖ ਕੇ ਅੱਗੇ ਨਾ ਠਹਿਰੋ। ਅਸਲ ਕਾਰਨ ਨੋਟ ਕਰੋ—ਜਿਵੇਂ ਕੋਈ ਗੁੰਝਲਦਾਰ ਫੀਚਰ, ਅਸਪਸ਼ਟ ਸੈਟਅਪ, ਨਰਮ ਨਤੀਜੇ, ਜਾਂ ਖਰਾਬ ਭਰੋਸੇਯੋਗਤਾ।

ਹਰ ਹਫਤੇ ਉਹੀ ਨੰਬਰ ਇਕੋ ਕ੍ਰਮ ਵਿੱਚ ਰਿਵਿਊ ਕਰੋ। ਇਹ ਅਭਿਆਸ ਬੇਮਿਸਾਲ ਟੂਲਾਂ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਨਾਪਣ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹੋ ਤਾਂ ਛੋਟੀ ਰੁਝਾਨਾਂ ਆਸਾਨੀ ਨਾਲ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ।

ਉਹ ਮੁੱਦੇ ਠੀਕ ਕਰੋ ਜੋ ਭਰੋਸਾ ਰੋਕ ਰਹੇ ਹਨ

ਯੂਜ਼ਰ ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਪਰਫੈਕਸ਼ਨ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਉਹ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਜਦ ਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਡਕਟ ਕੰਮ ਕਰੇ। ਜੇ ਕੋਈ ਪੇਜ ਟੁੱਠਦਾ ਹੈ, ਸੇਵ fail ਹੁੰਦੀ ਹੈ, ਜਾਂ ਲੌਗਇਨ ਇਮੇਲ ਨਹੀਂ ਆਉਂਦੀ, ਤਾਂ ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਹੈ। ਇਹ ਸੁੰਦਰ ਡਿਜ਼ਾਇਨ ਜਾਂ ਇੱਕ ਗੁੰਮ ਹੋਈ ਵਾਧੂ ਫੀਚਰ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ।

ਉਨਾਂ ਫਲੋਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕਾਂ ਨੂੰ ਮੁੱਲ ਤੱਕ ਲਿਜਾਂਦੇ ਹਨ: ਸਾਈਨਅਪ, ਲੌਗਇਨ, ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ, ਉਸਨੂੰ ਸੇਵ ਕਰਨਾ, ਭੁਗਤਾਨ ਕਰਨਾ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੁੜ ਆਉਣਾ। ਜੇ ਇਹਨਾਂ 'ਚੋਂ ਕੋਈ ਵੀ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਛੋਟੀ UI ਸੁਧਾਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।

ਇੱਕ ਆਸਾਨ ਨਿਯਮ ਇੱਥੇ ਮਦਦ ਕਰਦਾ ਹੈ: ਰਸਤੇ ਨੂੰ ਮੁਰੰਮਤ ਕਰੋ ਪਹਿਲਾਂ, ਲੈਂਡਸਕੇਪ ਨੂੰ ਸੁੰਦਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ। ਇਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਕਚੀ ਸਕ੍ਰੀਨ ਸੁੰਦਰ ਪਰ ਡੇਟਾ ਖੋਣ ਵਾਲੀ ਸਕ੍ਰੀਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਲੱਗਦੀ ਹੈ।

ਅਕਸਰ ਜਲਦੀ ਮੁਰੰਮਤੀਆਂ ਕੁਝ ਅਗਲੇ ਗਰੁੱਪਾਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ: ਬਿੱਲਿੰਗ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਲੌਗਇਨ ਦੇ ਮੁੱਦੇ, ਸੁਸਤ ਪੇਜ, ਅਤੇ failed saves ਜਾਂ ਟੁੱਟੇ onboarding ਕਦਮ ਜੋ ਪ੍ਰਗਟੀ ਰੋਕਦੇ ਹਨ। ਇਹ ਉਹ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ 'ਤੇ ਸਵਾਲ ਚੁੱਕਾਉਂਦੀਆਂ ਹਨ।

Onboarding ਖਾਸ ਧਿਆਨ ਲਾਇਕ ਹੈ ਕਿਉਂਕਿ ਗੁੰਝਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰੋਡਕਟ ਦੀ ਕਮਜ਼ੋਰੀ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਜੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਗਲਾ ਕਿਵੇਂ ਕਲਿੱਕ ਕਰਨਾ ਹੈ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪੈ ਰਿਹਾ ਹੈ, ਜਾਂ ਪਹਿਲਾ ਟਾਸਕ ਬਹੁਤ ਸਾਰੇ ਕਦਮ ਰੱਖਦਾ ਹੈ, ਉਹ ਫ਼ੈਸਲਾ ਕਰ ਲੈਂਦੇ ਹਨ ਕਿ ਪੂਰਾ ਐਪ ਹੀ ਔਖਾ ਹੈ। ਕਦਮ ਘਟਾਓ, ਸਪਸ਼ਟ ਲੇਬਲ ਪਾਓ, ਅਤੇ ਇਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਾਰਵਾਈ ਦਿਖਾਓ।

ਗਤੀ (speed) ਵੀ ਭਰੋਸੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ। ਇੱਕ ਪੇਜ ਨੂੰ ਤੁਰੰਤ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਉਹ ਸੰਵੇਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਕੁਝ ਕੁ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ ਤਾਂ ਪ੍ਰਗਤੀ ਦਿਖਾਓ ਅਤੇ ਸਫਲਤਾ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਖਾਮੋਸ਼ੀ ਲੋਕਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਹੋਏ ਕਾਪੀ ਕੰਮ, ਸਹਾਇਤਾ ਬੇਨਤੀਆਂ ਅਤੇ ਤਣਾਅ ਬਣਦੇ ਹਨ।

ਜਦੋਂ ਕੋਈ ਫਿਕਸ ਲਾਈਵ ਹੋ ਜਾਏ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਦੱਸੋ। ਇੱਕ ਛੋਟਾ ਸੁਨੇਹਾ ਜਿਵੇਂ "We fixed the failed save issue from yesterday" ਲੂਪ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਦਿਖਾਂਦਾ ਹੈ ਕਿ ਕੋਈ ਧਿਆਨ ਦੇ ਰਿਹਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ ਤਾਂ snapshots ਅਤੇ rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਹ ਛੋਟੀ ਮੁਰੰਮਤੀਆਂ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਭਰੋਸਾ ਵਧਦਾ ਹੈ ਜਦ ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ ਕਿ ਸਮੱਸਿਆਵਾਂ ਤੁਰੰਤ, ਸਪਸ਼ਟ ਅਤੇ ਬਿਨਾਂ bahaane ਦੇ ਸੁਲਝਾਈਆਂ ਗਈਆਂ।

ਕੀਮਤ ਫੀਡਬੈਕ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੁਣੋ

ਕੀਮਤ ਦੀਆਂ ਟਿੱਪਣੀਆਂ ਕਾਰآمد ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਿਰਫ਼ ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸੰਦਰਭ ਵਿੱਚ ਪੜ੍ਹਦੇ ਹੋ। ਅਰੰਭਕ ਯੂਜ਼ਰ ਅਕਸਰ "too expensive" ਕਹਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਦਰਅਸਲ ਕਹਿ ਰਹੇ ਹੁੰਦੇ ਹਨ "ਮੈਂ ਹੁਣ ਭਰੋਸਾਹ ਨਹੀਂ ਕਰਦਾ" ਜਾਂ "ਮੈਂ ਅਜੇ ਵੀ ਮੁੱਲ ਨਹੀਂ ਵੇਖ ਰਿਹਾ"।

ਜਦੋਂ ਕੋਈ ਕੀਮਤ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿਖਾਏ, ਇੱਕ follow-up ਸਵਾਲ ਪੁੱਛੋ: ਤੁਹਾਨੂੰ ਕੀ ਚੀਜ਼ ਉੱਚੀ ਜਾਂ ਘੱਟ ਮਹਿਸੂਸ ਕਰਵਾ ਰਹੀ ਹੈ? ਉਹਨਾਂ ਦਾ ਜਵਾਬ ਅਕਸਰ ਅਸਲ ਮੁੱਦੇ ਨੂੰ ਬਤਾਏਗਾ। ਘੱਟ ਬਜਟ ਵਾਲਾ ਵਿਅਕਤੀ ਉਸ ਤੋਂ ਵੱਖਰਾ ਹੈ ਜੋ ਕਿਸੇ ਐਸੇ ਫੀਚਰ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਜੇ ਨਹੀਂ ਦਿੰਦੇ।

ਉਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਬਜਟ ਸੰਬੰਧੀ ਚਿੰਤਾਵਾਂ ਤੁਹਾਨੂੰ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕੌਣ ਹੁਣ ਲਈ ਤੁਹਾਡਾ ਗਾਹਕ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਉਤਪਾਦੀ ਖਾਮੀਆਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਉਹ ਕਿਸੇ ਸਹੀ ਗਾਹਕ ਨੂੰ ਭੁਗਤਾਨ ਕਰਨ ਤੋਂ ਰੋਕ ਰਹੀਆਂ ਹਨ।

ਹਰ ਵਾਰੀ ਜਦੋਂ ਤੁਸੀਂ ਕੀਮਤ ਬਾਰੇ ਫੀਡਬੈਕ ਸੁਨੋ ਤਾਂ ਤਿੰਨ ਵਿਸਥਾਰ ਨੋਟ ਕਰੋ:

• ਕਿਸ ਨੇ ਦਿੱਤਾ
• ਕਦੋਂ ਦਿੱਤਾ
• ਉਹ ਕਿਸ ਕੰਮ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸਨ

ਇੱਕ ਦਿਨ ਦਾ ਟ੍ਰਾਇਲ ਯੂਜ਼ਰ ਅਤੇ ਇੱਕ ਐਸਾ ਯੂਜ਼ਰ ਜਿਸਨੇ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਨਾਲ ਅਸਲ ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ ਹੋਵੇ, ਦੋ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਸੋਚਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ foundਰ ਜੋ Koder.ai 'ਤੇ ਪਹਿਲੀ ਵਰਜਨ ਬਣਾ ਰਿਹਾ ਹੈ, ਸੈਟਅਪ ਪੂਰਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀਮਤ 'ਤੇ ਅਕਸਰ ਵਿਰੋਧ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਹਰ ਵਾਰੀ ਯੋਜਨਾ ਗਲਤ ਹੈ, ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ—ਬਲਕਿ ਉਹ ਅਜੇ ਓਸ ਲਹਜੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਜਿੱਥੇ ਮੁੱਲ ਸਪਸ਼ਟ ਹੈ।

ਰੁਝਾਨ ਲੱਭੋ, ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ। ਇੱਕ ਉੱਚ ਆਵਾਜ਼ ਵਾਲੀ ਰਾਏ ਤੁਹਾਨੂੰ ਗਲਤ ਰਾਹ 'ਤੇ ਲੈ ਜਾ ਸਕਦੀ ਹੈ। ਜੇ ਇਕੋ ਕਿਸਮ ਦੇ ਪੰਜ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ free ਯੋਜਨਾ ਜ਼ਿਆਦਾ ਛੋਟੇ ਸਮੇਂ ਲਈ ਖਤਮ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਅਸਲ ਸੂਚਕ ਹੈ। ਜੇ ਇੱਕ ਵਿਅਕਤੀ enterprise ਫੀਚਰ starter ਕੀਮਤ 'ਤੇ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਮਤੌਰ ਤੇ ਨਹੀਂ ਹੈ।

ਵੱਡਾ ਕੀਮਤ ਬਦਲਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਛੋਟੇ ਢੰਗਾਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਸਪਸ਼ਟ ਯੋਜਨਾ ਨਾਮ, ਵਧੀਆ ਲਫ਼ਜ਼, ਵੱਖ-ਵੱਖ ਉਪਯੋਗ ਸੀਮਾਵਾਂ, ਜਾਂ ਇਕ ਸਧਾਰਾ ਤુલਨਾਤਮਕ ਟੇਬਲ ਕੀਮਤ ਨੂੰ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਬਦਲ ਸਕਦੇ ਹਨ।

ਉਹ ਵਾਕਾਂ ਨੂੰ ਵੀ ਸੁਣੋ ਜੋ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ। "I would pay if..." ਉਸ ਵੇਲੇ ਕਾਰآمد ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਸੇ ਖਤਮ ਹੋਣ ਵਾਲੀ ਵਾਕ ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਜਵਾਬ ਕਈ ਵਾਰ ਮਿਲੇ। ਇਹ ਉਸ ਵੇਲੇ ਕੀਮਤ ਫੀਡਬੈਕ ਨੂੰ ਐਕਸ਼ਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਹਫਤਾਵਾਰੀ ਸਮੀਖਿਆ ਰੂਟੀਨ

ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਤਤਕਾਲ ਲੱਗਦੀ ਹੈ, ਇਸੀ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਬੁਨਿਆਦੀ ਰਿਦਮ ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਹਫਤਾਵਾਰੀ ਸਮੀਖਿਆ ਤੁਹਾਨੂੰ ਸੰਕੇਤ ਨੂੰ ਸ਼ੋਰ ਤੋਂ ਵੱਖ ਕਰਕੇ steady ਤਰੀਕੇ ਨਾਲ ਅੱਗੇ ਵਧਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।

ਹਰ ਦਿਨ ਲਈ ਇੱਕ ਛੋਟਾ ਸਮੀਖਿਆ ਬਲਾਕ ਚੁਣੋ। 30-60 ਮਿੰਟ ਰੱਖੋ ਜਦ ਤਕ ਕੁਝ ਜਲਦੀ ਨਹੀਂ ਹੋ ਰਿਹਾ। ਲਕਸ਼ਿਅ ਇਹ ਨਹੀਂ ਕਿ ਹੋਰ ਮੀਟਿੰਗਾਂ ਹੋਣ। ਲਕਸ਼ਿਅ ਇਹ ਹੈ ਕਿ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਮੂਨੇ ਜਲਦੀ ਨਜ਼ਰ ਆਉਣਾ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਅਮਲ ਕਰਨਾ ਜਦ ਪ੍ਰੋਡਕਟ ਛੋਟਾ ਹੈ।

ਪੰਜ-ਦਿਨਾਂ ਰਿਦਮ

ਇੱਕ ਉਪਯੋਗੀ ਪੈਟਰਨ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

• ਹਫਤੇ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਹਾਇਤਾ ਦੀ ਮਾਤਰਾ, ਜਵਾਬ ਦੇ ਸਮੇਂ, ਅਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਉਲੇਖ ਕੀਤੀ ਗਈਆਂ ਸਮੱਸਿਆਵਾਂ ਵੇਖੋ।
• ਫਿਰ activation ਤੇ retention ਵੇਖੋ। ਕੀ ਨਵੇਂ ਯੂਜ਼ਰ ਪਹਿਲੀ ਸਫਲਤਾ ਦਾ ਮੋਮੈਂਟ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹਨ? ਕੀ ਉਹ ਕੁਝ ਦਿਨਾਂ ਬਾਅਦ ਮੁੜ ਆ ਰਹੇ ਹਨ?
• ਮੱਧ-ਹਫ਼ਤੇ ਵਿੱਚ ਛੋਟੀਆਂ fixes ship ਕਰੋ ਅਤੇ ਹਰ ਟਾਸਕ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਮਾਲਕ ਰੱਖੋ।
• ਬਾਅਦ ਵਿੱਚ ਕੁਝ active ਯੂਜ਼ਰਾਂ ਅਤੇ ਕੁਝ ਜੋ ਚੁੱਪ ਹੋ ਗਏ ਉਨ੍ਹਾਂ ਨਾਲ ਗੱਲ ਕਰੋ।
• ਹਫਤੇ ਦੇ ਅੰਤ 'ਤੇ ਅਗਲੇ ਹਫਤੇ ਦੀਆਂ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਨੂੰ ਪਿਛਲੇ ਸਿੱਖਣ ਦੇ ਅਧਾਰ 'ਤੇ ਲਿਖੋ।

ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਦਿਨ ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਸਹਾਇਤਾ ਦਿਖਾਂਦੀ ਹੈ ਕਿ ਲੋਕ ਕਿੱਥੇ ਫਸਦੇ ਹਨ। ਵਿਸ਼ਲੇਸ਼ਣ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਸਮੱਸਿਆਵਾਂ ਵਰਤਾਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ। ਛੋਟੇ fixes ਫੀਡਬੈਕ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ੀ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ। ਯੂਜ਼ਰ ਕਾਲ ਨੰਬਰਾਂ ਦੇ ਪਿੱਛੇ ਦੀ ਕਹਾਣੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ। ਇੱਕ ਸ਼ੁਕਰਵਾਰ ਦਾ reset ਤੁਹਾਡੇ backlog ਨੂੰ wish list ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਸਮੀਖਿਆ ਹਲਕੀ ਰੱਖੋ। ਇਕ ਸਾਂਝਾ ਡੌਕ ਜਾਂ ਬੋਰਡ ਵਰਤੋਂ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਸਧਾਰਨ ਕਾਲਮ ਹੋਣ: what we saw, what we changed, what we will watch next week. ਜੇ ਪੰਜ ਯੂਜ਼ਰਾਂ ਨੇ ਇੱਕ onboarding ਕਦਮ ਟੁੱਟਿਆ ਰਿਪੋਰਟ ਕੀਤਾ, ਉਹ ਸਿਖਰ 'ਤੇ ਆਉਂਦਾ ਹੈ। ਜੇ ਇੱਕ ਵਿਅਕਤੀ ਇਕ ਵੱਡਾ ਨਵਾਂ ਫੀਚਰ ਮੰਗਦਾ ਹੈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਰੁਕਦਾ ਹੈ।

ਛੋਟੀ ਟੀਮ, ਜੋ Koder.ai ਵਰਤਦੀ ਹੈ ਉਦਾਹਰਨ ਵਜੋਂ, ਨੋਟ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਕਈ ਯੂਜ਼ਰ ਚੈਟ ਵਿੱਚ ਐਪ ਆਈਡਿਆ ਤਿਆਰ ਕਰ ਲੈਂਦੇ ਹਨ ਪਰ deployment ਤੋਂ ਪਹਿਲਾਂ ਅਟਕ ਜਾਂਦੇ ਹਨ। ਇਹ weekly focus ਲਈ ਇੱਕ ਵਧੀਆ ਚੀਜ਼ ਹੈ ਨਾਂ ਕਿ ਹੋਰ ਟੈਂਪਲੇਟ ਜਾਂ ਵਾਧੂ ਵਿਕਲਪ ਜੋੜਨਾ। blocker ਨੂੰ ਠੀਕ ਕਰੋ, ਨੰਬਰ ਵੇਖੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅੱਗੇ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਰੁਟੀਨ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ। ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ ਕਿ ਬੱਗ ਠੀਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਕੀਮਤ ਬਾਰੇ ਸੁਨੇਹੇ ਨੋਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹਫਤੇ ਦਰ ਹਫਤੇ ਪ੍ਰੋਡਕਟ ਵਰਤਣ ਯੋਗ ਹੋ ਰਿਹਾ ਹੈ।

ਉਦਾਹਰਨ: 25 ਅਰੰਭਕ ਯੂਜ਼ਰਾਂ ਵਾਲਾ ਇੱਕ ਛੋਟਾ SaaS

ਇੱਕ ਛੋਟੀ ਟੀਮ ਦੀ ਰੂਪਕਲਪਨਾ ਕਰੋ ਜਿਸde 25 ਅਰੰਭਕ ਯੂਜ਼ਰ ਹਨ। ਪਹਿਲੇ ਹਫਤੇ 10 ਲੋਕ ਸਾਈਨਅਪ ਕਰਦੇ ਹਨ, ਪਰ ਕੇਵਲ 4 setup ਪੂਰਾ ਕਰਕੇ ਉਹ ਅੰਤਰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਪ੍ਰੋਡਕਟ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।

ਇਹ ਫਰਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਹ ਟੀਮ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਵృద్ధੀ ਪਹਿਲੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ—activation ਹੈ।

ਸਹਾਇਤਾ ਸੁਨੇਹਿਆਂ ਨੂੰ ਪੜ੍ਹਕੇ ਉਹ ਇੱਕ ਪੈਟਰਨ ਵੇਖਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਸ਼ਨ ਗੁੰਝਲਦਾਰ onboarding ਚਰਨ ਬਾਰੇ ਹਨ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕਿ ਡੇਟਾ ਕਨੈਕਟ ਕਰਨ ਨੂੰ ਪਹਿਲਾਂ ਕਰੋਂ, ਪਰ ਉਹ ਸਮਝਦੇ ਨਹੀਂ ਕਿ ਇਹ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ।

ਜੋ ਟੀਮ ਅਸਲ ਵਿੱਚ dashboard ਫੀਚਰ ਬਣਾਉਣ ਦੀ ਯੋਜਨਾ ਕਰ ਰਹੀ ਸੀ, ਉਸਦੇ ਬਦਲੇ ਉਹ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਕਰਦੀ ਹੈ। ਉਹ setup ਸਕ੍ਰੀਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹਨ, ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਉਦਾਹਰਨ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਇਕ ਵਿਕਲਪਿਕ ਕਦਮ ਨੂੰ ਬਾਅਦ ਲਈ ਟਾਲ ਦਿੰਦੇ ਹਨ।

ਨਤੀਜਾ ਸਧਾਰਨ ਪਰ ਅਹਮ ਹੁੰਦਾ ਹੈ:

• ਹੋਰ ਯੂਜ਼ਰ setup ਪੂਰਾ ਕਰਦੇ ਹਨ
• support ਪ੍ਰਸ਼ਨ ਘਟਦੇ ਹਨ
• ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ ਭਰੋਸਾ ਬਹਿ d



ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਕੀਮਤ ਟਿੱਪਣੀ ਦੋ ਵਾਰੀ ਮਿਲਦੀ ਹੈ। ਦੋ ਯੂਜ਼ਰ ਕਹਿੰਦੇ ਹਨ ਕਿ ਕੀਮਤ ਖ਼ਦੇ ਹੀ ਉੱਚੀ ਨਹੀਂ ਲੱਗਦੀ, ਪਰ ਯੋਜਨਾਵਾਂ ਅਸਪਸ਼ਟ ਹਨ। ਉਹ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਹੁਣ ਉਹਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ, ਕੀ ਸੀਮਾਵਾਂ ਹਨ, ਅਤੇ ਕਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ upgrade ਕਰਨਾ ਪਵੇਗਾ।

ਇਹ messaging ਦੀ ਸਮੱਸਿਆ ਹੈ, ਛੂਟ ਦਾ ਨਹੀਂ। ਇਸ ਲਈ ਟੀਮ pricing ਪੰਨਾ ਦਾ ਭਾਸ਼ਾ ਅਪਡੇਟ ਕਰਦੀ ਹੈ, ਯੋਜਨਾਵਾਂ ਦੇ ਫਰਕ ਨੂੰ ਅਸਾਨੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ upgrade ਪਲ੍ਹਾਂ ਦੱਸਦੀ ਹੈ।

ਹਫਤੇ ਦੇ ਅੰਤ ਤਕ ਉਹਨਾਂ ਕੋਲ ਚੋਣ ਰਹਿੰਦੀ ਹੈ: ਵੱਡੀ ਫੀਚਰ 'ਤੇ ਕੰਮ ਜਾਰੀ ਰੱਖਣਾ ਜਾਂ ਹਰ ਨਵੇਂ ਯੂਜ਼ਰ ਦੇ ਦੇਖਣ ਵਾਲੇ ਰਸਤੇ ਨੂੰ ਹੋਰ ਇੱਕ ਹਫਤਾ ਲਈ ਸਾਫ਼ ਕਰਨਾ।

ਉਹ ਵੱਡੀ ਫੀਚਰ ਇਕ ਹਫਤਾ ਰੁਕਦੇ ਹਨ।

ਛੋਟੀ SaaS ਲਈ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਮਝਦਾਰ ਚੋਣ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਨਰਮ onboarding ਫਿਕਸ activation ਨੂੰ ਅਕਸਰ ਇੱਕ ਚਮਕਦਾਰ ਰਿਲੀਜ਼ ਨਾਲੋਂ ਵੱਧ ਉੱਚਾ ਚੜ੍ਹਾ ਦਿੰਦੀ ਹੈ ਜੋ ਘੱਟ ਲੋਕਾਂ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ।

ਇਹੀ ਅਰੰਭਿਕ traction ਅਮਲ ਵਿੱਚ ਇਹੋ ਜਿਹਾ ਦਿਖਦਾ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਅਗਲਾ ਕਦਮ ਉਹ ਹੈ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲੋਕਾਂ ਨੂੰ ਬਿਨਾਂ ਸਹਾਇਤਾ ਦੇ ਮੁੱਲ ਤੱਕ ਪੁਚਾਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਨਕੀਨ ਦੀ ਗੂੰਜਦਾਰ ਗੱਲ ਨਹੀਂ।

ਪਹਿਲੇ 30 ਦਿਨਾਂ ਵਿੱਚ ਆਮ ਗਲਤੀਆਂ

ਪਹਿਲਾ ਮਹੀਨਾ ਭਰਮਾਉਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇਕੱਠੇ ਬੇਨਤੀਆਂ, ਬੱਗ ਰਿਪੋਰਟਾਂ, ਕੀਮਤ ਦੇ ਵਿਚਾਰ ਅਤੇ ਨਵੇਂ ਫੀਚਰਾਂ ਦੇ ਵਿਚਾਰ ਇਕੱਠੇ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ। ਅਸਲ ਖਤਰਾ ਧੀਮਾ ਨਹੀਂ ਹੋਣਾ; ਇਹ ਹਰ ਇਕ ਸਿਗਨਲ 'ਤੇ ਇੱਲਾਜ਼ ਕਰਨਾ ਹੈ ਜਿਵੇਂ ਉਹੋ ਜਿਹੀ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ।

ਇੱਕ ਆਮ ਗਲਤੀ ਹੈ ਸਭ ਤੋਂ ਉੱਚੀ ਆਵਾਜ਼ ਵਾਲੇ ਯੂਜ਼ਰ ਲਈ ਬਣਾਉਣਾ। ਜੇ ਇੱਕ ਅਰੰਭਕ ਗਾਹਕ ਇੱਕ ਕਸਟਮ ਫੀਚਰ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਉਹ ਤੁਰੰਤ ਜਰੂਰੀ ਲੱਗ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਟ ਤੇਜ਼ੀ ਨਾਲ ਅਪਡੇਟ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਇੱਕ ਅਜਿਹਾ ਫੀਚਰ ਜੋ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਮਦਦ ਕਰਦਾ ਅਤੇ ਬਾਕੀ ਸਭ ਨੂੰ ਉਲਝਾਉਂਦਾ ਹੈ, ਸ਼ੁਰੂ ਵਿੱਚ ਕਰਜ਼ਾ ਬਣਾਉਂਦਾ ਹੈ। ਕੁਝ ਵੀ ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ ਕਿ ਕੀ ਇਹ ਦੁਹਰਾਏ ਗਏ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੇਸ।

ਇੱਕ ਹੋਰ ਗਲਤੀ ਸਭ ਕੁਝ ਮਾਪਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਹੈ। ਨਵੇਂ ਫਾਊਂਡਰ ਅਕਸਰ ਪੰਜ ਡੈਸ਼ਬੋਰਡ ਖੋਲ੍ਹ ਲੈਂਦੇ ਹਨ ਅਤੇ ਹਰ ਕਲਿੱਕ, ਪੇਜ ਵਿਊ ਅਤੇ ਈਵੈਂਟ ਨੂੰ ਟਰੈਕ ਕਰਦੇ ਹਨ। ਇਹ ਧਿਆਨ ਨਾਲ ਲੱਗਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਛਿਪਾ ਦਿੰਦਾ ਹੈ। ਪਹਿਲੇ ਮਹੀਨੇ ਲਈ ਕੁਝ ਨੰਬਰ ਕਾਫ਼ੀ ਹਨ: signups, activation, retention, ਅਤੇ ਸਭ ਤੋਂ ਆਮ support ਮੁੱਦਾ।

ਸਹਾਇਤਾ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਗੜਬੜ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਯੂਜ਼ਰ ਤੁਹਾਨੂੰ ਲਾਈਵ ਚੈਟ, ਇਮੇਲ, X, Discord, ਅਤੇ ਨਿੱਜੀ DMs 'ਤੇ ਸੰਪਰਕ ਕਰਦੇ ਹਨ, ਤਾਂ ਸਧਾਰਨ ਪ੍ਰਸ਼ਨ ਫਸਦੇ ਰਹਿੰਦੇ ਹਨ। ਇੱਕ ਛੋਟੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਵੀ ਸਾਫ਼ ਲੇਨ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ ਮੁੱਖ ਸਹਾਇਤਾ ਚੈਨਲ ਅਤੇ ਇੱਕ ਬੈਕਅਪ ਚੁਣੋ, ਫਿਰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ।

ਕੀਮਤ ਸੰਬੰਧੀ ਗਲਤੀਆਂ ਅਕਸਰ ਕਮਜ਼ੋਰ ਸਬੂਤ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਵਿਅਕਤੀ ਕਹਿੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਯੋਜਨਾ ਮਹਿੰਗੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਘਟਾ ਦਿੰਦੇ ਹੋ। ਦੂਜਾ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਹ ਸਸਤੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਹੋਰ ਟਾਇਰ ਜੋੜ ਦਿੰਦੇ ਹੋ। ਇਹ ਸਿੱਖਣ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਠੀਕ ਕਿਸਮ ਦੇ ਯੂਜ਼ਰਾਂ ਤੋਂ ਵਾਰ-ਵਾਰ ਉਹੀ ਆਪਣੀ ਵਿਰੋਧ ਸੁਣੋ ਤਦ ਹੀ ਬਦਲਾਅ ਕਰੋ।

ਸਭ ਤੋਂ ਨੁਕਸਾਨਦਾਇਕ ਗਲਤੀ bugs ਨੂੰ ਛਪਾਉਣਾ ਹੈ। ਅਰੰਭਕ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪਰਫੈਕਸ਼ਨ ਦੀ ਉਮੀਦ ਨਹੀਂ ਹੁੰਦੀ; ਉਹ ਇਮਾਨਦਾਰੀ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਜੇ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਦੱਸੋ ਕੀ ਹੋਇਆ, ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ, ਅਤੇ ਤੁਸੀਂ ਮੁਰੰਮਤ ਕਦੋਂ ਤੱਕ ਉਮੀਦ ਕਰਦੇ ਹੋ। ਇੱਕ ਸਧਾਰਨ ਵਰਣਨ ਖਾਮੋਸ਼ੀ ਨਾਲੋਂ ਭਰੋਸਾ ਬਚਾਉਂਦਾ ਹੈ।

ਪਹਿਲੇ ਮਹੀਨੇ ਲਈ ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਸਧਾਰਨ ਹੈ:

• ਦੁਹਰਾਏ ਦਰਦ ਨੂੰ ਅਦਾਂ ਕਰੋ ਨਾ ਕਿ ਰੇਅਰ ਬੇਨਤੀਆਂ
• ਕੁਝ ਸੰਕੇਤ ਟ੍ਰੈਕ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅਮਲ ਕਰ ਸਕਦੇ ਹੋ
• ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਛੋਪਦਾ ਨਹੀਂ, ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਵੇਖਾਓ

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਣਾ ਆਸਾਨ ਹੈ ਕਿ ਹਰ ਰੋਜ਼ ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਲਾਂਚ ਕਰੋ। ਤੇਜ਼ੀ ਉਸ ਸਮੇਂ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਭਰੋਸਾ, ਸਪਸ਼ਟਤਾ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਯੂਜ਼ਰਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੱਲ ਟਿਕੀ ਹੋਵੇ।

ਹੋਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਚੈਕਲਿਸਟ

ਹੋਰ ਫੀਚਰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਚੈੱਕ ਕਰੋ ਕਿ ਕੀ ਪ੍ਰੋਡਕਟ ਪਹਿਲਾਂ ਹੀ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਉਪਯੋਗ ਨਤੀਜਾ ਪਹੁੰਚਾ ਰਿਹਾ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਵਧੇਰੇ ਕੋਡ ਅਕਸਰ ਅਸਲ ਸਮੱਸਿਆ ਨੂੰ ਛੁਪਾ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਹੱਲ ਕਰਦਾ ਹੈ।

ਇੱਕ ਆਸਾਨ ਨਿਯਮ ਮਦਦ ਕਰਦਾ ਹੈ: ਜੇ ਨਵੇਂ ਯੂਜ਼ਰ ਗੁੰਝਲਦਾਰ, ਫਸ ਜਾਂ ਰਹੇ ਹਨ, ਜਾਂ ਜਲਦੀ ਛੱਡ ਰਹੇ ਹਨ, ਤਾਂ ਹੋਰ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਹਾਲਤ ਨੂੰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ।

• ਕੀ ਨਵਾਂ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਉਪਯੋਗ ਨਤੀਜਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ? ਜੇ ਅੱਜ ਕੋਈ ਸਾਈਨਅਪ ਕਰੇ, ਕੀ ਉਹ ਮਦਦ ਦੇ ਬਿਨਾਂ ਮੁੱਖ ਕੰਮ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ?
• ਕੀ ਤੁਹਾਨੂੰ ਟਾਪ-ਥਰੀ support issues ਦਾ ਪਤਾ ਹੈ? ਤੁਹਾਨੂੰ ਵੱਡੇ support ਸਿਸਟਮ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਡੇ ਕੋਲ ਆਮ ਸਵਾਲਾਂ ਜਾਂ ਫੇਲ੍ਹਾਂ ਦੀ ਇੱਕ ਦਰਜੀ ਸੂਚੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
• ਕੀ ਤੁਸੀਂ activation ਅਤੇ ਹਫ਼ਤੇ-ਇੱਕ retention ਦੇਖ ਸਕਦੇ ਹੋ? ਇਹ ਦੋ ਨੰਬਰ ਦੱਸਦੇ ਹਨ ਕਿ ਲੋਕ ਜਲਦੀ ਮੁੱਲ ਪਾ ਰਹੇ ਹਨ ਅਤੇ ਮੁੜ ਆ ਰਹੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਹ ਮਾਪ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾ ਰਹੇ ਹੋ।
• ਕੀ ਮੁੱਖ ਬੱਗਸ ਠੀਕ ਕੀਤੇ ਗਏ ਹਨ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਪਤਾ ਲੱਗ ਚੁੱਕੇ ਹਨ? ਭਰੋਸਾ ਤੋੜਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ: failed sign-up, ਗੁੰਮ ਹੋਈ ਜਾਣਕਾਰੀ, ਸੁਸਤ ਲੋਡਿੰਗ, ਬਿੱਲਿੰਗ ਟੁੱਟਣਾ, ਜਾਂ ਅਸਪਸ਼ਟ errors.
• ਕੀ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਤੋਂ ਅਸਲ ਕੀਮਤ ਫੀਡਬੈਕ ਸੁਣਿਆ ਹੈ? ਦੋਸਤਾਂ ਦੇ ਵਿਚਾਰ ਜਾਂ ਟੀਮ ਦੇ ਅਨੁਮਾਨ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਛੋਟੇ, ਸਪਸ਼ਟ ਟਿੱਪਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਉਹਨਾਂ ਲੋਕਾਂ ਤੋਂ ਜਿਨ੍ਹਾਂ ਨੇ ਹਕੀਕਤੀ ਤੌਰ 'ਤੇ ਉਤਪਾਦ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਹਰ ਰੋਜ਼ ਨਵੀਆਂ 아이ਡੀਆ ship ਕਰਨ ਦਾ ਲੋਭ ਹੋ ਸਕਦਾ ਹੈ। ਤੇਜ਼ੀ ਤਦ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਸਹੀ ਸਮੱਸਿਆ 'ਤੇ ਨਿਸ਼ਾਨਾ ਹੋਵੇ। ਤੁਹਾਡੀ ਤੇਜ਼ੀ ਦਾ ਵਧੀਆ ਉਪਯੋਗ onboarding friction ਠੀਕ ਕਰਨ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ support issues ਹਟਾਉਣ, ਅਤੇ ਮੁੱਲ ਤੱਕ ਰਸਤੇ ਨੂੰ ਤੰਗ ਕਰਨਾ ਹੈ।

ਇੱਕ ਅਚਛਾ ਟੈਸਟ ਇਹ ਹੈ: ਜੇ ਇਸ ਹਫਤੇ 10 ਨਵੇਂ ਯੂਜ਼ਰ ਆਏ, ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋਂਗੇ ਕਿ ਉਹ ਕਿੱਥੇ ਫਸੇ, ਕਿਉਂ ਰਹੇ, ਅਤੇ ਕੀ ਉਸੇ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਛੱਡਣ ਨੂੰ ਮਜਬੂਰ ਕੀਤਾ? ਜੇ ਜਵਾਬ ਨਾ ਹੈ, ਤਾਂ ਫੀਚਰ ਕੰਮ ਰੋਕੋ ਅਤੇ ਪਹਿਲਾਂ ਇਹ ਸਾਫ਼ ਕਰੋ।

ਪਹਿਲੇ ਮਹੀਨੇ ਤੋਂ ਬਾਅਦ ਕੀ ਕਰਨਾ

ਪਹਿਲੇ ਮਹੀਨੇ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੇ ਕੰਮ ਦੀ ਕਿਸਮ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਹੁਣ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਕਿ ਲੋਕ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ; ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਰਹੇ ਹੋ ਕਿ ਲੋਕ ਪ੍ਰੋਡਕਟ ਵਰਤ ਸਕਦੇ ਹਨ, ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਮੁੜ ਆਉਂਦੇ ਹਨ।

ਅਗਲੇ 30 ਦਿਨਾਂ ਲਈ ਇੱਕ ਛੋਟੀ ਪਰ ਸਪਸ਼ਟ ਪ੍ਰਾਇਰਿਟੀ ਲਿਸਟ ਰੱਖੋ। ਨਾ ਕੋਈ ਵੱਡਾ ਰੋਡਮੈਪ ਜਾਂ ਵਿਲ-ਲਿਸਟ। ਸਿਰਫ਼ ਕੁਝ ਬਦਲਾਅ ਜੋ ਪ੍ਰੋਡਕਟ ਨੂੰ ਭਰੋਸੇਯੋਗ ਅਤੇ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਇੱਕ ਚੰਗੀ ਲਿਸਟ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦੀ ਹੈ:

• ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ਾਂ ਲਈ ਇੱਕ ਜਾਂ ਦੋ fixes
• onboarding ਜਾਂ setup ਵਿੱਚ ਇੱਕ ਸੁਧਾਰ
• ਇੱਕ ਸਹਾਇਤਾ ਬਦਲਾਅ ਜੋ ਦੁਹਰਾਏ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਘਟਾਏ
• ਇੱਕ ਕੀਮਤ ਪ੍ਰਸ਼ਨ ਜੋ ਤੁਸੀਂ ਅਜੇ ਵੀ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ

ਕੇਵਲ ਫੀਚਰ ਜੋੜੋ ਜਦੋਂ ਇੱਕੋ ਮੰਗ ਵਾਰ-ਵਾਰ ਦੁਹਰਾਈ ਜਾਵੇ, ਉਹ ਵੀ ਸਹੀ ਕਿਸਮ ਦੇ ਯੂਜ਼ਰਾਂ ਵੱਲੋਂ ਅਤੇ ਇੱਕੋ ਕਾਰਨ ਲਈ। ਇਕ ਉੱਚ ਆਵਾਜ਼ ਵਾਲਾ ਯੂਜ਼ਰ ਤੁਹਾਨੂੰ ਗਲਤ ਦਿਸ਼ਾ ਵੱਲ ਖਿੱਚ ਸਕਦਾ ਹੈ। ਦੁਹਰਾਏ ਸੰਕੇਤਾਂ ਅਤੇ ਰੋਮਾਂਚਕ ਵਿਚਾਰਾਂ ਤੋਂ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ।

ਜੇ ਤਿੰਨ ਭੁਗਤਾਨ ਕਰਨ ਵਾਲੇ ਯੂਜ਼ਰ ਇੱਕ ਸਧਾਰਨ export flow ਮੰਗਦੇ ਹਨ, ਤਾਂ ਉਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਜੇ ਇੱਕ ਵਿਅਕਤੀ ਪੰਜ advanced settings ਮੰਗਦਾ ਹੈ ਜੋ ਹੋਰ ਕਿਸੇ ਨੇ ਨਹੀਂ ਪੁੱਛੀਆਂ, ਤਾਂ ਉਹ ਰੁਕ ਸਕਦੀ ਹੈ।

ਜੋ ਕੁਝ ਤੁਸੀਂ ਸਹਾਇਤਾ ਅਤੇ ਕੀਮਤ ਬਾਰੇ ਸਿੱਖਿਆ, ਉਹ ਨੋਟ ਕਰੋ ਜਦ ਤਕ ਯਾਦ ਤਾਜ਼ਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ ਜਵਾਬ ਕਿੱਥੇ ਮਿਲਿਆ? ਕਿਹੜੇ ਸਵਾਲ ਦੁਹਰਾਏ ਗਏ? ਕੀ ਕਿਸੇ ਨੇ ਕੀਮਤ 'ਤੇ ہچکچਾਓ ਕੀਤਾ, ਅਤੇ ਉਹ ਕਿਸ ਨਾਲ ਤੁਲਨਾ ਕਰ ਰਹੇ ਸਨ? ਐਸੇ ਨੋਟਸ ਯਾਦਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਫੈਸਲੇ ਲੈਣ 'ਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਮੁੱਖ ਫਲੋ ਸਥਿਰ ਮਹਿਸੂਸ ਹੋਣ ਤੱਕ ਪ੍ਰੋਡਕਟ ਸਧਾਰਨ ਰੱਖੋ। ਲੋਕਾਂ ਨੂੰ ਸਾਈਨਅਪ, ਮੁੱਖ ਕੰਮ ਪੂਰਾ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਸਮਝਣਾ ਬਿਨਾਂ ਮਦਦ ਦੇ ਕਰਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਉਹ ਰਸਤਾ ਅਜੇ ਵੀ ਢਿੱਲਾ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਹੋਰ ਫੀਚਰ ਆਮ ਤੌਰ 'ਤੇ ਹਾਲਤ ਨੂੰ ਬਦਤਰ ਬਣਾਉਂਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਇਕ ਚੰਗਾ ਪੜਾਅ ਹੈ ਛੋਟੀ, ਸੰਭਾਲਿਆ ਰਿਲੀਜ਼ ਕਰਨ ਲਈ। ਨਿਸ਼ਾਨਾ ਬਣਾਈਏ, ਯੂਜ਼ਰਾਂ ਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਵੇਖੋ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ snapshots ਵਰਤੋਂ ਤਾਂ ਜੋ ਸ਼ਿਪ ਅਤੇ ਰਿਕਵਰੀ ਸੁਰੱਖਿਅਤ ਰਹੇ।

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਮਹੀਨੇ ਇੱਕ ਤੋਂ ਬਾਅਦ ਘੱਟ ਬਣਾਉਣਾ ਜ਼ਿਆਦਾ ਉਪਯੋਗ ਹੁੰਦਾ ਹੈ, ਨਾਂ ਕਿ ਵੱਧ। ਨਰਮਾਂ ਨੂੰ ਸਾਫ਼ ਕਰੋ, ਸੁਣਦੇ ਰਹੋ, ਅਤੇ ਦੂਸਰੇ ਮਹੀਨੇ ਦਾ ਭਰੋਸਾ ਕਮਾਓ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਵੱਡੇ ਹੋਵੋ।