ਗਾਹਕ ਈਮੇਲਾਂ: ਐਪ ਦੀਆਂ ਅਸਲ ਲੋੜਾਂ ਸਮਝਣ ਲਈ

ਗਾਹਕ ਸੁਨੇਹੇ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਥਾਂ ਕਿਉਂ ਹਨ

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

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

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

ਕੁਝ ਸਿਗਨਲ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦੇ ਹਨ:

• ਇੱਕੋ ਸਮੱਸਿਆ ਵੱਖ-ਵੱਖ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੋਹਰਾਈ ਜਾ ਰਹੀ ਹੈ
• ਲੋਕ ਪਹਿਲਾਂ ਹੀ ਵਰਤ ਰਹੇ ਕੂਲ ਉਪਾਇਆ ਬਿਆਨ ਕਰਦੇ ਹਨ
• ਮੁੱਦਾ ਸਮਾਂ, ਪੈਸਾ, ਜਾਂ ਦੈਨੀਕ ਧਿਆਨ ਖਰਚ ਕਰਦਾ ਹੈ
• ਸੁਨੇਹਾ ਕਾਫ਼ੀ ਸੰਦਰਭ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਸਮਝ ਆ ਸਕੇ ਕਿ ਕੀ ਗਲਤ ਹੋਇਆ

ਇੱਕ ਈਮੇਲ ਦਿਲਚਸਪ ਹੋ ਸਕਦੀ ਹੈ। ਦਸ ਮਿਲਦੀਆਂ ਈਮੇਲਾਂ ਸਬੂਤ ਹੁੰਦੀਆਂ ਹਨ। ਦੋਹਰਾਈਆਂ ਬੇਨਤੀਆਂ ਤੁਹਾਨੂੰ ਉਸ ਸ਼ਰੀਕ ਗਾਹਕ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਿਰਮਿਮਤ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ ਜੋ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਅਵਾਜ਼ ਉਠਾਉਂਦਾ ਹੈ ਪਰ ਸਭ ਤੋਂ ਆਮ ਲੋੜ ਨਹੀਂ।

ਇਹ ਗੈਰ-ਟੈਕਨੀਕਲ ਫਾਊਂਡਰਾਂ ਲਈ ਖਾਸ ਕਰਕੇ ਲਾਭਦਾਇਕ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਐਪ ਦੀ ਸੰਰਚਨਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਕ ਖ਼ਰਾਬ ਵਿਚਾਰ ਉਸ ਵੇਲੇ ਜ਼ਿਆਦਾ ਮਜ਼ਬੂਤ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਅਸਲੀ ਸਪੋਰਟ ਥ੍ਰੈਡ ਜਾਂ ਇੰਟੇਕ ਨੋਟਾਂ ਨਾਲ ਸਮਰਥਿਤ ਹੁੰਦਾ ਹੈ। "CRM ਬਣਾਓ" ਕਹਿਣ ਦੀ ਬਜਾਏ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ: "ਉਹ CRM ਬਣਾਓ ਜੋ ਸਾਨੂੰ ਫਾਲੋਅਪ ਦੀ ਯਾਦ ਦਿਵਾਏ, ਕਲਾਇੰਟ ਕਾਲਾਂ ਨੂੰ ਲੌਗ ਕਰੇ, ਅਤੇ ਲੀਡਸ ਨੂੰ ਈਮੇਲ ਵਿੱਚ ਖੋਣ ਤੋਂ ਰੋਕੇ।"

ਇਹੀ ਗੱਲ ਹੈ ਜੋ ਗਾਹਕ ਸੁਨੇਹੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹਨ। ਉਹ ਇਕ ਅਧੂਰੇ ਵਿਚਾਰ ਨੂੰ ਉਸ ਸਮੱਸਿਆ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਜਿਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਤੁਸੀਂ ਅਸਲ ਤੌਰ 'ਤੇ ਬਣਾਉਂ ਸਕਦੇ ਹੋ।

ਯੋਜਨਾ ਬਣਾਉਣ ਤੋਂ ਪਿਹਲਾ ਕੀ ਇਕੱਤਰ ਕਰੋ

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

ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਸਮੱਗਰੀ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਥਾਵਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ: ਸਪੋਰਟ ਈਮੇਲ, ਸੇਲਜ਼ ਜਾਂ ਇੰਟੇਕ ਨੋਟਸ, ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਵੱਲੋਂ ਦੋਹਰਾਈਆਂ ਮੰਗਾਂ, ਅਤੇ ਉਹ ਸੁਨੇਹੇ ਜੋ ਵਰਕਅਰਾਉਂਡ, ਦੇਰੀਆਂ, ਰਹਿ ਗਏ ਕਦਮ ਜਾਂ ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਦਾ ਜਿਕਰ ਕਰਦੇ ਹਨ।

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

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

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

