ਹਰ ਮਹੀਨੇ ਦਸ ਤਾਰੀਖ ਦੇ ਆਸ-ਪਾਸ, ਅਕਾਊਂਟਿੰਗ ਟੀਮ ਇੱਕੋ ਜਿਹੀ ਬੇਨਤੀ ਭੇਜਦੀ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਹਰੇਕ ਕਲਾਇੰਟ ਤੋਂ ਪੰਜ ਫਾਈਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਬੈਂਕ ਸਟੇਟਮੈਂਟ, ਇੱਕ ਰਸੀਦ ਆਰਕਾਈਵ (receipt archive), ਇੱਕ ਪੇਰੋਲ ਰਿਪੋਰਟ, ਇੱਕ ਸੇਲਜ਼ ਸਮਰੀ, ਅਤੇ ਇੱਕ ਇਨਵੈਂਟਰੀ ਦਸਤਾਵੇਜ਼। ਟੈਂਪਲੇਟ ਦੋਸਤਾਨਾ, ਸਹੀ ਅਤੇ ਟੈਸਟ ਕੀਤਾ ਹੋਇਆ ਹੈ। ਇਹ ਕਲਾਇੰਟ ਦਾ ਨਾਮ ਲੈ ਕੇ ਸਵਾਗਤ ਕਰਦਾ ਹੈ, ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਸਮਾਂ ਸੀਮਾ (deadline) ਦੱਸਦਾ ਹੈ। ਪਹਿਲੀ ਵਾਰ ਭੇਜਣ 'ਤੇ, ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਇੱਕ ਸਾਫ਼-ਸੁਥਰੀ ਸੂਚੀ ਦੇਖਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਮੁਸ਼ਕਲ ਦੂਜੀ ਈਮੇਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਕਲਾਇੰਟ ਚਾਰ ਫਾਈਲਾਂ ਭੇਜਦਾ ਹੈ। ਪੰਜਵੀਂ ਬੈਂਕ ਸਟੇਟਮੈਂਟ ਕਦੇ ਨਹੀਂ ਆਉਂਦੀ। ਰਸੀਦ ਆਰਕਾਈਵ ਤਾਂ ਆ ਜਾਂਦੀ ਹੈ, ਪਰ ਇਹ ਗਲਤ ਮਹੀਨੇ ਦੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਟੀਮ ਇਸਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਪੇਰੋਲ ਰਿਪੋਰਟ ਅਸਲ ਵਿੱਚ ਤਿੰਨ ਦਿਨ ਪਹਿਲਾਂ Slack ਰਾਹੀਂ ਆ ਗਈ ਸੀ, ਅਤੇ ਕਿਸੇ ਨੇ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਫਾਈਲ ਕਰ ਦਿੱਤਾ ਹੈ। ਇਨਵੈਂਟਰੀ ਦਸਤਾਵੇਜ਼ ਇਸ ਕਲਾਇੰਟ ਲਈ ਬਿਲਕੁਲ ਵੀ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਇੱਕ ਅਜਿਹੀ ਜਾਣਕਾਰੀ ਜੋ ਤੁਹਾਨੂੰ ਪਹਿਲਾ ਸੁਨੇਹਾ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਹੀ ਪਤਾ ਲੱਗੀ। ਜੇਕਰ ਤੁਸੀਂ ਅਸਲ ਟੈਂਪਲੇਟ ਦੁਬਾਰਾ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਫਿਰ ਤੋਂ ਪੰਜ ਫਾਈਲਾਂ ਦੀ ਮੰਗ ਕਰਦੇ ਹੋ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਚਾਰ ਬੇਨਤੀਆਂ ਹੁਣ ਬੇਮਤਲਬ ਹਨ। ਇੱਕ ਬਿਲਕੁਲ ਗਲਤ ਜਾਣਕਾਰੀ ਦੇ ਰਹੀ ਹੈ। ਸ਼ਬਦਾਵਲੀ ਠੀਕ ਹੈ। ਈਮੇਲ ਵਿੱਚ ਸਿਰਫ਼ ਯਾਦਦਾਸ਼ਤ ਦੀ ਕਮੀ ਹੈ।
ਇੱਕ ਈਮੇਲ ਟੈਂਪਲੇਟ ਨਾਮ, ਮਿਤੀਆਂ ਅਤੇ ਹਦਾਇਤਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ, ਇੱਕ ਵਾਰ ਦੀ ਬੇਨਤੀ ਲਈ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵਿਅਕਤੀ ਮੇਲ ਭੇਜਦਾ ਹੈ, ਕਲਾਇੰਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਵਿਅਕਤੀ ਕੰਮ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਇਤਿਹਾਸ ਇੱਕ ਦਿਮਾਗ ਅਤੇ ਇੱਕ ਇਨਬਾਕਸ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਅਗਲਾ ਸੁਨੇਹਾ ਉਹਨਾਂ ਘਟਨਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲੀ ਈਮੇਲ ਤੋਂ ਬਾਅਦ ਵਾਪਰੀਆਂ ਸਨ। ਟੈਂਪਲੇਟ ਅਜੇ ਵੀ ਅਸਲ ਸੂਚੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਬੈਂਕ ਸਟੇਟਮੈਂਟ ਕੱਲ੍ਹ ਆਈ ਸੀ। ਇਸਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਪੇਰੋਲ ਰਿਪੋਰਟ ਰੱਦ ਕਰ ਦਿੱਤੀ ਗਈ ਸੀ। ਉਹ ਡੇਟਾ ਇੱਕ ਇਨਬਾਕਸ ਵਿੱਚ, ਸ਼ਾਇਦ ਕਈ ਇਨਬਾਕਸਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਰੀਮਾਈਂਡਰ ਬਣਾਉਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਕੋਲ ਇਸਨੂੰ ਪੜ੍ਹਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੁੰਦਾ।
ਜਦੋਂ "Open" ਹੋਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ
ਜੇਕਰ ਤੁਸੀਂ ਪੂਰੀ ਬੇਨਤੀ ਨੂੰ "open" ਵਰਗੀ ਇੱਕ ਸਿੰਗਲ ਸਟੇਟਸ ਵਜੋਂ ਟ੍ਰੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਵੇਰਵੇ ਗੁਆ ਲੈਂਦੇ ਹੋ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਵਸਤੂਆਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ। ਹਰੇਕ ਨੂੰ ਆਪਣੀ ਵੱਖਰੀ ਸਟੇਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਅਗਲੀ ਗੱਲਬਾਤ ਸਹੀ ਹੋ ਸਕੇ:
- Bank statement: ਗੁੰਮ ਹੈ। ਕਲਾਇੰਟ ਨੇ ਇਹ ਨਹੀਂ ਭੇਜੀ ਹੈ।
- Receipt archive: ਅਪਲੋਡ ਕੀਤੀ ਗਈ ਹੈ ਪਰ ਅਜੇ ਤੱਕ ਜਾਚੀ ਨਹੀਂ ਗਈ। ਇਹ ਅੰਦਰੂਨੀ ਚੈੱਕ ਦੀ ਉਡੀਕ ਵਿੱਚ ਇੱਕ ਫੋਲਡਰ ਵਿੱਚ ਪਈ ਹੈ।
- Payroll report: ਰੱਦ ਕਰ ਦਿੱਤੀ ਗਈ। ਕਲਾਇੰਟ ਨੇ ਕੁਝ ਭੇਜਿਆ ਸੀ, ਪਰ ਉਹ ਗਲਤ ਫਾਰਮੈਟ ਜਾਂ ਗਲਤ ਪੇਅ ਪੀਰੀਅਡ ਸੀ।
- Sales report: ਕਿਸੇ ਹੋਰ ਚੈਨਲ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਹੋਈ। ਇਹ Slack, ਫ਼ੋਨ ਕਾਲ, ਜਾਂ ਡਾਕ ਰਾਹੀਂ ਆਈ ਸੀ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਨੇ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲੌਗ ਕਰ ਲਿਆ ਹੈ।
- Inventory document: ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਕਲਾਇੰਟ ਨੂੰ ਇਹ ਦੇਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਪੁੱਛਣਾ ਬੰਦ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਵੇਰਵੇ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਡਾ ਰੀਮਾਈਂਡਰ ਅੰਨ੍ਹਾ ਹੈ। ਇਹ ਇੱਕ ਗੁੰਮ ਹੋਈ ਫਾਈਲ ਅਤੇ ਇੱਕ ਰੱਦ ਕੀਤੀ ਗਈ ਫਾਈਲ ਨਾਲ ਇੱਕੋ ਜਿਹਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਇਹ ਹੱਥ ਵਿੱਚ ਮੌਜੂਦ ਫਾਈਲ ਨਾਲ ਅਜਿਹਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਉਹ ਕਦੇ ਆਈ ਹੀ ਨਾ ਹੋਵੇ। ਇਹ ਕਲਾਇੰਟ ਦਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ ਅਤੇ ਭਰੋਸੇ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਦੋ ਜਾਂ ਤਿੰਨ ਗੈਰ-ਸਬੰਧਤ ਰੀਮਾਈਂਡਰਾਂ ਤੋਂ ਬਾਅਦ, ਕਲਾਇੰਟ ਸੁਨੇਹਿਆਂ ਨੂੰ ਉੱਪਰ-ਉੱਪਰੋਂ ਦੇਖਦੇ ਹਨ। ਉਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਸਿਸਟਮ ਖਰਾਬ ਹੈ।
ਸਿਰਫ਼ ਉਹੀ ਬਣਾਓ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਿਸ਼ਾਲ ਰੂਲਜ਼ ਇੰਜਣ ਨਾ ਬਣਾਓ। ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਹੀ ਵੀਹ ਕੰਡੀਸ਼ਨਲ ਬ੍ਰਾਂਚਾਂ ਵਾਲੇ ਵਰਕਫਲੋ ਆਟੋਮੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਸਿਰਫ਼ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਲੋੜੀਂਦਾ ਡੇਟਾ ਟ੍ਰੈਕ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕਲਾਇੰਟ ਤੋਂ ਅਜੇ ਕਿਸ ਕੰਮ ਦੀ ਲੋੜ ਹੈ?
ਹਰੇਕ ਮੰਗੀ ਗਈ ਵਸਤੂ ਲਈ ਇੱਕ ਟਿਕਾਊ ਨਤੀਜੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਅਜਿਹਾ ਰਿਕਾਰਡ ਜੋ ਈਮੇਲ ਥ੍ਰੈਡ ਤੋਂ ਬਾਹਰ ਹੋਵੇ, ਅਜਿਹੀ ਜਗ੍ਹਾ 'ਤੇ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਅਗਲਾ ਸੁਨੇਹਾ ਤਿਆਰ ਕਰਦੇ ਸਮ
ਇੱਕ ਸਿੰਗਲ ਫਾਈਲ ਲਈ, ਜਵਾਬ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ। ਪਰ ਕਈ ਪਹਿਲੂਆਂ ਵਾਲੀਆਂ ਮਹੀਨਾਵਾਰ ਦੁਹਰਾਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਲਈ, ਇਹ ਬਹੁਤ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਜੇਕਰ ਮੁੱਖ ਸੰਪਰਕ ਵਿਅਕਤੀ ਛੁੱਟੀ 'ਤੇ ਹੈ, ਤਾਂ ਕੀ ਕੋਈ ਸਹਿਕਰਮੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਗੁੰਮ ਹੈ? ਕੀ ਇੱਕ ਮੈਨੇਜਰ ਦਸ ਈਮੇਲਾਂ ਅਤੇ ਤਿੰਨ ਸਾਂਝੇ ਫੋਲਡਰਾਂ ਨੂੰ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਕਲਾਇੰਟ ਸਾਰੇ ਕੰਮ ਪੂਰੇ ਕਰ ਚੁੱਕਾ ਹੈ? ਜੇਕਰ ਰਿਜੈਕਸ਼ਨ (rejection) ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਇਕਲੌਤੀ ਜਗ੍ਹਾ ਕਿਸੇ ਥਰੈਡ (thread) ਦਾ ਚੌਥਾ ਸੁਨੇਹਾ ਹੈ, ਜੋ ਕਿ ਸਿਗਨੇਚਰਾਂ ਅਤੇ ਫਾਰਵਰਡਸ ਦੇ ਹੇਠਾਂ ਦਬਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਸਿਸਟਮ ਇਨਸਾਨਾਂ ਨੂੰ ਉਹ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਇੱਕ ਡਾਟਾਬੇਸ ਨੂੰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਟੈਂਪਲੇਟਸ (Templates) ਸੁਨੇਹੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਟ੍ਰੈਕ ਕੀਤੀ ਹੋਈ ਬੇਨਤੀ ਇਤਿਹਾਸ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ। ਇੱਕ ਇਹ ਸੰਭਾਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹੋ। ਦੂਜਾ ਇਹ ਸੰਭਾਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਜਾਣਦੇ ਹੋ।
ਕੁਐਰੀਆਂ (Queries), ਸਕ੍ਰਿਪਟਾਂ ਨਹੀਂ
ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਆਈਟਮ-ਲੈਵਲ ਸਟੇਟਸ (item-level states) ਹੁੰਦੇ ਹਨ, ਤਾਂ ਈਮੇਲ ਤਿਆਰ ਕਰਨਾ ਸਕ੍ਰਿਪਟਿੰਗ ਤੋਂ ਕੁਐਰੀਆਂ (querying) ਵੱਲ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਪਹਿਲਾਂ, ਤੁਸੀਂ ਇੱਕ ਪੈਰਾ ਲਿਖਦੇ ਸੀ ਅਤੇ ਉਮੀਦ ਕਰਦੇ ਸੀ ਕਿ ਇਹ ਅਜੇ ਵੀ ਸਹੀ ਹੈ। ਹੁਣ ਤੁਸੀਂ ਆਪਣੇ ਡਾਟਾ ਨੂੰ ਪੁੱਛਦੇ ਹੋ: ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀਆਂ ਆਈਟਮਾਂ ਲਈ ਅਜੇ ਵੀ ਕਲਾਇੰਟ ਦੀ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੈ? ਤੁਸੀਂ ਉਸ ਫਿਲਟਰ ਕੀਤੀ ਗਈ ਸੂਚੀ ਦੇ ਆਧਾਰ 'ਤੇ ਰੀਮਾਈਂਡਰ ਤਿਆਰ ਕਰਦੇ ਹੋ। ਜੇਕਰ ਕਿਸੇ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕੋਈ ਰੀਮਾਈਂਡਰ ਨਹੀਂ ਭੇਜਦੇ। ਜੇਕਰ ਦੋ ਆਈਟਮਾਂ ਲਈ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇੱਕ ਨੂੰ ਕਿਸੇ ਖਾਸ ਕਾਰਨ ਕਰਕੇ ਰਿਜੈਕਟ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਈਮੇਲ ਉਹਨਾਂ ਤੱਥਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਆਪਣੇ ਆਪ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇਹ