ਆਡਿਟ ਇਤਿਹਾਸ: ਉਹ ਫੀਚਰ ਜਿਸ 'ਤੇ ਵਪਾਰਕ ਐਪ ਦੀਆਂ ਟੀਮਾਂ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ

ਕਿਉਂ ਬਦਲਾਅ ਦੇ ਰਿਕਾਰਡ ਨਾ ਹੋਣ ਨਾਲ ਰੋਜ਼ਾਨਾ ਗੁੰਝਲ ਪੈਦਾ ਹੁੰਦੀ ਹੈ

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

ਫਿਰ ਕੋਈ ਬੰਦਾ ਬਾਅਦ ਵਿੱਚ ਐਪ ਖੋਲ੍ਹਦਾ ਹੈ ਤੇ ਪੁੱਛਦਾ ਹੈ, "ਇਹ ਕੌਣ ਬਦਲਿਆ?"

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

ਇਹੇ ਸਵਾਲ ਲਗਭਗ ਹਰ ਟੀਮ ਵਿੱਚ ਆਉਂਦੇ ਹਨ:

• ਕੌਣ ਇਸ ਨੂੰ ਬਦਲਿਆ؟
• ਇਹ ਕਦੋਂ ਹੋਇਆ?
• ਪੁਰਾਣਾ ਮੁੱਲ ਕੀ ਸੀ?
• ਕੀ ਇਹ ਗਲਤੀ ਸੀ ਜਾਂ ਸੋਚ-ਸਮਝ ਕੇ ਕੀਤਾ ਗਿਆ?
• ਕੀ ਹੁਣ ਹੋਰ ਕੁਝ ਸਹੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ?

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

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

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

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

ਆਡਿਟ ਇਤਿਹਾਸ ਆਸਾਨ ਭਾਸ਼ਾ ਵਿੱਚ

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

ਇੱਕ ਉਪਯੋਗੀ ਆਡਿਟ ਇਤਿਹਾਸ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਚੀਜ਼ਾਂ ਰੱਖਦਾ ਹੈ:

• ਉਹ ਆਈਟਮ ਜਿਸ ਨੂੰ ਬਦਲਿਆ ਗਿਆ
• ਉਹ ਵਿਅਕਤੀ ਜਾਂ ਸਿਸਟਮ ਜਿਸ ਨੇ ਇਹ ਬਦਲਾਅ ਕੀਤਾ
• ਬਦਲਾਅ ਦਾ ਸਮਾਂ
• ਪੂਰਵ ਮੁੱਲ ਅਤੇ ਨਵਾਂ ਮੁੱਲ, ਜਦੋਂ ਇਸ ਦੀ ਮਹੱਤਤਾ ਹੋਵੇ

ਇਹੀ ਇਸਨੂੰ ਲਾਭਦਾਇਕ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਇਹ ਨੋਟ ਨਹੀਂ ਕਿ "ਕੁਝ ਹੋਇਆ।" ਇਹ ਇੰਨੀ ਵਿਸਥਾਰ ਦਿੰਦਾ ਹੈ ਕਿ ਕੋਈ ਅਸਲ ਵਿਅਕਤੀ ਰਿਕਾਰਡ ਦੀ ਕਹਾਣੀ ਨੂੰ ਫਾਲੋ ਕਰ ਸਕੇ।

ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਸੇਲਜ਼ ਆਰਡਰ ਦਾ ਡਿਲਿਵਰੀ ਡੇਟ ਗਲਤ ਹੋ ਗਿਆ। ਆਡਿਟ ਇਤਿਹਾਸ ਨਾਲ, ਮੈਨੇਜਰ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ Maya ਨੇ 12 ਜੂਨ ਤੋਂ 21 ਜੂਨ 'ਤੇ ਤਾਰੀਖ 3:14 PM 'ਤੇ ਬਦਲੀ। ਬਿਨਾਂ ਇਸਦੇ, ਟੀਮ ਕਾਲਪਨਿਕ ਹੋ ਕੇ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਖੋਜ ਕਰਦੀ।

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

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

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

ਸੁਧੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਆਡਿਟ ਇਤਿਹਾਸ ਐਪ ਦੀ ਯਾਦਸ਼ਤ ਹੈ। ਲੋਕ ਡੇਟਾ 'ਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਦੇਖ ਸਕਦੇ ਹਨ ਕਿ ਇਹ ਇੱਥੇ ਕਿਵੇਂ ਆਇਆ।

ਇੱਕ ਉਪਯੋਗੀ ਰਿਕਾਰਡ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਔਰਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਲੌਗ ਸ਼ੱਕਤ ਰੂਪ ਵਿੱਚ ਵਿਅਕਤੀ ਦਾ ਨਾਮ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਪੱਸ਼ਟ ਭੂਮਿਕਾ ਜਿਵੇਂ Sales Manager, Support Agent, ਜਾਂ System. "Changed by admin" ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਧੁੰਦਲਾ ਹੁੰਦਾ ਹੈ।

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

ਰਿਕਾਰਡ ਨੂੰ ਉਸ ਖਾਸ ਚੀਜ਼ ਦਾ ਨਾਮ ਵੀ ਦਿਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਬਦਲੀ। ਸਿਰਫ਼ "customer updated" ਨਹੀਂ, ਬਲਕਿ "billing address changed" ਜਾਂ "invoice #1042 status updated." ਖੇਤਰਾਂ ਦੇ ਨਾਂ ਲੋਕਾਂ ਨੂੰ ਪੰਜ ਸਕ੍ਰੀਨ ਖੋਲ੍ਹਣ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।

ਸਭ ਤੋਂ ਮਦਦਗਾਰ ਹਿੱਸਾ ਪਹਿਲਾਂ-ਅਤੇ-ਬਾਅਦ ਦਾ ਦਰશਨ ਹੈ। ਇੱਕ ਚੰਗੀ ਐਂਟਰੀ ਇਹ ਸਪਸ਼ਟ ਕਰਦੀ ਹੈ ਕਿ ਪੁਰਾਣਾ ਮੁੱਲ ਕੀ ਸੀ ਅਤੇ ਕੀ ਇਸਨੇ ਬਦਲਿਆ ਹੈ।

ਇੱਕ ਉਪਯੋਗੀ ਰਿਕਾਰਡ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:

• ਕਿਸ ਨੇ ਅਪਡੇਟ ਕੀਤਾ
• ਕਦੋਂ ਹੋਇਆ
• ਕੀ ਬਦਲਿਆ
• ਪੁਰਾਣਾ ਮੁੱਲ ਅਤੇ ਨਵਾਂ ਮੁੱਲ
• ਜਦੋਂ ਸੰਦਰਭ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਤਾਂ ਇਕ ਛੋਟਾ ਕਾਰਨ

ਜਦੋਂ ਕਾਰਨ ਸਪਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ, ਉਹ ਛੋਟਾ ਕਾਰਨ ਕਾਰਗਰ ਹੁੰਦਾ ਹੈ। "Discount changed from 10% to 15%" ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ। ਇਸ ਵਿੱਚ "approved after retention call" ਜਿਵੇਂ ਸ਼ਬਦ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਉਂ।

ਇੱਕ ਸਪਸ਼ਟ ਐਂਟਰੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖ ਸਕਦੀ ਹੈ: "Maya Chen, Support Lead, changed Order #584 status from Pending to Refunded on 12 Mar, 3:14 PM. Note: duplicate charge confirmed."

ਇੱਕ ਲਾਈਨ ਇਸੇ ਨਾਲ ਲੰਬੇ ਅੰਦਰੂਨੀ ਈਮੇਲ ਕਥਨਾਂ ਤੋਂ ਬਚਾ ਸਕਦੀ ਹੈ।

ਵਪਾਰਕ ਵਰਕਫਲੋ ਤੋਂ ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ

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

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

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

ਉਹ ਇਕੋ ਦ੍ਰਿਸ਼ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਲੰਬੇ ਸੁਨੇਹੇ ਧਾਗੇ ਬਣਾਉਂਦੇ ਹਨ:

• ਕੀ ਬਦਲਿਆ?
• ਕਦੋਂ ਬਦਲਿਆ?
• ਕੌਣ ਬਦਲਿਆ?
• ਕੀ ਇਹ ਮਨੁੱਖੀ ਕਾਰਵਾਈ ਸੀ ਜਾਂ ਸਿਸਟਮ ਕਾਰਵਾਈ?

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

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

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

ਐਪ ਵਿੱਚ ਕਦਮ-ਦਰ-ਕਦਮ ਇਸਨੂੰ ਸ਼ਾਮਿਲ ਕਰਨ ਦਾ ਤਰੀਕਾ

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

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

ਇੱਕ ਸਧਾਰਣ ਰੋਲਆਊਟ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

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

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

ਇਤਿਹਾਸ ਨੂੰ ਗੈਰ-ਤਕਨੀਕੀ ਸਟਾਫ ਲਈ ਆਸਾਨ ਬਣਾਓ।"Price changed from 49 to 59 by Maria at 2:14 PM" ਉਪਯੋਗੀ ਹੈ।"Field value updated in record 8841" ਨਹੀਂ। ਸਪਸ਼ਟ ਬੋਲਚਾਲ ਨੈੜੇ-ਨੈੜੇ ਪੁੱਛਤਾਛ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਨਵੇਂ ਟੀਮ ਮੈਂਬਰਾਂ ਨੂੰ ਜਲਦੀ ਸਮਝਾਉਂਦੀ ਹੈ ਕਿ ਕੀ ਹੋਇਆ।

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

ਇੱਕ ਅਸਲੀ ਕੇਸ ਨਾਲ ਟੈਸਟ ਕਰੋ

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

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

ਇਹ ਸਪੋਰਟ, ਹੈਂਡਓਫ਼ ਅਤੇ ਟੀਮ ਭਰੋਸੇ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ

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

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

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

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

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

ਆਮ ਗਲਤੀਆਂ ਜੋ ਆਡਿਟ ਇਤਿਹਾਸ ਨੂੰ ਘੱਟ ਉਪਯੋਗੀ ਬਣਾਉਂਦੀਆਂ ਹਨ

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

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

ਬਹੁਤ ਘੱਟ ਡੇਟਾ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸ਼ੋਰ

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

ਇੱਕ ਉਪਯੋਗੀ ਰਿਕਾਰਡ ਦੋਨੋਂ ਅਤਿਕ੍ਰਮਤੀਆਂ ਤੋਂ ਬਚ ਕੇ ਫੋਕਸ ਕਰਦਾ ਹੈ: ਮਾਨਯੋਗ ਘਟਨਾਵਾਂ ਤੇ, ਜਿਵੇਂ:

• ਉਹ ਖੇਤਰ ਜਿਨ੍ਹਾਂ ਦੇ ਬਦਲਾਅ ਕੰਮ ਜਾਂ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ
• ਕਿਸ ਨੇ ਬਦਲਾਅ ਕੀਤਾ
• ਪੁਰਾਣਾ ਅਤੇ ਨਵਾਂ ਮੁੱਲ
• ਘਟਨਾ ਦਾ ਨਿਰਧਾਰਤ ਸਮਾਂ
• ਮਿਟਾਏ, ਰੀਸਟੋਰ ਕੀਤੇ ਜਾਂ ਆਰਕਾਈਵ ਕੀਤੇ ਕਾਰਜ

ਦੂਜੀ ਗਲਤੀ ਉਹ ਲੇਬਲ ਵਰਤਣਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਬਣਾਉਣ ਵਾਲਾ ਸਮਝ ਸਕਦਾ ਹੈ। ਕਰਮਚਾਰੀ ਨੂੰ ਐਨਾਂ ਐਂਟਰੀਜ਼ ਨੂੰ ਡਿਕੋਡ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ—"entity_state_modified" ਜਾਂ "attr_17 updated" ਵਰਗੀ ਲੇਬਲਾਂ ਦੀ ਥਾਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਰਤੋ। "Invoice status changed from Pending to Paid" ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਸਪੱਸ਼ਟ ਹੈ।

ਵੇਖਣ ਵਿੱਚ ਔਖਾ, ਭਰੋਸਾ ਘਟਾਉਂਦਾ

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

