48 ਘੰਟਿਆਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾਲ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ

48 ਘੰਟਿਆਂ ਵਿੱਚ ਕੀ ਸਿੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ

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

3 ਤੋਂ 6 ਸੈਸ਼ਨਾਂ ਨਾਲ, ਜੇ ਤੁਸੀਂ ਸਕੋਪ ਸੀਮਾ ਰੱਖਦੇ ਹੋ ਤਾਂ ਬਹੁਤ ਕੁਝ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਸੰਪੂਰਨ ਅੰਕੜੇ ਨਹੀਂ ਮਿਲਣਗੇ, ਪਰ ਤੁਹਾਨੂੰ ਉਹ ਦੁਹਰਾਏ ਪੈਟਰਨ ਮਿਲਣਗੇ ਜੋ ਤੁਸੀਂ ਇਸ ਹਫਤੇ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।

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

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

ਕਿਸੇ ਨੂੰ ਵੀ ਸ਼ਡਿਊਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਿੰਗਲ ਲਕ਼ਸ਼ ਨਿਰਧਾਰਿਤ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਫਾਰਮੈਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: “ਕੀ ਪਹਿਲੀ ਵਾਰੀ ਵਾਲਾ ਉਪਭੋਗਤਾ X ਨੂੰ Y ਮਿੰਟਾਂ ਵਿੱਚ ਬਿਨਾਂ ਮਦਦ ਦੇ ਕਰ ਸਕਦਾ ਹੈ?” ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਰਲ CRM ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: “ਕੀ ਇੱਕ ਨਵਾਂ ਯੂਜ਼ਰ ਇੱਕ ਸੰਪਰਕ ਜੋੜ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਟੈਗ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਵਾਪਸ ਲੱਭ ਸਕਦਾ ਹੈ?”

ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਪ੍ਰੋਟੋਟਾਈਪ तेज਼ੀ ਨਾਲ ਕਿਸੇ ਟੂਲ ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਬਣਾਇਆ ਹੈ, ਤਾ ਲਕ਼ਸ਼ ਉਹੀ ਰਹਿੰਦਾ ਹੈ: ਇੱਕ ਫਲੋ ਚੁਣੋ, ਅਸਲੀ ਲੋਕਾਂ ਨੂੰ ਦੇਖੋ ਉਹ ਕੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਿਲਕੁਲ ਦਰਸਾਓ ਕਿ ਕੀ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।

ਤੰਗ ਲਕ਼ਸ਼ (ਤਾਂ ਜੋ ਇੰਟਰਵਿਊ ਫੋਕਸ ਰਹਿਣ)

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

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

ਇੱਕ ਦੇਖਣ ਯੋਗ ਸਫਲਤਾ ਸੰਕੇਤ ਚੁਣੋ

ਕਿਸੇ ਨਾਲ ਗੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਮਾਪੋਂਗੇ। ਇਸਨੂੰ ਸੈਸ਼ਨ ਦੌਰਾਨ ਸਾਦਾ ਅਤੇ ਦਿੱਖ-ਯੋਗ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਇਹ ਸਮਾਂ (ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ), ਘਰੜ (ਕਿੰਨੀ ਵਾਰੀ ਉਹ ਫਸਦੇ ਹਨ ਜਾਂ “ਹੁਣ ਕੀ?” ਪੁੱਛਦੇ ਹਨ), ਨੈਵੀਗੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ (ਹਿਜੜ, ਮੁੜ-ਪੜ੍ਹਨਾ, ਵਾਪਸੀ), ਅਤੇ ਭਰੋਸੇ ਦੇ ਸੰਕੇਤ (ਭੁਗਤਾਨ, ਪ੍ਰਾਈਵੇਸੀ, ਜਾਂ ਐਰਰ ਬਾਰੇ ਚਿੰਤਾ) ਦਾ ਮਿਸ਼ਰਣ ਹੁੰਦਾ ਹੈ।

ਫਿਰ 3 ਤੋਂ 5 ਸਵਾਲ ਲਿਖੋ ਜੋ ਰਾਊਂਡ ਦੇ ਅੰਤ ਤੱਕ ਜਰੂਰੀ ਹੋਣਗੇ। ਉਦਾਹਰਣ:

• ਲੋਕ ਇਸ ਫਲੋ ਨੂੰ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ?
• ਕਿਹੜੀ ਸਕ੍ਰੀਨ ਪਹਿਲੀ ਅਸਲੀ ਗੁੰਝਲ ਪੈਦਾ ਕਰਦੀ ਹੈ?
• ਕਿਹੜਾ ਸ਼ਬਦ ਉਨ੍ਹਾਂ ਨੂੰ ਅਨਿਸ਼ਚਿਤ ਬਣਾ ਦਿੰਦਾ ਹੈ?
• ਉਹ ਕੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਪ੍ਰੋਟੋਟਾਈਪ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰਦਾ?
• ਕਿਹੜੀ ਚੀਜ਼ ਉਨ੍ਹਾਂ ਨੂੰ “ਹਾਂ, ਮੈਂ ਇਹ ਵਰਤਾਂਗਾ” ਕਹਿਣ ਲਈ ਤਿਆਰ ਕਰੇਗੀ?

ਰੋਕ ਨਿਯਮ ਲਗਾਓ

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

