ਸਟਾਫ ਦੇ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਬਿਜ਼ਨਸ ਐਪਾਂ ਲਈ ਅਸਲ ਵਰਗਾ ਟੈਸਟ ਡੇਟਾ

ਸਟਾਫ ਦੇ ਐਪ ਵਰਤਣ ਨਾਲ ਪਾਲਿਸ਼ ਕੀਤੇ ਡੈਮੋ ਕਿਉਂ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੇ ਹਨ

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

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

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

ਸਾਂਝੇ ਰਿਕਾਰਡ ਵਰਕਫਲੋ ਬਦਲ ਦਿੰਦੇ ਹਨ

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

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

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

ਟੈਸਟ ਡੇਟਾ ਨੂੰ ਅਸਲ ਜਾਣਕਾਰੀ ਤੋਂ ਵੱਖ ਰੱਖੋ

ਜਾਂਚ ਦੌਰਾਨ ਕਲਪਿਤ ਨਾਮ, ਈਮੇਲ ਪਤੇ, ਫ਼ੋਨ ਨੰਬਰ ਅਤੇ ਕੰਪਨੀ ਦੇ ਵੇਰਵੇ ਵਰਤੋ। ਰਿਕਾਰਡਾਂ 'ਤੇ ਸਪਸ਼ਟ ਨਿਸ਼ਾਨ ਲਗਾਓ, ਜਿਵੇਂ «TEST - Northside Supplies», ਤਾਂ ਜੋ ਕੋਈ ਉਨ੍ਹਾਂ ਨੂੰ ਅਸਲ ਗਾਹਕ ਨਾ ਸਮਝੇ। ਗਾਹਕ ਸੂਚੀਆਂ, ਕਰਮਚਾਰੀ ਰਿਕਾਰਡ, ਵਿੱਤੀ ਵੇਰਵੇ ਜਾਂ ਨਿੱਜੀ ਨੋਟ ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਾਪੀ ਨਾ ਕਰੋ।

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

ਸਟਾਫ ਦੇ ਅਸਲ ਕੰਮ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

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

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

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

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

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

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

ਚੰਗੇ ਸਿਨਾਰੀਓ ਦੀ ਇੱਕ ਸਪਸ਼ਟ ਸਮਾਪਤੀ ਹੁੰਦੀ ਹੈ। «ਗਾਹਕ ਦੇ ਵੇਰਵੇ ਅਪਡੇਟ ਕਰੋ» ਬਹੁਤ ਢਿੱਲਾ ਹੈ। «ਗਾਹਕ ਦਾ ਬਿਲਿੰਗ ਈਮੇਲ ਬਦਲੋ, ਰਿਕਾਰਡ ਸੇਵ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅਗਲਾ ਇਨਵੌਇਸ ਇਸੇ ਈਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ» ਟੈਸਟਰ ਨੂੰ ਜਾਂਚਣ ਲਈ ਖਾਸ ਚੀਜ਼ ਦਿੰਦਾ ਹੈ।

ਰਿਕਾਰਡਾਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਦੇ ਬਿਜ਼ਨਸ ਡੇਟਾ ਵਰਗਾ ਬਣਾਓ

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

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

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

ਅਸਲ ਵਰਗੇ ਕੁਝ ਪੈਟਰਨ ਅਕਸਰ ਸੈਂਕੜੇ ਇੱਕੋ ਜਿਹੀਆਂ ਐਂਟਰੀਆਂ ਨਾਲੋਂ ਵੱਧ ਦਿਖਾ ਦਿੰਦੇ ਹਨ:

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

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

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

ਟੀਮ ਨੂੰ ਸੱਦਣ ਤੋਂ ਪਹਿਲਾਂ ਯੂਜ਼ਰਾਂ ਅਤੇ ਅਨੁਮਤੀਆਂ ਦਾ ਮਾਡਲ ਬਣਾਓ

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

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

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

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

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

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

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

ਆਮ ਵਰਕਫਲੋ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਔਖੇ ਮਾਮਲਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਆਰਡਰ ਐਪ ਲਈ ਇੱਕ ਨਵਾਂ ਆਰਡਰ ਬਣਾਓ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਨਹੀਂ ਛੇੜਿਆ, ਇੱਕ ਉਹ ਜਿਸਨੂੰ ਸਟਾਫ ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੈ, ਇੱਕ ਮੈਨੇਜਰ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤਾ ਹੋਇਆ ਅਤੇ ਇੱਕ ਜੋ ਟੀਮ ਨੇ ਪਿਛਲੇ ਮਹੀਨੇ ਬੰਦ ਕੀਤਾ ਸੀ। ਹਰ ਪੜਾਅ 'ਤੇ ਵੇਖੋ ਕਿ ਸਟਾਫ ਕਿਹੜੇ ਫੀਲਡ ਬਦਲ ਸਕਦਾ ਹੈ। ਬੰਦ ਆਰਡਰ ਕਿਸੇ ਵੱਲੋਂ ਡਿਲਿਵਰੀ ਪਤਾ ਬਦਲਣ ਨਾਲ ਚੁੱਪਚਾਪ «in progress» ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ।