ਸਮਾਂ-ਸੰਭਾਲ ਵੀ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਜੇ ਇਕ ਸਾਥੀ 9:00 AM ਵੇਖਦਾ ਹੈ ਅਤੇ ਦੂਜਾ 2:00 PM ਏਕੋ ਹੀ ਘਟਨਾ ਲਈ, ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਹੈ। ਖਾਸ ਕਰਕੇ ਰਿਮੋਟ ਟੀਮਾਂ ਲਈ ਟਾਈਮ ਜ਼ੋਨ ਸਪੱਸ਼ਟ ਦਿਖਾਓ।

ਬਹੁਤ ਸਾਰੀਆਂ ਐਪ ਮਿਟਾਏ ਗਏ ਘਟਨਾਵਾਂ ਨੂੰ ਲਿਖਣਾ ਵੀ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਸਭ ਤੋਂ ਵੀਖਤ ਕਿਸਮ ਦੀ ਰਹੱਸ ਹੈ: ਹਰੇਕ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਕੁਝ ਗੁੰਮ ਹੋ ਗਿਆ, ਪਰ ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਇਹ ਕਦੋਂ ਮਿਟਿਆ ਜਾਂ ਕਿਸ ਨੇ ਮਿਟਾਇਆ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਰੰਤ ਚੈੱਕ

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

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

ਪੰਜ ਚੈੱਕ ਕੀਤੇ ਜਾਣ ਯੋਗ ਹਨ:

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

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

ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਜਦੋਂ activity ਵਧੇ, ਇਤਿਹਾਸ ਪੜ੍ਹਨਯੋਗ ਰਹੇ ਨਾ ਕਿ ਸ਼ੋਰ ਬਣ ਜਾਵੇ।

ਆਪਣੇ ਐਪ ਲਈ عملي ਅਗਲੇ ਕਦਮ

ਇਕ workflow ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਗੁੰਝਲ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਆਰਡਰ ਸਟੇਟਸ ਬਦਲਾਅ, ਇਨਵੌਇਸ ਸੰਪਾਦਨ, ਗਾਹਕ ਰਿਕਾਰਡ ਅਪਡੇਟ ਜਾਂ ਅਨੁਮੋਦਨੀ ਕਦਮ। ਜੇ ਲੋਕ ਅਕਸਰ ਪੁੱਛਦੇ ਹਨ, "ਇਸਨੂੰ ਕਿਸ ਨੇ ਬਦਲਿਆ?" ਜਾਂ "ਇਹ ਕਦੋਂ ਹੋਇਆ?" ਤਾਂ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਓਹੀ ਥਾਂ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ।

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

ਕੁਝ ਸਧਾਰਣ ਸਵਾਲਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਸ਼ੁਰੂਆਤੀ ਨੁਕਤੇ ਖੋਲ੍ਹ ਦਿੰਦੇ ਹਨ:

• ਕਿਹੜੇ ਰਿਕਾਰਡ ਸਭ ਤੋਂ ਵੱਧ ਬੈਕ-ਅੰਡ-ਫੋਰਥ ਪੈਦਾ ਕਰਦੇ ਹਨ?
• ਕਿਹੜੇ ਖੇਤਰ ਅਕਸਰ ਬਦਲਦੇ ਹਨ?
• ਕਿਹੜੇ ਬਦਲਾਅ ਵਪਾਰਕ ਖ਼ਤਰੇ ਪੈਦਾ ਕਰਦੇ ਹਨ?
• ਜਦੋਂ ਯੂਜ਼ਰ ਸਮੱਸਿਆ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਸਪੋਰਟ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਵੇਖਦਾ ਹੈ?
• ਕੌਣ ਇਤਿਹਾਸ ਵੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਸਿਰਫ਼ ਆਖ਼ਰੀ ਨਤੀਜਾ ਦੇਖੇ?

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

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

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

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

ਮਕਸਦ ਸਭ ਕੁਝ ਲੌਗ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨੂੰ ਸਧਾਰਣ, ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣਾ ਹੈ।