ਡੈਸਕਟਾਪ ਅਤੇ ਫੀਲਡ ਟੀਮਾਂ ਲਈ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਵਰਕਫਲੋ

ਇੱਕ ਸਾਂਝਾ ਵਰਕਫਲੋ ਅਕਸਰ ਕਿਉਂ ਫੇਲ ਹੁੰਦਾ ਹੈ

ਇੱਕ ਹੀ ਵਰਕਫਲੋ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਲਈ ਸੋਚਣ ਵਿੱਚ ਸੁਚੱਜਾ ਲੱਗਦਾ ਹੈ। ਹਕੀਕਤ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਦਾ ਹੈ।

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

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

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

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

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

ਡੈਸਕਟਾਪ 'ਤੇ ਕੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

ਡੈਸਕਟਾਪ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਲਈ ਉਚਿਤ ਹੈ:

• ਸ਼ੈਡਿਊਲਿੰਗ ਅਤੇ ਵਰਕਲੋਡ ਯੋਜਨਾ
• ਲੰਮੇ ਫਾਰਮ ਅਤੇ ਵਿਸਥਾਰਕ ਰਿਕਾਰਡ ਸੋਧਾਂ
• ਦਸਤਾਵੇਜ਼ ਅਤੇ ਰਿਪੋਰਟ ਸਮੀਖਿਆ
• ਭੂਮਿਕਾਵਾਂ, ਸੈਟਿੰਗਜ਼, ਅਨੁਮਤੀਆਂ ਅਤੇ ਆਡਿਟ ਇਤਿਹਾਸ

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

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

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

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

ਮੋਬਾਈਲ 'ਤੇ ਕੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

ਜੇ ਕਿਸੇ ਨੂੰ ਫੋਨ 'ਤੇ ਲੰਬੀਆਂ ਅਪਡੇਟ ਲਿਖਣੀਆਂ ਪੈਣ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਭਾਰੀ ਹੋ ਗਈ ਹੈ। ਚੈੱਕਬਾਕਸ, ਛੋਟੇ ਟੈਕਸਟ ਫੀਲਡ, ਮੌਕੇ 'ਤੇ ਆਵਾਜ਼ ਨੋਟ ਜੇ ਲੋੜ ਅਨੁਸਾਰ ਤੇ ਸਪਸ਼ਟ ਐਕਸ਼ਨ ਬਟਨ ਵਰਤੋ—ਜਿਵੇਂ Approve, Reject, Arrived, Delayed, ਜਾਂ Complete।

ਮੋਬਾਈਲ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਐਕਸ਼ਨ ਛੋਟੇ ਅਤੇ ਸਪਸ਼ਟ ਰਹਿਣ:

• ਤੇਜ਼ ਫੋਟੋ, ਨੋਟ ਅਤੇ ਦਸਤਖਤ ਕੈਪਚਰ
• ਇਕ ਜਾਂ ਦੋ ਟੈਪ ਨਾਲ ਸਥਿਤੀ ਅਪਡੇਟ
• ਸਪਸ਼ਟ ਲੇਬਲ ਵਾਲੀਆਂ ਛੋਟੀ ਮਨਜ਼ੂਰੀਆਂ
• ਸਿਰਫ਼ ਜਦੋਂ ਜਰੂਰੀ ਹੋਵੇ ਤਾਂ ਅਲਰਟ

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

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

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

ਅੰਤਿਮ ਨਤੀਜੇ ਤੋਂ ਫਲੋ ਨਕਸ਼ਾ ਬਣਾਓ

ਚੰਗਾ ਵਰਕਫਲੋ ਅੰਤ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਸਕ੍ਰੀਨ ਨਕਸ਼ਾ ਬਣਾਉਣ ਜਾਂ ਟਾਸਕ ਸੌਂਪਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ।

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

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

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

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

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

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

ਹੈਂਡਆਫ਼ਸ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ

ਵਰਕਫਲੋ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਹੈਂਡਆਫ਼ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ। ਜੇ ਲੋਕ ਅਗਲੇ ਕਦਮ ਦੇ ਮਾਲਕ ਬਾਰੇ unsure ਹਨ, ਕੰਮ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਤਾਰੀਖਾਂ ਦੇਰੀ ਨਾਲ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕੋ ਟਾਸਕ 'ਤੇ ਕਈ ਲੋਕ ਸੋਧ ਕਰਦੇ ਹਨ।

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

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