ਉਦਾਹਰਣ: ਜੇ ਪੰਜ ਵਿੱਚੋਂ ਤਿੰਨ ਭਾਗੀਦਾਰ “Create invoice” ਨਹੀਂ ਲੱਭ ਸਕਦੇ ਕਿਉਂਕਿ ਇਹ “Billing” ਹੇਠਾਂ ਛੁਪਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਪਸ਼ਟ ਬਿਲਡ ਬੇਨਤੀ ਹੈ: ਲੇਬਲ ਨੂੰ ਰੀਨੇਮ ਕਰੋ, ਐਂਟਰੀ ਪੋਇੰਟ ਨੂੰ ਸਥਾਨਾਂਤਰਿਤ ਕਰੋ, ਅਤੇ ਉਸ ਇੱਕ ਬਦਲਾਅ ਨੂੰ ਫਿਰ-ਟੈਸਟ ਕਰੋ।

48 ਘੰਟਿਆਂ ਦੀ ਯੋਜਨਾ (ਸਧਾਰਨ ਅਤੇ ਹਕੀਕਤੀ)

ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ ਸਪ੍ਰਿੰਟ ਵਾਂਗ ਵਰਤੋਂ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਵਰਤਣ ਯੋਗ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਚਲਾ ਸਕਦੇ ਹੋ: ਭਰਤੀ ਕਰੋ, ਤਿਆਰੀ ਕਰੋ, ਚਲਾਓ, ਫਿਰ ਤਾਜ਼ਾ ਯਾਦਾਂ ਦੇ ਹੋਣ ਤੇ ਸੁੰਞਾ ਕਰੋ। 3 ਤੋਂ 5 ਸੈਸ਼ਨਾਂ ਲਈ ਟਾਰਗਟ ਕਰੋ। ਤਿੰਨ ਘੱਟੋ-ਘੱਟ ਹਨ ਤਾਕਿ ਸਭ ਤੋਂ ਵੱਡੇ ਸਮੱਸਿਆਂ ਨੂੰ ਨੋਟ ਕੀਤਾ ਜਾ ਸਕੇ; ਪੰਜ ਆਮ ਤੌਰ 'ਤੇ ਪੈਟਰਨ ਦਿਖਾਉਂਦੇ ਹਨ।

ਇੱਕ ਹਕੀਕਤੀ ਯੋਜਨਾ ਇੰਝ ਦਿਖਦੀ ਹੈ:

• ਘੰਟੇ 0-4: ਆਪਣੇ ਇੱਕ-ਵਾਕ ਲਕ਼ਸ਼ ਨੂੰ ਲਿਖੋ, 2 ਤੋਂ 4 ਟਾਸਕ ਚੁਣੋ, ਇੱਕ ਛੋਟਾ ਨਿਮੰਤਰਣ ਸੁਨੇਹਾ ਤਿਆਰ ਕਰੋ, ਅਤੇ ਭਰਤੀ ਸ਼ੁਰੂ ਕਰੋ।
• ਘੰਟੇ 4-12: ਸਲਾਟ ਬੁੱਕ ਕਰੋ, ਫਿੱਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਸਹਿਮਤੀ ਲਵੋ, ਅਤੇ ਇੱਕ ਤਜ਼ਕਰਾ ਪ੍ਰੋਟੋਟਾਈਪ ਜਾਂਚ ਕਰੋ ਤਾਂ ਕਿ ਸਪੱਸ਼ਟ ਬਗ ਸੈਸ਼ਨ ਨੂੰ ਖਰੀਦ ਨਾ ਲੈ ਜਾਣ।
• ਘੰਟੇ 12-24: ਦੋ ਸੈਸ਼ਨ ਚਲਾਓ। ਹਰ ਇੱਕ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਪੰਜ ਮਿੰਟ ਦਾ ਸੰਖੇਪ ਲਿਖੋ: ਉਹਨਾਂ ਨੇ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਕਿੱਥੇ ਸੰਕੋਚ ਹੋਇਆ, ਉਹਨਾਂ ਨੇ ਕੀ ਉਮੀਦ ਕੀਤੀ।
• ਘੰਟੇ 24-36: ਇੱਕ ਤੋਂ ਤਿੰਨ ਹੋਰ ਸੈਸ਼ਨ ਚਲਾਓ। ਸਕ੍ਰਿਪਟ ਅਤੇ ਸੈਟਅਪ ਏਹੇ ਹੀ ਰੱਖੋ ਤਾਂ ਕਿ ਨਤੀਜੇ ਤੁਲਨਯੋਗ ਹੋਣ।
• ਘੰਟੇ 36-48: ਸੁੰਞਾ ਕਰੋ। ਨੋਟਸ ਨੂੰ ਥੀਮਾਂ ਵਿੱਚ ਕਲੱਸਟਰ ਕਰੋ, ਸਿਖਰ ਦੇ ਤਿੰਨ ਮੁੱਦਿਆਂ ਨੂੰ ਚੁਣੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬਦਲੋ।

ਜੇ ਭਰਤੀ ਢੀਲੀ ਹੋ ਰਹੀ ਹੈ ਤਾਂ ਉਡੀਕ ਨਾ ਕਰੋ। ਸਕੋਪ ਘਟਾਓ ਅਤੇ ਉਪਲਬਧਤਾ ਵਿਸਥਾਰੋ। ਹੋਰ ਸਮਾਂ-ਸਲਾਟ ਦਿਓ (ਸਵੇਰੇ ਜਾਂ ਸ਼ਾਮ), ਸੈਸ਼ਨਾਂ ਨੂੰ 15 ਮਿੰਟ ਤੱਕ ਘਟਾਓ, ਜਾਂ ਨੇੜਲੇ ਸਰਕਲ ਤੋਂ ਭਰਤੀ ਕਰੋ ਜੋ ਫਿਰ ਵੀ ਤੁਹਾਡੇ ਟਾਰਗੇਟ ਯੂਜ਼ਰ ਨੂੰ ਮਿਲਦਾ ਹੋਵੇ।

ਮਾਮਲਿਆਂ ਨੂੰ ਠੀਕ-ਠਾਕ ਰੱਖਣ ਲਈ, ਪਹਿਲੀ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਫੋਲਡਰ ਸਿਸਟਮ ਬਣਾ ਲਵੋ:

• 01_Recruiting
• 02_Recordings
• 03_Notes
• 04_Synthesis
• 05_Tickets

ਫਾਇਲਾਂ ਦੇ ਨਾਮ ਜਿਵੇਂ P01_2026-01-16_Record.mp4 ਅਤੇ P01_Notes.md ਰੱਖੋ। ਇਹ ਛੋਟੀ ਆਦਤ ਪ੍ਰੋਟੋਟਾਈਪ ਯੂਜ਼ਬਿਲਟੀ ਟੈਸਟਿੰਗ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵੇਖਣ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।

ਤੇਜ਼ੀ ਨਾਲ ਭਰਤੀ ਕਰੋ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਸੋਚੇ-ਬਚਾਰੇ

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

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

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

ਜੇ ਤੁਸੀਂ ਫ੍ਰੀਲਾਂਸਰਾਂ ਲਈ ਇੱਕ ਸਧਾਰਣ ਅੰਦਰੂਨੀ CRM ਪ੍ਰੋਟੋਟਾਈਪ (ਉਦਾਹਰਣ ਲਈ Koder.ai ਵਿੱਚ) ਬਣਾਇਆ ਹੈ, ਤਾਂ ਦੋਹਾਂ “ਗੰਦੇ spreadsheet” ਯੂਜ਼ਰਾਂ ਅਤੇ ਜੋ ਪਹਿਲਾਂ CRM ਵਰਤ ਰਹੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਬੁਲਾਓ। ਇਹ ਮਿਕਸ ਤੁਹਾਡੇ ਨਾਲਫ਼ੀਡਬੈਕ ਨੂੰ ਸਿਰਫ ਪਾਵਰ ਯੂਜ਼ਰਾਂ ਤੋਂ ਆਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਅਤੇ ਬਹੁਤ ਨੇੜਲੇ ਦੋਸਤਾਂ 'ਤੇ ਹੀ ਨਿਰਭਰ ਨਾ ਰਹੋ—ਉਹ ਮਿੱਠਾ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ।

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

ਅੰਤ ਵਿੱਚ, ਬੈਕਅਪ ਬੁੱਕ ਕਰੋ। ਤੁਹਾਨੂੰ ਜ਼ਿਆਦਾ ਲੋਕ ਭਰਤੀਆਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ (ਉਦਾਹਰਨ: ਜਿੰਨੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਸ ਤੋਂ ਦੋ ਵੱਧ) ਕਿਉਂਕਿ ਕੋਈ-ਕੋਈ ਨੋ-ਸ਼ੋ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ਪਾਸੇ ਵਿੱਚ ਸਕਰੀਨ, ਸ਼ਡਿਊਲ ਅਤੇ ਸਹਿਮਤੀ ਇੱਕ ਹੀ ਵਾਰ ਲਵੋ

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

ਹਲਕੀ ਸਕ੍ਰੀਨਰ ਸਿਰਫ ਤਿੰਨ ਸਵਾਲ ਹੋ ਸਕਦਾ ਹੈ:

• ਤੁਸੀਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਹੱਲ ਕਰਨ ਲਈ ਕੀ ਵਰਤਦੇ ਹੋ (ਜਾਂ ਤੁਸੀਂ ਹੁਣ ਕੀ ਕਰਦੇ ਹੋ)?
• ਆਖਰੀ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸੀ ਤਾਂ ਕੀ ਹੋਇਆ?
• ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਢੰਗ ਨਾਲ ਵੇਰਵਾ ਕਰਦਾ ਹੈ: [ਤੁਹਾਡੇ ਟਾਰਗੇਟ ਰੋਲ], ਅਤੇ ਕਿਉਂ?

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

ਸ਼ਡਿਊਲਿੰਗ ਲਈ, ਕਸੇ ਬੰਦੋਬਸਤ ਰੱਖੋ: 30 ਮਿੰਟ ਸੈਸ਼ਨ ਅਤੇ 15 ਮਿੰਟ ਬਫਰ। ਬਫਰ ਵਿੱਚ ਤੁਸੀਂ ਸਾਫ ਨੋਟਸ ਲਿਖਦੇ ਹੋ, ਰਿਕਾਰਡਿੰਗ ਨਾਂ ਰੱਖਦੇ ਹੋ, ਅਤੇ ਪ੍ਰੋਟੋਟਾਈਪ ਰੀਸੈਟ ਕਰਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਕਾਲਾਂ ਬਿਨਾ ਬਫਰ ਸਧੇਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਨੋਟਸ ਘੱਟ ਗੁਣਵੱਤਾ ਵਾਲੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਪੈਟਰਨਾਂ ਮਿਸ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਸਹਿਮਤੀ ਇੱਕ ਛੋਟੀ ਸਨੇਹਕੀ ਹੋ ਸਕਦੀ ਹੈ: ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮੰਗੋ, ਦੱਸੋ ਕਿ ਨੋਟਸ ਉਤਪਾਦ ਸੁਧਾਰ ਲਈ ਵਰਤੇ ਜਾਣਗੇ, ਅਤੇ ਕੋਟਸ ਨੂੰ ਐਨੋਨੀਮਾਈਜ਼ ਕੀਤਾ ਜਾਵੇਗਾ ਜੇ ਸਾਂਝੇ ਕੀਤੇ ਜਾਣ। ਇੱਕ ਆਸਾਨ opt-out ਦਿਓ: ਉਹ ਰਿਕਾਰਡਿੰਗ ਲਈ ਨਾ ਕਹਿ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਹਸੀਂ ਨੋਟ ਲੈ ਲਵੋਗੇ।

ਇੱਕ ਸਾਦਾ ਪ੍ਰੀ-ਕਾਲ ਸੁਨੇਹਾ ਭੇਜੋ ਜਿਸ ਵਿੱਚ ਸਮਾਂ, ਉਮੀਦਿਤ ਲੰਬਾਈ, ਅਜੰਞਾ (5 ਮਿੰਟ ਇੰਟਰੋ, 20 ਮਿੰਟ ਟਾਸਕ, 5 ਮਿੰਟ ਰੈਪ-ਅਪ), ਅਤੇ ਉਹਨਾਂ ਦੀ ਲੋੜ (ਲੈਪਟੌਪ ਬਨਾਮ ਫੋਨ, ਲੌਗਿਨ ਜੇ ਲੋੜੀਂਦਾ, ਸ਼ਾਂਤ ਥਾਂ). ਇਹ “ਮੈਂ ਮੋਬਾਈਲ ਤੇ ਜੁੜਿਆ” ਵਾਲੇ ਆਚਜੇਕਟਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਪ੍ਰੋਟੋਟਾਈਪ ਟੈਸਟਿੰਗ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ।

ਪ੍ਰੋਟੋਟਾਈਪ ਤਿਆਰ ਕਰੋ ਤਾਂ ਕਿ ਸੈਸ਼ਨ ਡੇਰੈਲ ਨਾ ਹੋ ਜਾਣ

ਚੰਗਾ ਇੰਟਰਵਿਊ ਵੀ ਫਿਰ ਵੀ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਪ੍ਰੋਟੋਟਾਈਪ ਗੰਦਾ ਹੋਵੇ। ਲਕ਼ਸ਼ ਇੰਪ੍ਰੈਸ ਕਰਨ ਦਾ ਨਹੀਂ—ਉਹ ਹੈ ਕਿ ਉਹਨਾਂ ਲਈ ਟਾਸਕਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ ਬਿਨਾਂ ਉਡੀਕ ਦੇ ਜਾਂ ਤੁਹਾਡੀ ਵਿਆਖਿਆ ਦੀ ਲੋੜ ਪਏ।

ਪ੍ਰੋਟੋਟਾਈਪ ਛੋਟਾ ਰੱਖੋ। ਸਿਰਫ ਉਹ ਸਕ੍ਰੀਨ ਅਤੇ ਰਸਤੇ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਟਾਸਕ ਲਈ ਜ਼ਰੂਰੀ ਹਨ, ਅਤੇ ਬਾਕੀ ਛੁਪਾਓ। ਇੱਕ ਛੋਟਾ ਰਸਤਾ ਆਧੂਰੇ "ਫੁੱਲ ਐਪ" ਤੋਂ ਜ਼ਿਆਦਾ ਬਿਹਤਰ ਹੈ।

ਸਮੱਗਰੀ ਨੂੰ ਵਾਸਤਵਿਕ ਮਹਿਸੂਸ ਕਰਵਾਓ। Lorem ipsum ਦੀ ਥਾਂ ਵਿਸ਼ਵਾਸਯੋਗ ਕਾਪੀ ਅਤੇ ਡੇਟਾ ਰੱਖੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਿਤ ਹੋਣ। ਜੇ ਤੁਸੀਂ CRM ਫਲੋ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ 6-10 ਸੰਪਰਕਾਂ ਦੇ ਨਾਮ, ਕੰਪਨੀ ਅਤੇ ਕੁਝ ਨੋਟਸ ਦਿਖਾਓ। ਜੇ ਚੈੱਕਆਊਟ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਹਕੀਕਤੀ ਕ਼ੀਮਤਾਂ ਅਤੇ ਡਿਲਿਵਰੀ ਚੋਣਾਂ ਦਿਓ। ਨਕਲੀ ਪਰ ਨਿਰਧਾਰਿਤ ਹਕੀਕਤ ਤੋਂ ਜ਼ਿਆਦਾ ਚੰਗਾ ਹੈ।

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

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

ਕੈਪਚਰ ਟੂਲ ਚੁਣੋ ਪਹਿਲਾਂ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਨਾਲ ਗੱਲ ਕਰਦਿਆਂ ਹੋ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਕਾਲ ਰਿਕਾਰਡ ਕਰੋ, ਅਤੇ ਇੱਕ ਸਾਦਾ ਨੋਟਸ ਟੈਮਪਲੇਟ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਕਾਲਮ ਹੋਣ: Task, Observations (ਕੀ ਹੋਇਆ), ਅਤੇ Quotes (ਠੀਕ-ਠੀਕ ਸ਼ਬਦ)। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲੇ ਸੈਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲੈਣ ਨਾਲ ਦਿਨ ਦੌਰਾਨ ਅਣਚਾਹੇ ਬਦਲਾਅ ਵਾਪਸ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਰਹਿੰਦੀ ਹੈ।

ਅਜਿਹਾ ਟਾਸਕ ਸਕ੍ਰਿਪਟ ਲਿਖੋ ਜੋ ਸਪਸ਼ਟ ਸੰਕੇਤ ਦੇਵੇ

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

ਮੁੱਖ ਸਿਨਾਰਿਓ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਨਾਂ ਦਿਓ (ਉਦਾਹਰਣ: “ਮੈਂ ਆਪਣਾ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਸੈਟਅਪ ਕਰਕੇ ਇੱਕ ਟੀਮ-ਮੈਂਬਰ ਨੂੰ ਨਿਯੋਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ”)। ਫਿਰ ਟਾਸਕ ਚੁਣੋ ਜੋ ਉਹ ਮੋਹੜੇ ਦਰਸਾਉਂਦੇ ਹਨ ਜਿੱਥੇ ਫੇਲ੍ਹ ਹੋਣਾ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦਾਇਕ ਹੋਵੇ: ਪਹਿਲੀ ਵਾਰੀ ਸੈਟਅਪ, ਇੱਕ ਮੁੱਖ ਫੀਚਰ ਲੱਭਣਾ, ਅਤੇ ਇੱਕ ਮੈਨੀਫੁਲ ਕਾਰਵਾਈ ਪੂਰੀ ਕਰਨਾ।