ਹਰ ਸੁਨੇਹੇ ਨਾਲ ਥੋੜਾ ਸੰਦਰਭ ਸਾਂਭੋ। ਲੇਖਕ ਕੌਣ ਸੀ, ਉਹ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ, ਇਹ ਕਿੰਨੀ ਵਾਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਾ ਕੀ ਸੀ—ਇਹ ਨੋਟ ਸਰਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ ਛੋਟੀ ਲਾਈਨ ਜਿਵੇਂ "ਛੋਟਾ ਏਜੰਸੀ, ਹਫਤਿਆਂਕ, ਬਿਲਿੰਗ ਵਿੱਚ ਦੇਰੀ" بعد ਦੀ ਯੋਜਨਾ ਬਹੁਤ ਆਸਾਨ ਕਰ ਦਿੰਦੀ ਹੈ।

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

ਇਨਬਾਕਸ ਵਿੱਚ ਪੈਟਰਨ ਕਿਵੇਂ ਪਛਾਣੋ

ਗਾਹਕ ਸੁਨੇਹਿਆਂ ਨੂੰ ਇੱਕ ਹੀ ਮਕਸਦ ਨਾਲ ਪੜ੍ਹੋ: ਦੋਹਰਾਈਆਂ ਲੱਭੋ।

ਇੱਕ ਇਕਲੋਤਾ ਗੁੱਸੇ ਵਾਲਾ ਈਮੇਲ ਤਤਕਾਲ ਮਹੱਤਵਪੂਰਣ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਚੰਗੇ ਉਤਪਾਦ ਫੈਸਲੇ ਪੈਟਰਨਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ। ਹਰ ਸੁਨੇਹੇ ਨੂੰ ਇੱਕ ਸੂਝ ਸਮਝੋ। ਤੁਸੀਂ ਅਜੇ ਪੂਰੇ ਫੀਚਰ ਵਿਚਾਰਾਂ ਦੀ ਖੋਜ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਦਰਦ ਨੂੰ ਵਾਰ-ਵਾਰ ਆਉਂਦਾ ਦੇਖ ਰਹੇ ਹੋ ਜਾਂ ਨਹੀਂ, ਇਹ ਵੇਖ ਰਹੇ ਹੋ।

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

ਇਕ ਸਧਾਰਨ ਟੈਗ ਸੈੱਟ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ:

• ਜਾਣਕਾਰੀ ਨਹੀਂ ਲੱਭ ਰਹੀ
• ਬਹੁਤ ਸਾਰੇ ਹੀ ਹੱਥੀ ਕਦਮ
• ਪਹੁੰਚ ਜਾਂ ਅਧਿਕਾਰ ਘੱਟ ਹਨ
• ਸਾਂਝਾ ਕਰਨ ਜਾਂ ਐਕਸਪੋਰਟ ਕਰਨਾ ਔਖਾ ਹੈ
• ਮੋਬਾਈਲ ਉਪਭੋਗ ਅਨੁਭਵ ਠੀਕ ਨਹੀਂ

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

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

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

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

ਪੈਟਰਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲੋ

ਜਦੋਂ ਤੁਸੀਂ ਸੁਨੇਹਿਆਂ ਨੂੰ ਗਰੁੱਪ ਕਰ ਲੈਂਦੇ ਹੋ, ਹਰ ਕਲੱਸਟਰ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਵਾਕ ਵਿੱਚ ਮਨੁੱਖੀ ਸਮਝ ਲਈ ਵਰਣਨ ਕਰੋ—ਸਮੱਸਿਆ ਨੂੰ, ਨ ਕਿ ਹੱਲ ਨੂੰ।

ਉਦਾਹਰਣ ਲਈ: "ਗਾਹਕ ਮੁਲਾਕਾਤਾਂ ਨੂੰ ਗੁਆ ਰਹੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਸਮੇਂ ਤੇ ਯਾਦ ਨਹੀਂ ਦਿਤੀ ਜਾਂਦੀ।"

ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮੱਸਿਆ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਵੀਖਾ ਸਕਦੇ, ਤਾਂ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਕਿ ਆਈਟਮ ਹਜੇ ਵੀ ਧੁੰਦਲਾ ਹੈ।

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

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

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