ਅਸਲ ਕੰਮ ਵਿੱਚ ਆਉਣ ਵਾਲੀਆਂ ਅਪਵਾਦ ਸਥਿਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰੋ:

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

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

ਜਦੋਂ ਬਾਅਦ ਵਿੱਚ ਸਵਾਲ ਉੱਠਣ, ਸਟੇਟਸ ਦਾ ਇਤਿਹਾਸ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਕ੍ਰਮ ਜਾਂਚੋ: Sam ਨੇ 9:10 ਵਜੇ ਬੇਨਤੀ ਬਣਾਈ, Priya ਨੇ 9:25 ਵਜੇ ਮਨਜ਼ੂਰ ਕੀਤੀ ਅਤੇ ਗਾਹਕ ਦੇ ਫ਼ੋਨ ਕਰਨ ਤੋਂ ਬਾਅਦ Sam ਨੇ 10:00 ਵਜੇ ਇਸਨੂੰ ਰੱਦ ਕੀਤਾ। ਬੇਨਤੀ ਦੀ ਪਹੁੰਚ ਵਾਲੇ ਸਟਾਫ ਨੂੰ ਹਰ ਬਦਲਾਅ ਕਰਨ ਵਾਲਾ ਵਿਅਕਤੀ, ਸਮਾਂ ਅਤੇ ਐਪ ਵੱਲੋਂ ਇਕੱਠਾ ਕੀਤਾ ਕਾਰਨ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੌਜੂਦਾ ਸਟੇਟਸ ਵੀ ਲੰਬੇ ਨੋਟਾਂ ਦਾ ਇਤਿਹਾਸ ਪੜ੍ਹੇ ਬਿਨਾਂ ਸਮਝ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਜਾਣਬੁੱਝ ਕੇ ਗਲਤ ਇਨਪੁਟ ਦਿਓ

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

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

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

ਐਪ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ। «ਘੱਟੋ-ਘੱਟ 10 ਅੰਕਾਂ ਵਾਲਾ ਫ਼ੋਨ ਨੰਬਰ ਦਰਜ ਕਰੋ» ਅਗਲਾ ਕਦਮ ਦੱਸਦਾ ਹੈ। «Validation error» ਨਹੀਂ ਦੱਸਦਾ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਸੁਨੇਹਾ ਫੀਲਡ ਦੇ ਨੇੜੇ ਰੱਖੋ ਅਤੇ ਯੂਜ਼ਰ ਵੱਲੋਂ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ ਵੀ ਇਸਨੂੰ ਦਿਖਾਈ ਦਿਓ।

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

ਰੋਕੀ ਗਈ ਸਬਮਿਸ਼ਨ ਤੋਂ ਬਾਅਦ ਅੱਗੇ ਵਧਣ ਦਾ ਸਪਸ਼ਟ ਰਸਤਾ ਹੋਵੇ: ਨਿਸ਼ਾਨ ਲੱਗੇ ਫੀਲਡ ਨੂੰ ਠੀਕ ਕਰੋ, ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਰੱਦ ਕਰੋ ਜਾਂ ਕੰਮ ਅਧੂਰਾ ਹੋਣ 'ਤੇ ਡਰਾਫਟ ਸੇਵ ਕਰੋ। ਐਸੇ ਗਲਤੀ ਪੌਪਅਪ ਤੋਂ ਬਚੋ ਜੋ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਗਾਇਬ ਹੋ ਜਾਵੇ ਜਾਂ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ ਬਟਨ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦੇਣ।

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

ਸਟਾਫ ਦੇ ਇੱਕ ਅਸਲ ਸਿਨਾਰੀਓ ਵਿੱਚੋਂ ਲੰਘੋ

ਕਲਪਨਾ ਕਰੋ ਕਿ 12 ਸਟਾਫ ਮੈਂਬਰਾਂ ਵਾਲੀ ਹੀਟਿੰਗ ਅਤੇ ਪਲੰਬਿੰਗ ਕੰਪਨੀ ਹੈ। ਇਹ ਇੱਕੋ ਐਪ ਵਿੱਚ ਗਾਹਕ, ਸਰਵਿਸ ਜੌਬ, ਇਨਵੌਇਸ ਅਤੇ ਭੁਗਤਾਨ ਟਰੈਕ ਕਰਦੀ ਹੈ।

Maya, ਆਫ਼ਿਸ ਮੈਨੇਜਰ, Jordan Lee ਦੀ ਲੀਕ ਕਰ ਰਹੀ ਰੇਡੀਏਟਰ ਬਾਰੇ ਕਾਲ ਲੈਂਦੀ ਹੈ। ਉਹ Jordan ਖੋਜਦੀ ਹੈ ਅਤੇ ਦੋ ਗਾਹਕ ਰਿਕਾਰਡ ਲੱਭਦੀ ਹੈ: «Jordan Lee» ਅਤੇ «J. Lee», ਦੋਵੇਂ ਇੱਕੋ ਪਤੇ 'ਤੇ। Maya ਇੱਕ ਰਿਕਾਰਡ ਚੁਣਦੀ ਹੈ, ਬੁੱਧਵਾਰ ਸਵੇਰ ਲਈ ਜੌਬ ਬਣਾਉਂਦੀ ਹੈ, ਦੱਸੀ ਗਈ ਸਮੱਸਿਆ ਲਿਖਦੀ ਹੈ ਅਤੇ ਟੈਕਨੀਸ਼ੀਅਨ Sam ਨੂੰ ਕੰਮ ਦਿੰਦੀ ਹੈ।