ਇੱਕ ਸਧਾਰਨ ਸਕ੍ਰਿਪਟ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਉਂ ਸਕਦੇ ਹੋ

ਹਰ ਸੈਸ਼ਨ ਵਿੱਚ ਇੱਕੋ ਰਚਨਾ ਵਰਤੋਂ ਤਾਂ ਕਿ ਨਤੀਜੇ ਤੁਲਨਯੋਗ ਹੋਣ:

• Intro (1 min): “ਅਸੀਂ ਉਤਪਾਦ ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹਾਂ, ਤੁਹਾਨੂੰ ਨਹੀਂ। ਕਿਰਪਾ ਕਰਕੇ ਸੋਚ-ਵੋਇਸ ਕਰੋ।”
• Warm-up (2 min): “ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਇਹ ਉਤਪਾਦ ਤੁਹਾਡੀ ਸਹਾਇਤਾ ਕਿਵੇਂ ਕਰੇਗਾ?”
• Tasks (20-25 min): 2 ਤੋਂ 4 ਟਾਸਕ, ਇੱਕ ਵਾਰੀ 'ਤੇ ਇੱਕ।
• Wrap-up (3 min): ਇੱਕ ਛੋਟੀ ਰੇਟਿੰਗ ਅਤੇ ਇੱਕ ਸੁਝਾਅ ਜੋ ਉਹ ਬਦਲਨਾ ਚਾਹੁੰਦੇ ਹਨ।

ਹਰ ਟਾਸਕ ਪ੍ਰਾਂਪਟ ਐਸਾ ਲਿਖੋ ਕਿ ਇਹ ਬਟਨ ਦਾ ਨਾਂ ਜਾਂ ਸਟੀਪ-ਬਾਈ-ਸਟੀਪ ਪਾਥ ਨਹੀਂ ਦੱਸੇ। ਮਿਸਾਲ: ਮਾੜਾ: “Click Snapshots and roll back.” ਚੰਗਾ: “ਤੁਸੀਂ ਇੱਕ ਗਲਤੀ ਕੀਤੀ ਅਤੇ ਕੱਲ੍ਹ ਦੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਮੈਨੂੰ ਦਿਖਾਓ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ।”

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

ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਟੋਟਾਈਪ Koder.ai ਵਿੱਚ ਬਣਾਇਆ ਹੈ, ਤਾਂ ਟਾਸਕਾਂ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜੋ (ਐਪ ਬਣਾਓ, ਸੋਰਸ ਕੋਡ ਇਕਸਪੋਰਟ ਕਰੋ, ਕਸਟਮ ਡੋਮੇਨ ਸੈੱਟ ਕਰੋ) ਤਾਕਿ ਤੁਹਾਡੇ ਨੋਟ ਸਾਫ਼-ਸੁਥਰੇ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬਦਲੇ ਜਾ ਸਕਣ।

ਸੈਸ਼ਨ ਚਲਾਓ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖੋ

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

ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਨਾਲ ਖੋਲ੍ਹੋ: ਧੰਯਵਾਦ ਕਰੋ, ਵਾਰ्ता ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਤਪਾਦ ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ (ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ), ਅਤੇ ਕੋਈ ਗਲਤ ਜਵਾਬ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਸੋਚ-ਵੋਇਸ ਕਰਨ ਲਈ ਕਹੋ ਅਤੇ ਤੁਸੀਂ ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਦੀ ਉਮੀਦ ਸੁਣੋ।

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

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

ਫੀਚਰ ਰਿਕਵੈਸਟ ਉਪਯੋਗੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ 'ਤੇ ਬਹਿਸ ਨਾ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਇਕ ਸਵਾਲ ਨਾਲ ਪਾਰੱਕ ਕਰੋ: “ਉਹ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰੇਗਾ?” ਫਿਰ ਮੌਜੂਦਾ ਟਾਸਕ 'ਤੇ ਵਾਪਸ ਆ ਜਾਓ।

ਨਿਰੰਤਰ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰੋ। ਪੁੱਛੋ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕੀ ਪਸੰਦ ਆਇਆ, ਕੀ ਨਿਰਾਸ਼ ਕੀਤਾ, ਕੀ ਉਹ ਭੁਗਤਾਨ ਕਰਨਗੇ (ਅਤੇ ਕੀ ਗੁਣ-ਘੱਟ ਮਹਿਸੂਸ ਹੋ ਰਿਹਾ), ਅਤੇ ਕਿ ਕੀ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਗਲੇ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਸੰਪਰਕ ਕਰ ਸਕਦੇ ਹੋ।

ਅਸਾਨ ਤਰੀਕੇ ਨਾਲ ਨੋਟਸ ਕੈਪਚਰ ਕਰੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸੁੰਞਣਯੋਗ ਹੋਣ

ਚੰਗੀਆਂ ਨੋਟਸ “ਜੋ ਕੁਝ ਵੀ ਹੋਇਆ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਛੋਟੇ, ਲਗਾਤਾਰ ਯੂਨਿਟ ਹੋਣਗੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਰ ਸਕੋ। ਜੇ ਤੁਸੀਂ ਸਾਰਿਆਂ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਓਹੀ ਬਣਤਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੀਜੇ ਇੰਟਰਵਿਊ ਦੇ ਬਾਅਦ ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਹੋ ਜਾਣਗੇ।