• ਸਟਾਫ਼ ਆਪਣੇ-ਆਪ ਅਗਾਂਹ ਯਾਦ ਦਿਵਾਉਣ ਭੇਜ ਸਕਦਾ ਹੈ
• ਸਟਾਫ਼ ਚੁਣ ਸਕਦਾ ਹੈ ਕਿ ਯਾਦ ਕਦੋਂ ਭੇਜੀ ਜਾਵੇ
• ਸਟਾਫ਼ ਵੇਖ ਸਕਦਾ ਹੈ ਕਿ ਯਾਦ ਭੇਜੀ ਗਈ ਸੀ ਜਾਂ ਨਹੀਂ
• ਯਾਦ ਉਹ ਸੰਪਰਕ ਵੇਰਵੇ ਵਰਤੇਗਾ ਜੋ ਪਹਿਲਾਂ ਬੁਕਿੰਗ ਵਿੱਚ ਸਾਂਭੇ ਗਏ ਹਨ

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

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

ਇੱਕ ਤੇਜ਼ ਟੈਸਟ ਮਦਦ ਕਰਦਾ ਹੈ:

• ਕੀ ਕੋਈ ਨਾ-ਟੈਕਨੀਕਲ ਟੀਮਮੈਂਬਰ ਇਸ ਨੂੰ ਸਮਝ ਸਕਦਾ ਹੈ?
• ਕੀ ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ?
• ਕੀ ਇਹ ਦੁਹਰਾਈ ਗਈ ਗਾਹਕ ਭਾਸ਼ਾ 'ਤੇ ਆਧਾਰਿਤ ਹੈ?
• ਕੀ ਇਸ ਨੂੰ ਹਟਾਉਣਾ ਵਰਜਨ ਇੱਕ ਨੂੰ ਘੱਟ ਉਪਯੋਗੀ ਕਰ ਦੇਵੇਗਾ?

ਜੇ ਚਾਰਾਂ ਦਾ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਸੰਭਵਤ: ਇੱਕ ਠੋਸ ਲੋੜ ਹੈ।

ਵਰਜਨ ਇੱਕ ਵਿੱਚ ਕੀ ਰੱਖਣਾ ਹੈ ਇਹ ਕਿਵੇਂ ਚੁਣੋ

ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਬੇਨਤੀਆਂ ਦੀ ਇੱਕ ਲਿਸਟ ਹੋਵੇ, ਅਗਲਾ ਕੰਮ ਹੋਰਾਂ ਨੂੰ ਨਾਹ ਕਹਿਣਾ ਹੈ।

ਇੱਕ ਚੰਗਾ ਪਹਿਲਾ ਵਰਜਨ ਪੂਰੇ ਉਤਪਾਦ ਦਾ ਛੋਟਾ ਨਕਲ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਸਭ ਤੋਂ ਛੋਟੀ ਸੁਧਾਰ ਹੈ ਜੋ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਮੁੱਖ ਦਰਦ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ ਲੋਕ ਭਾਰਤੀ ਤੌਰ 'ਤੇ ਵਾਰ-ਵਾਰ ਦਰਸਾ ਰਹੇ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਰੈਂਕਿੰਗ ਤਰੀਕਾ ਇੱਥੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ। ਚਾਰ ਗੱਲਾਂ ਤੇ ਦੇਖੋ:

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

ਵਧੀਆ ਵਰਜਨ ਇੱਕ ਆਈਟਮ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੇ ਤਿੰਨ 'ਤੇ ਵਧੀਆ ਸਕੋਰ ਕਰਦੇ ਹਨ ਅਤੇ ਚੌਥੇ 'ਤੇ ਮੈਨੇਜਬਲ ਰਹਿੰਦੇ ਹਨ।

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

ਇੱਕ ਕੇਂਦਰਿਤ ਵਰਜਨ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵੀ ਆਸਾਨੀ ਨਾਲ ਵਿਆਖਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ।

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

ਇਕ ਸਧਾਰਨ ਉਦਾਹਰਣ

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

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

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

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

ਇਸ ਲਈ ਵਰਜਨ ਇੱਕ ਛੋਟਾ ਰਹਿੰਦਾ ਹੈ:

• ਇੱਕ ਸੰਪਰਕ ਸੂਚੀ
• ਨੋਟ ਸੇਵ ਕਰਨ ਲਈ ਜਗ੍ਹਾ
• ਅਗਲੇ ਫੋਲੋਅਪ ਲਈ ਇੱਕ ਰਿਮਾਈਂਡਰ

ਇਹ ਪਰਯੋਗ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ।

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