ਜੌਬ «Booked» ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। Sam ਪਤੇ 'ਤੇ ਆਪਣੇ ਫ਼ੋਨ ਤੋਂ ਐਪ ਖੋਲ੍ਹਦਾ ਹੈ। ਉਹ ਫ਼ੋਟੋ ਜੋੜਦਾ ਹੈ, ਸਟੇਟਸ «Work complete» ਕਰਦਾ ਹੈ ਅਤੇ ਪਾਰਟਸ ਤੇ ਮਜ਼ਦੂਰੀ ਦਰਜ ਕਰਦਾ ਹੈ। ਇਹ ਲੇਬਲ ਅੰਤਿਮ ਲੱਗਦਾ ਹੈ, ਪਰ ਐਪ ਵੱਲੋਂ ਇਨਵੌਇਸ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ Maya ਨੂੰ ਚਾਰਜ ਦੀ ਜਾਂਚ ਕਰਨੀ ਹੈ। ਸਟਾਫ «Work complete» ਨੂੰ «ਬਿੱਲ ਭੇਜਣ ਲਈ ਤਿਆਰ» ਸਮਝ ਸਕਦਾ ਹੈ, ਜਦਕਿ Sam ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਸਾਈਟ ਤੋਂ ਚਲਾ ਗਿਆ ਹੈ।

«Awaiting office review» ਵਰਗਾ ਵਧੇਰੇ ਸਪਸ਼ਟ ਸਟੇਟਸ ਵਰਤੋ। ਇਸ ਨਾਲ Maya ਨੂੰ ਅਗਲਾ ਕਦਮ ਪਤਾ ਰਹੇਗਾ ਅਤੇ ਕਿਸੇ ਵੱਲੋਂ ਕੀਮਤ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਐਪ ਇਨਵੌਇਸ ਨਹੀਂ ਭੇਜੇਗੀ।

Maya ਵੇਖਦੀ ਹੈ ਕਿ Jordan ਦਾ 45 ਦਿਨਾਂ ਤੋਂ ਬਕਾਇਆ ਪੁਰਾਣਾ ਇਨਵੌਇਸ ਵੀ ਹੈ। ਉਹ ਫ਼ੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਬਿੱਲ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਂ ਜੌਬ ਨੂੰ ਸੁਪਰਵਾਈਜ਼ਰ ਦੀ ਮਨਜ਼ੂਰੀ ਚਾਹੀਦੀ ਹੈ। ਉਸਦੀ ਸੁਪਰਵਾਈਜ਼ਰ Priya, Sam ਦੇ ਨੋਟ ਪੜ੍ਹਦੀ ਹੈ ਅਤੇ ਡਿਸਕਾਊਂਟ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਪਹਿਲੀ ਮੁਰੰਮਤ ਅਸਫਲ ਰਹੀ ਸੀ।

ਇਹ ਸਿਨਾਰੀਓ ਜਾਂਚਦਾ ਹੈ ਕਿ ਐਪ ਅਸਲ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੀ ਹੈ:

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

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

ਜੇ Sam ਆਪਣੇ ਫ਼ੋਨ ਤੋਂ ਡਿਸਕਾਊਂਟ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਅਨੁਮਤੀ ਨਿਯਮ ਠੀਕ ਕਰੋ। ਜੇ Maya ਨਹੀਂ ਸਮਝ ਸਕਦੀ ਕਿ «Work complete» ਦਾ ਮਤਲਬ ਬਿੱਲ ਭੇਜਣਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਸਾਈਟ 'ਤੇ ਕੰਮ ਮੁਕੰਮਲ ਹੋਣਾ, ਤਾਂ ਸਟਾਫ ਦੇ ਭਰੋਸੇ ਤੋਂ ਪਹਿਲਾਂ ਸਟੇਟਸ ਦਾ ਨਾਮ ਬਦਲੋ।

ਸਧਾਰਨ ਟੈਸਟ ਸੈਸ਼ਨ ਚਲਾਓ ਅਤੇ ਨਤੀਜੇ ਦਰਜ ਕਰੋ

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

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

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

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

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

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

ਪਹਿਲੇ ਸਟਾਫ ਰੋਲਆਉਟ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਜਾਂਚ ਕਰੋ

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

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

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

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

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

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

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

ਅਗਲੇ ਟੈਸਟਿੰਗ ਦੌਰ ਦੀ ਤਿਆਰੀ ਕਰੋ

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

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

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

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

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

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