ਹਰ ਕਿਸੇ ਲਈ ਇੱਕ ਸਾਂਝੀ ਸ਼ੀਟ ਵਰਤੋਂ

ਇੱਕ ਨੋਟਸ ਡੌਕ ਜਾਂ ਸਪ੍ਰੈਡਸ਼ੀਟ ਪਿਕ ਕਰੋ ਜੋ ਹਰ ਨਿਰੀਖਣਕਾਰ ਵਰਤੇ। ਹਰ ਟਾਸਕ ਕੋਸ਼ਿਸ਼ ਲਈ ਇੱਕ ਕਤਾਰ ਬਣਾਓ ਅਤੇ ਹਰ ਵਾਰੀ ਛੋਟੇ, ਤੱਥ-ਅਧਾਰਿਤ ਨੋਟਸ ਉਨ੍ਹਾਂ ਹੀ ਥਾਵਾਂ ਤੇ ਲਿਖੋ। ਇੱਕ ਸਧਾਰਨ ਲੇਆਊਟ:

• ਟਾਈਮਸਟੈਂਪ (mm:ss) ਅਤੇ ਭਾਗੀਦਾਰ ID
• ਟਾਸਕ ਨੰਬਰ ਅਤੇ ਉਹ ਸਕ੍ਰੀਨ ਜਿਸ 'ਤੇ ਉਹ ਸਨ
• ਉਹਨਾਂ ਨੇ ਕੀ ਕੀਤਾ, ਉਹ ਕੀ ਉਮੀਦ ਕਰ ਰਹੇ ਸਨ, ਕੀ ਹੋਇਆ
• ਇੱਕ ਕੋਟ (ਸਿਰਫ ਜਦੋਂ ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੋਵੇ)
• ਟੈਗ: severity (high/med/low) + type

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

ਸਬੂਤ ਕੈਪਚਰ ਕਰੋ, ਰਾਏ ਨਹੀਂ

ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ, ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਾ ਵਾਕ ਲਿਖੋ ਜੋ ਕਿਸੇ ਟੀਮਮੇਟ ਨੂੰ ਬਿਨਾਂ ਸੰਦਰਭ ਦੇ ਸਮਝ ਆ ਸਕੇ। ਮੂਲ-ਵਿਆਖਿਆ ਨਾਂ ਲਿਖੋ।

ਉਦਾਹਰਣ: “T2 06:14: Clicked ‘Save’ expecting a confirmation, but nothing changed and they asked if it worked.”

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

ਟੈਗ ਛੋਟੇ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਫਿਲਟਰ ਕਰ ਸਕੋ:

• Severity: high (ਟਾਸਕ ਰੋਕਦਾ), med (ਉਨ੍ਹਾਂ ਨੂੰ ਧੀਰਾ ਕਰਦਾ), low (ਚਿੱਪੜ)
• Type: confusion, trust, missing, bug

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

ਅੰਤਿਮ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਨੋਟ ਨੂੰ ਟਿਕਟ ਸਿਰਲੇਖ ਵਿੱਚ ਬਦਲ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਦੁਬਾਰਾ ਲਿਖੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਕਰ ਨਾ ਸਕੋ।

ਫੀਡਬੈਕ ਨੂੰ ਸਪਸ਼ਟ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬਦਲੋ

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

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

ਹਰ ਮੁੱਦੇ ਲਈ ਇੱਕ ਸਧਾਰਨ ਬੇਨਤੀ ਫਾਰਮੈਟ ਵਰਤੋਂ:

• Problem: ਯੂਜ਼ਰ ਜੋ ਨਹੀਂ ਕਰ ਸਕੇ (ਇੱਕ ਵਾਕ)
• Evidence: ਸੱਟਾ ਨਿਰੀਖਣ ਜਾਂ ਕੋਟ + ਕਿੱਥੇ ਹੋਇਆ
• Impact: ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ (ਘਟਿਆ ਸਮਾਂ, ਗੁੰਝਲ, ਡਰੌਪ-ਆਫ, ਗਲਤ ਡੇਟਾ)
• Proposed change: UI ਜਾਂ ਫਲੋ ਵਿੱਚ ਕੀ ਬਦਲਣਾ
• Acceptance check: ਅਗਲੇ ਟੈਸਟ ਵਿੱਚ ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਂਗੇ ਕਿ ਇਹ ਠੀਕ ਹੋ ਗਿਆ ਹੈ

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

ਫਿਰ ਹਰ ਮੁੱਦੇ 'ਤੇ ਫੈਸਲਾ ਕਰੋ: ਹੁਣੀ ਫਿਕਸ ਕਰੋ, ਫਿਰ-ਟੈਸਟ ਕਰੋ, ਜਾਂ ਬਾਅਦ ਲਈ ਪਾਰਕ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਆਰਡਰਿੰਗ ਤਰੀਕਾ ਹੈ: ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ, ਕੋਸ਼ਿਸ਼ (ਇਫੋਰਟ), ਵਿਸ਼ਵਾਸ (ਕੀ ਇਹ ਦੁਹਰਾਇਆ ਗਿਆ?), ਅਤੇ ਅਗਲਾ ਕਾਰਵਾਈ (build, re-test, park)।

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

ਉਦਾਹਰਣ: ਪੰਜ ਇੰਟਰਵਿਊ ਜੋ ਪੰਜ ਕਾਰਵਾਈ ਯੋਗ ਟਿਕਟਾਂ ਬਣ ਜਾਂਦੇ ਹਨ