ਇਸ ਨਾਲ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਉਸ ਦੁਹਰਾਈ ਦਰਦ 'ਤੇ ਕੇਂਦਰਿਤ ਰਹਿੰਦੀ ਹੈ ਜੋ ਅਸਲ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੱਤੀ।

ਜਿਹੜੀਆਂ ਗਲਤੀਆਂ ਪਹਿਲਾ ਬਿਲਡ ਧੁੰਦਲਾ ਕਰਦੀਆਂ ਹਨ

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

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

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

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

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

ਇੱਕ ਹੋਰ ਆਸਾਨ ਜਾਲ਼ ਹੈ ਕਿ ਮੁੱਖ ਕੰਮ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਐਡਜ ਕੇਸਾਂ ਜੋੜੇ ਜਾਂ। ਇਹ ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਲਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਪਹਿਲੇ ਉਪਭੋਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਐਪ ਨੂੰ ਇੱਕ ਹੀ ਗੱਲ 'ਤੇ ਅੰਕਿਤ ਕਰਦੇ ਹਨ: ਕੀ ਉਹ ਮੁੱਖ ਕੰਮ ਬਿਨਾਂ ਰੁਕਾਵਟ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ?

ਜੇ ਗਾਹਕ ਲਗਾਤਾਰ ਬੁਕਿੰਗ ਦੇ ਧੀਰੇ ਹੋਣ ਬਾਰੇ ਈਮੇਲ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਛੁੱਟੀਆਂ ਦੇ ਨਿਯਮ, ਜਟਿਲ ਮਨਜ਼ੂਰੀ ਚੇਨ, ਅਤੇ ਅਨੋਖੇ ਛੋਟੇ-ਮੋਟੇ ਕੇਸ ਪਹਿਲਾਂ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਪਹਿਲਾਂ ਬੁਕਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਓ।

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

ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਆਖਰੀ ਜਾਂਚ ਕਰੋ

ਬਣਾਉਣ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕੋ ਅਤੇ ਆਪਣੀ ਯੋਜਨਾ ਨੂੰ ਜੋ ਸਬੂਤ ਤੁਹਾਡੇ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਹੈ ਉਸ ਨਾਲ ਟੈਸਟ ਕਰੋ।

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

ਉਪਭੋਗਤਾ ਅਤੇ ਸਮੱਸਿਆ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਨਾਮ ਦਿਓ। "ਵਰਕਫਲੋ ਪ੍ਰਬੰਧਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਓ" ਨਾ ਲਿਖੋ। ਕੁਝ ਐਸਾ ਲਿਖੋ: "ਛੋਟੇ ਦੁਕਾਨ ਮਾਲਕ ਆਰਡਰ ਗੁਆ ਰਹੇ ਹਨ ਕਿਉਂਕਿ ਬੇਨਤੀਆਂ ਈਮੇਲ ਧਾਰਿਆਂ ਵਿੱਚ ਦਬ ਜਾਂਦੀਆਂ ਹਨ।"

ਹਰ ਫੀਚਰ ਨੂੰ ਇੱਕ ਦਰਦ ਨਾਲ ਜੋੜੋ। ਜੇ ਕੋਈ ਫੀਚਰ ਸਿਰਫ਼ ਇਸ ਲਈ ਹੈ ਕਿ ਇਹ ਪ੍ਰਭਾਵਸ਼ালী ਲੱਗਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਕੱਟੋ।

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

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

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

ਪੈਟਰਨ ਮਿਲਣ ਤੋਂ ਬਾਅਦ ਕੀ ਕਰੋ

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

ਇਹ ਇੰਨਾ ਹੀ ਸਧਾਰਨ ਹੋ ਸਕਦਾ ਹੈ: "ਨਵੇਂ ਗ੍ਰਾਹਕ ਲਗਾਤਾਰ ਪੁੱਛ ਰਹੇ ਹਨ ਕਿ ਇਨਵਾਇਸ ਕਿੱਥੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸਪੋਰਟ ਬਹੁਤ ਸਮਾਂ ਏਹੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਵਿੱਚ ਖਰਚ ਕਰਦਾ ਹੈ।"

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

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

ਉਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਦੱਸੇਗਾ ਕਿ ਕੀ ਕਮੀ ਹੈ, ਕੀ ਬੇਲੋੜੀ ਹੈ, ਅਤੇ ਕੀ ਕਾਗਜ਼ 'ਤੇ ਚੰਗਾ ਲੱਗਿਆ ਪਰ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦਾ।

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

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

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