ਸਥਿਤੀ ਨਾਵੇ ਵੀ ਬਹੁਤ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਅਜਿਹੇ ਲੇਬਲ ਤੋਂ ਦੂਰ ਰਹੋ ਜੋ ਬਹੁਤ ਵਿਆਪਕ ਹਨ। ਹਰ ਸਥਿਤੀ ਲੋਕਾਂ ਨੂੰ ਦੱਸੇ ਕਿ ਕੀ ਹੋਇਆ ਹੈ ਅਤੇ ਅਗਲੇ ਕਦਮ ਵਾਂਗ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਸਥਿਤੀ ਫਲੋ ਇਹ ਹੋ ਸਕਦੀ ਹੈ:

• New request - ਦਫ਼ਤਰੀ ਟੀਮ ਰਿਕਾਰਡ ਦੀ ਸਮੀਖਿਆ ਕਰਦੀ ਹੈ
• Scheduled - تاریخ ਫਿਕਸ ਹੋਈ ਅਤੇ ਵਰਕਰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ
• On site - ਫੀਲਡ ਸਟਾਫ਼ ਪਹੁੰਚ ਕੇ ਕੰਮ ਸ਼ੁਰੂ ਕਰ ਚੁੱਕਾ ਹੈ
• Waiting approval - ਦਫ਼ਤਰ ਜਾਂ ਗਾਹਕ ਨੂੰ ਅਗਲਾ ਕਦਮ ਮਨਜ਼ੂਰ ਕਰਨਾ ਹੈ
• Complete - ਕੰਮ ਮੁਕੰਮਲ ਹੋ ਗਿਆ ਅਤੇ ਬਿਲਿੰਗ ਜਾਂ ਕਲੋਜ਼ਆਉਟ ਲਈ ਤਿਆਰ

ਸਹੀ ਸ਼ਬਦਚੋਣ ਤੋਂ ਜ਼ਿਆਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਹਰ ਕੋਈ ਉਹੀ ਮਾਇਨਾ ਸਮਝੇ।

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

ਇੱਕ ਸਧਾਰਨ ਫੀਲਡ ਸਰਵਿਸ ਉਦਾਹਰਣ

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

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

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

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

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

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

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

ਬਚੇ ਹੋਏ ਆਮ ਗਲਤੀਆਂ ਤੋਂ ਪਰੇ ਰਹੋ

ਜ਼ਿਆਦਾਤਰ ਵਰਕਫਲੋ ਸਮੱਸਿਆਵਾਂ ਇਸ ਕਾਰਨ ਆਉਂਦੀਆਂ ਹਨ ਕਿ ਦੋਨੋਂ ਡਿਵਾਈਸਾਂ ਨੂੰ ਇੱਕੋ ਕੰਮ ਕਰਨ ਲਈ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

ਹੋਰ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਡੈਸਕਟਾਪ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਵੱਖ-ਵੱਖ ਸਥਿਤੀ ਨਾਮ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਦਫ਼ਤਰ "Awaiting approval" ਵੇਖਦਾ ਹੈ ਪਰ ਐਪ 'ਚ "Pending review" ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਦ ਲੋਕ ਅਨੁਮਾਨ ਲਾਉਣ ਲਗਦੇ ਹਨ। ਸਾਂਝੇ ਲੇਬਲ ਅਹੰਕਾਰਕ ਹਨ ਕਿਉਂਕਿ ਹੈਂਡਆਫ਼ ਉਨ੍ਹਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

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

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

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

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

ਰੋਲਆਉਟ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈਕ

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

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

ਕੁਝ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਚੈੱਕ ਕਰੋ:

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

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

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

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

ਬਣਾਓ, ਪਰੀਖੋ, ਫਿਰ ਵਧਾਓ

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

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

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

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

ਅਸਲ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਬਦਲੋ। ਛੋਟੀਆਂ ਸੁਧਾਰ ਆਮਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਤਲਬ ਰੱਖਦੇ ਹਨ: ਇੱਕ ਛੋਟਾ ਫਾਰਮ, ਵੱਡਾ ਬਟਨ, ਘੱਟ ਲਾਜ਼ਮੀ ਫੀਲਡ ਜਾਂ ਸਪਸ਼ਟ ਸਥਿਤੀ ਲੇਬਲ।

ਹਰ ਟੈਸਟ ਰਾਊਂਡ ਨੂੰ ਛੋਟਾ ਰੱਖੋ—ਇੱਕ ਜਾਂ ਦੋ ਹਫ਼ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਪੈਟਰਨ ਪਛਾਣਨ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਫਲੋ ਰੱਖਣਾ ਹੈ, ਸੋਧਣਾ ਹੈ ਜਾਂ ਦੂਜੇ ਟੀਮ ਤੱਕ ਫੈਲਾਉਣਾ ਹੈ।

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

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