ਇੱਕ ਗੈਰ-ਟੈਕਨਿਕਲ ਫਾਊਂਡਰ ਨੇ Koder.ai ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ CRM ਆਨਬੋਰਨਿੰਗ ਫਲੋ ਬਣਾਇਆ, ਫਿਰ ਅਗਲੇ ਦਿਨ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਚਲਾਏ। ਲਕ਼ਸ਼ ਤੰਗ ਸੀ: ਕੀ ਇੱਕ ਸੇਲਜ਼ ਰੈਪ “ਪਹਿਲਾ ਡੀਲ ਬਣਾਇਆ” ਬਿਨਾਂ ਮਦਦ ਦੇ ਕਰ ਸਕਦਾ ਹੈ।

ਭਰਤੀ ਤੇਜ਼ ਸੀ: ਉਹਨਾਂ ਨੇ ਆਪਣੀ ਨੈਟਵਰਕ ਅਤੇ ਕੁਝ ਲੋਕੀ ਸੇਲਜ਼ ਕਮਿਊਨਿਟੀਆਂ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜਿਆ, ਛੋਟਾ ਗਿਫਟ ਕਾਰਡ ਦिता। ਪੰਜ ਸੇਲਜ਼ ਰੈਪ ਨੇ ਇਕ ਦੁਪਹਿਰ ਵਿੱਚ 20-ਮਿੰਟ ਸਲਾਟ ਬੁੱਕ ਕੀਤੇ।

ਹਰ ਸੈਸ਼ਨ ਇੱਕੋ ਤਿੰਨ ਟਾਸਕ ਵਰਤਦਾ, ਸ਼ਬਦ-ਬ-ਸ਼ਬਦ ਪੜ੍ਹੇ:

• ਛੋਟੀ ਸੰਪਰਕ ਸੂਚੀ ਲਿਆਓ (CSV ਜਾਂ ਕਾਪੀ-ਪੇਸਟ)
• ਇੱਕ ਸੰਪਰਕ ਲਈ ਪਹਿਲਾ ਡੀਲ ਬਣਾਓ ਅਤੇ ਉਸਨੂੰ ਅਗਲੇ ਸਟੇਜ ਵਿੱਚ ਲਿਜਾਓ
• ਕੱਲ ਸਵੇਰ 9:00 ਲਈ ਫਾਲੋ-ਅਪ ਰੀਮਾਈਂਡਰ ਸੈੱਟ ਕਰੋ

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

ਦਿਨ ਦੇ ਅੰਤ ਤੱਕ, ਉਹ ਨਿਰੀਖਣ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਅਜੇਹੀਆਂ ਬਣ ਗਈਆਂ:

• ਖਾਲੀ ਸਟੇਟ ਤੇ “Import contacts” ਬਟਨ ਸ਼ਾਮਲ ਕਰੋ। Acceptance: ਪਹਿਲੀ ਸਕਰੀਨ 'ਤੇ ਦਿੱਖਵਾਂ; CSV ਅਪਲੋਡ ਅਤੇ ਪੇਸਟ ਸਹਾਇਤਾ।
• “Reminder” ਨੂੰ ਹਰ ਜਗ੍ਹਾ “Follow-up” ਨਾਲ ਰੀਨੇਮ ਕਰੋ। Acceptance: ਬਟਨ, ਮਾਡਲ ਟਾਈਟਲ, ਅਤੇ ਪੁਸ਼ਟੀ ਸੁਨੇਹੇ 'ਤੇ ਲੇਬਲ ਅਪਡੇਟ ਹੋਵੇ।
• ਇੱਕ ਡੀਫ਼ਾਲਟ ਪਾਈਪਲਾਈਨ ਆਟੋ-ਕ੍ਰੀਏਟ ਕਰੋ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਸਟੇਜ ਹੋਣ। Acceptance: ਨਵਾਂ ਖਾਤਾ “New, Contacted, Won” ਨਾਲ ਆਵੇ; ਯੂਜ਼ਰ ਪਿੱਛੇ ਤੋਂ ਸਪਾਦਨ ਕਰ ਸਕਦਾ ਹੈ।
• “Create deal” ਫਾਰਮ 'ਤੇ inline help text ਜੋੜੋ। Acceptance: “Deal name” ਹੇਠਾਂ ਇੱਕ ਵਾਕ ਦਾ ਉਦਾਹਰਣ; ਖਾਲੀ ਸਬਮਿਸ਼ਨ ਘੱਟ ਹੋਣ।
• ਹਰ ਟਾਸਕ ਦੇ ਬਾਅਦ ਸਫਲਤਾ ਬੈਨਰ ਦਿਖਾਓ ਜੋ ਅਗਲਾ ਕਦਮ ਸੁਝਾਏ। Acceptance: ਇम्पੋਰਟ ਤੋਂ ਬਾਅਦ “Create your first deal” ਦੀ ਸੁਝਾਅ; ਡੀਲ ਬਣਣ 'ਤੇ “Set a follow-up” ਦੀ ਸੁਝਾਅ।

ਇਹੀ ਮਕਸਦ ਹੈ: ਇਕੋ ਜਿਹੇ ਟਾਸਕ, ਦੁਹਰਾਏ ਪੈਟਰਨ, ਅਤੇ ਇੰਨੇ ਸਪਸ਼ਟ ਟਿਕਟ ਜਿੰਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਦਿਨ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕੇ।

ਆਮ ਫੈੰਸਲੇ ਜੋ ਤੁਹਾਡੇ ਇੰਟਰਵਿਊਜ਼ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਖਰਾਬ ਨਤੀਜੇ ਕੁਝ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਨ ਕਿ ਪ੍ਰੋਟੋਟਾਈਪ ਸਵੈ-ਵਿੱਚ।

ਉਹ ਫੈੰਸਲੇ ਜੋ ਫੀਡਬੈਕ ਨੂੰ ਵਧੀਆ ਦਿਖਾਉਂਦੇ ਹਨ ਪਰ ਨਹੀਂ ਹੁੰਦੇ

ਲਿਡਿੰਗ ਸਵਾਲ ਜਿਵੇਂ “ਇਹ ਸਮਝ ਆਉਂਦਾ ਹੈ, ਹੈ ਨਾ?” ਨਰਮ ਸਹਿਮਤੀ ਲੈ ਲੈਂਦੇ ਹਨ। ਨਿਰਪੱਖ ਪ੍ਰੰਪਟ ਵਰਤੋਂ ਜਿਵੇਂ “ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਇਹ ਕੀ ਕਰਦਾ ਹੈ?” ਅਤੇ ਫਿਰ ਚੁੱਪ ਰਹੋ।

ਇੱਕ ਸੈਸ਼ਨ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਟੈਸਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਸਭ ਸਤਹੀ ਰਾਏਆਂ ਅਤੇ ਕਮਜ਼ੋਰ ਸੰਕੇਤ ਮਿਲਦੇ ਹਨ। 2-3 ਕੋਰ ਫਲੋਜ਼ ਚੁਣੋ।

ਮਧ-ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਬਦਲਣਾ ਤੁਲਨਯੋਗਤਾ ਤੋੜਦਾ ਹੈ। ਨਵੀਆਂ ਸੋਚਾਂ ਨੂੰ ਬੈਕਲੌਗ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਟਾਸਕ ਸਥਿਰ ਰੱਖੋ।

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

ਇੱਕ ਸਧਾਰਨ ਹਕੀਕਤ-ਚੈੱਕ: ਜੇ ਭਾਗੀਦਾਰ ਕਹਿ ਦਿੰਦਾ “ਵਧੀਆ ਲੱਗਦਾ ਹੈ” ਪਰ ਅਗਲਾ ਬਟਨ ਲੱਭਣ ਵਿੱਚ 90 ਸਕਿੰਟ ਲਗਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਕਰਵਾਈ ਅਸਲੀ ਡੇਟਾ ਹੈ। ਤਾਰੀਫ਼ ਸ਼ੋਰ ਹੈ।

ਨਤੀਜੇ ਦੀ ਵਿਆਖਿਆ ਵਕਤੋਂ ਜਾਣ ਵਾਲੀਆਂ ਫੈੰਸਲੇ

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

ਜੇ ਤੁਸੀਂ ਵੱਡੇ ਸੋਧ ਕਰਦੇ ਹੋ, ਤਾਂ ਜਲਦੀ ਤੋਂ ਰੀ-ਟੈਸਟ ਕਰੋ। ਦੋ ਛੋਟੀਆਂ ਸੈਸ਼ਨ ਵੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ

ਪਹਿਲੀ ਕਾਲ ਬੁੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਖ ਚੀਜ਼ਾਂ ਲਾਕ ਕਰੋ:

• ਇਸ ਰਾਊਂਡ ਲਈ ਲਕ਼ਸ਼ (ਇੱਕ ਵਾਕ)
• ਟਾਰਗੇਟ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ (ਕਿਸ ਲਈ ਹੈ, ਕਿਸ ਲਈ ਨਹੀਂ)
• ਸਕ੍ਰੀਨਰ ਸਵਾਲ + ਭਰਤੀ ਯੋਜਨਾ
• ਟਾਸਕ ਸਕ੍ਰਿਪਟ (2 ਤੋਂ 4 ਟਾਸਕ) + ਹਰ ਟਾਸਕ ਲਈ ਇੱਕ ਫਾਲੋ-ਅਪ ਸਵਾਲ
• ਪ੍ਰੋਟੋਟਾਈਪ ਰੀਸੈਟ ਯੋਜਨਾ (ਤਾਜ਼ਾ ਸਥਿਤੀ, ਟੈਸਟ ਡੇਟਾ)
• ਰਿਕਾਰਡਿੰਗ ਤਰੀਕਾ (ਅਤੇ ਬੈਕਅਪ) ਅਤੇ ਸਹਿਮਤੀ ਟੈਕਸਟ
• ਨੋਟਸ ਟੈਮਪਲੇਟ (issues, quotes, severity, evidence)

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

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

ਉਸੇ ਦਿਨ ਰੈਪ-ਅਪ (20 ਮਿੰਟ)

• Patterns: ਉਹ ਜੋ ਤੁਸੀਂ ਘੱਟੋ-ਘੱਟ ਦੋ ਵਾਰੀ ਵੇਖਿਆ
• Priorities: ਪਹਿਲੇ ਤਿੰਨ ਨੂੰ ਚੁਣੋ
• Next build steps: ਹਰ ਸਮੱਸਿਆ ਲਈ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਜੋ ਹੱਲ ਕਰ ਸਕੇ

ਫਿਰ ਫਿਕਸ ਸ਼ਿਪ ਕਰਨ ਤੋਂ 72 ਘੰਟਿਆਂ ਦੇ ਅੰਦਰ ਰੀ-ਟੈਸਟ ਦੀ ਸ਼ਡਿਊਲ ਬਣਾਓ। ਇੱਥੇ ਤਕ ਕਿ ਤਿੰਨ ਛੋਟੇ ਸੈਸ਼ਨ ਵੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਬਦਲਾਅ ਕੰਮ ਕਰ ਰਹੇ ਨੇ।

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਨਤੀਜੇ ਸਪੇਕਡ ਟਾਸਕਾਂ ਵਾਂਗ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ (“Change X so user can do Y without Z”), ਅਤੇ snapshots ਬਿਨਾ ਇੱਕ ਸਥਿਰ ਵਰਜ਼ਨ ਗੁਆਉਂਦੇ ਤੇਜ਼ੀ ਨਾਲ ਫਿਕਸ آزمਾਉਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।