ਯੋਜਿਤ ਡਾਊਨਟਾਈਮ, ਪਾਰਸ਼ਲ ਆਉਟੇਜ ਅਤੇ ਡੀਗਰੇਡਡ ਪਰਫਾਰਮੈਂਸ ਦੌਰਾਨ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਸ਼ਾਂਤ ਰੱਖਣ ਵਾਲੇ ਮੈਂਟੇਨੈਂਸ ਵਿੰਡੋ ਸੁਨੇਹਾ ਟੈਮਪਲੇਟ — ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਓ ਅਤੇ ਸਪੋਰਟ ਟਿਕੱਟਾਂ ਨੂੰ ਕਟੋ।
ਬਹੁਤ ਸਾਰੇ ਮੈਂਟੇਨੈਂਸ ਨੋਟ ਇੱਕ ਹੀ ਸਧਾਰਣ ਕਾਰਨ ਕਰਕੇ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ: ਉਹ ਅਣਿਸ਼ਚਿਤਤਾ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਬੈਨਰ ਜੋ ਕੇਵਲ “ਅਸੀਂ ਮੈਂਟੇਨੈਂਸ ਕਰ ਰਹੇ ਹਾਂ” ਕਹਿੰਦਾ ਹੈ ਬਿਨਾਂ ਵੇਰਵੇ ਦੇ, ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਠਾਣਾ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਟੁੱਟਿਆ ਹੈ, ਇਹ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਚੱਲੇਗਾ, ਅਤੇ ਉਹਨਾਂ ਦਾ ਕੰਮ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿ ਨਹੀਂ। ਅਨੁਮਾਨ ਡਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡਰ ਸਪੋਰਟ ਟਿਕੱਟਾਂ ਵਿੱਚ।
ਅਸਪਸ਼ਟ ਸੁਨੇਹਾ ਵੀ ਸ਼ੱਕ ਜਨਕ ਲੱਗਦਾ ਹੈ। ਜੇ ਉਪਭੋਗਤਾ ਏਰਰ ਵੇਖਦੇ ਹਨ ਪਰ ਤੁਹਾਡਾ ਸੁਨੇਹਾ ਠੰਡਾ ਅਤੇ ਜਨਰਿਕ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਉਹ ਸੋਚਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਅਸਲ ਸਮੱਸਿਆ ਛੁਪਾ ਰਹੇ ਹੋ। ਜੋ ਫਰਕ ਉਹ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਅਤੇ ਜੋ ਤੁਸੀਂ ਕਹਿੰਦੇ ਹੋ, ਉਹ ਭਰੋਸਾ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।
ਲੋਕਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਤਿੰਨ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਸਪਸ਼ਟ ਪ੍ਰਭਾਵ, ਸਪਸ਼ਟ ਸਮਾਂ, ਅਤੇ ਸਪਸ਼ਟ ਅਗਲੇ ਕਦਮ।
ਪ੍ਰਭਾਵ ਦਾ ਮਤਲਬ ਹੈ ਕੀ ਪ੍ਰਭਾਵਤ ਹੋ ਰਿਹਾ ਹੈ ਦਾ ਨਾਮ ਲੈਣਾ (ਲੌਗਿਨ, ਐਕਸਪੋਰਟ, ਭੁਗਤਾਨ), ਕੇਵਲ “ਸਰਵਿਸ ਰੁਕਾਵਟ” ਕਹਿਣ ਦੀ ਥਾਂ। ਸਮਾਂ ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਨਿਰਧਾਰਿਤ ਵਿੰਡੋ ਅਤੇ ਅਗਲਾ ਅਪਡੇਟ ਕਦੋਂ ਹੋਵੇਗਾ, “ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ” ਨਾ। ਅਗਲੇ ਕਦਮ ਦਾ ਮਤਲਬ ਹੈ ਬਤਾਉਣਾ ਕਿ ਉਨਾਂ ਨੂੰ ਉਡੀਕ ਦੌਰਾਨ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ “20 ਮਿੰਟ ਬਾਅਦ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ” ਜਾਂ “ਇਸ ਦੀ ਬਜਾਏ ਮੋਬਾਈਲ ਐਪ ਵਰਤੋ।”
ਜ਼ਿਆਦਾ ਪ੍ਰਤੀਸ਼ਾ ਕਰਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਹਾਲਤ ਬਿਗਾੜ ਸਕਦਾ ਹੈ। “ਕੋਈ ਪ੍ਰਭਾਵ ਦੀ ਉਮੀਦ ਨਹੀਂ” ਕਹਿਣਾ ਖਤਰਨਾਕ ਹੈ ਜੇ ਤੱਕ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨिश्चਿਤ ਨਹੀਂ ਹੋ। ਜਦ ਵੀ ਇੱਕ ਵੀ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਤ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਉਹ ਲਾਈਨ ਇਹ ਸਾਬਤ ਕਰ ਦਿੰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਧਿਆਨ ਨਹੀਂ ਦੇ ਰਹੇ। ਇਮਾਨਦਾਰ ਅਪਡੇਟ ਬਿਹਤਰ ਕੰਮ ਕਰਦੇ ਹਨ: ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ, ਅਤੇ ਅਗਲੇ ਅਪਡੇਟ ਦਾ ਸਮਾਂ ਸਾਫ਼ ਕਹੋ।
ਮਕਸਦ ਕਹਾਣੀ ਨੂੰ “ਸਪਿਨ” ਕਰਨਾ ਨਹੀਂ। ਮਕਸਦ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣਾ ਹੈ। ਜਦ ਲੋਕ ਸਮਝ ਲੈਂਦੇ ਹਨ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਉਹਨਾਂ ਲਈ ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੁਣ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਉਹ ਰਿਫਰੇਸ਼ ਕਰਨਾ ਬੰਦ ਕਰਦੇ ਹਨ, ਸਭ ਤੋਂ ਖਰਾਬ ਮੰਨਣਾ ਬੰਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਕੰਟਰੋਲ ਮਹਿਸੂਸ ਕਰਨ ਲਈ ਟਿਕੱਟ ਖੋਲ੍ਹਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਜਦ ਤੁਸੀਂ ਸਥਿਤੀ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਨਾਂਮ ਦਿੱਤਾ ਕਰਦੇ ਹੋ ਤਾਂ ਉਪਭੋਗਤਾ ਅਰਾਮ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀ ਸਭ ਕੁਝ “ਮੈਂਟੇਨੈਂਸ” ਜਾਂ “ਮੁਸ਼ਕਲ” ਕਹਿੰਦੇ ਹੋ, ਲੋਕ ਸਭ ਤੋਂ ਬੁਰੇ ਦੀ ਅਨੁਮਾਨ ਲਾਉਂਦੇ ਹਨ, ਫਿਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼, ਰਿਫਰੇਸ਼ ਅਤੇ ਸਪੋਰਟ ਟਿਕੱਟ ਖੋਲ੍ਹਦੇ ਹਨ।
ਸਹੀ ਲੇਬਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
“Degraded” ਕਦੇ ਵੀ ਅਸਪਸ਼ਟ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਦੱਸੋ ਉਪਭੋਗਤਾ ਕੀ ਮਹਿਸੂਸ ਕਰੇਗਾ। ਉਦਾਹਰਨ ਵਜੋਂ: “ਐਕਸਪੋਰਟ ਸਧਾਰਣ ਵਾਰੋਂ 10 ਤੋਂ 20 ਮਿੰਟ ਵੱਧ ਲੈ ਸਕਦੇ ਹਨ” ਕਹਿਣਾ “ਡੀਗਰੇਡਡ ਪਰਫਾਰਮੈਂਸ” ਦੀ ਬਜਾਏ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੈ।
ਜੇ ਪ੍ਰਭਾਵਤ ਚੀਜ਼ਾਂ ਦੀ ਸੂਚੀ ਛੋਟੀ ਵੀ ਹੋਵੇ ਤਾਂ ਵੀ ਉਸਨੂੰ ਨਿਰਧਾਰਤ ਰੂਪ ਵਿੱਚ ਦੱਸੋ। ਉਹ ਖੇਤਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੋਕ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਪਿਆਰ ਕਰਦੇ ਹਨ: ਲੌਗਿਨ, ਭੁਗਤਾਨ ਅਤੇ ਬਿੱਲਿੰਗ, ਸਿੰਕ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਡੈਸ਼ਬੋਰਡ, ਐਕਸਪੋਰਟ, API ਐਕਸੇਸ, ਅਤੇ ਫਾਈਲ ਅੱਪਲੋਡ।
ਡਰਾਉਣੇ ਸ਼ਬਦਾਂ ਤੋਂ ਬਚੋ, ਪਰ ਸੱਚਾਈ ਨੁਂ ਛੁਪਾਉਣਾ ਵੀ ਨਹੀਂ। “Critical failure” ਦੀ ਥਾਂ “ਕੁਝ ਯੂਜ਼ਰ ਲੌਗਿਨ ਨਹੀਂ ਕਰ ਸਕਦੇ” ਅਤੇ “system instability” ਦੀ ਥਾਂ “ਸੇਵਿੰਗ ਵੇਲੇ ਤੁਸੀਂ ਟਾਈਮਆਊਟ ਵੇਖ ਸਕਦੇ ਹੋ” ਵਰਗਾ ਬਦਲੋ। ਇੱਕ ਠੰਢਾ ਟੋਨ ਸਹੀ ਜਾਣਕਾਰੀ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਓਪਟਿਮਿਸਟਿਕ ਭਾਵ ਤੋਂ।
ਜੇ ਤੁਸੀਂ ਅਣਿਸ਼ਚਿਤ ਹੋ, ਤਾਂ ਅੰਦਰੂਨੀ ਕਾਰਨ ਦੀ ਥਾਂ ਉਹ ਲੇਬਲ ਚੁਣੋ ਜੋ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। “ਡੇਟਾਬੇਸ ਮੈਂਟੇਨੈਂਸ” ਜ਼ਿਆਦਾ ਲੋਕਾਂ ਲਈ ਘੱਟ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। “ਬਿੱਲਿੰਗ ਪੇਜ 15 ਮਿੰਟ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਹੋ ਸਕਦੀ” ਦੱਸਣਾ ਉਨਾਂ ਨੂੰ ਕਿ ਉਮੀਦ ਕੀ ਹੈ ਅਤੇ ਕੀ ਕਰਨਾ ਹੈ।
ਉਪਭੋਗਤਾ ਉਸ ਚੀਜ਼ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਜੋ ਉਹ ਵੱਜੇ ਸਮੇਂ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹਨ। ਚੰਗੇ ਮੇਸੇਜ ਟੈਮਪਲੇਟ ਵਾਕਈ ਵਿਚ ਕਲਿਆਨ ਕਹਿਣ ਤੋਂ ਜ਼ਿਆਦਾ ਸਹੀ ਸਰਫੇਸ ਵਰਤਣ ਬਾਰੇ ਹੁੰਦੇ ਹਨ।
ਅਕਸਰ ਯੋਜਿਤ ਕੰਮ ਲਈ ਇਨ-ਐਪ ਬੈਨਰ ਵਰਤੋ। ਇਹ ਦਿਖਾਈ ਦਿੱਤਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਲੋਕ ਆਪਣਾ ਕੰਮ ਜਾਰੀ ਰਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਕ੍ਰੀਨ ਨੂੰ ਹਾਈਜੈਕ ਨਹੀਂ ਕਰਦਾ।
ਜਦੋਂ ਉਪਭੋਗਤਾ ਨਾਲਾਂ ਜਾਰੀ ਰੱਖਣ ਨਾਲ ਗਲਤੀ ਜਾਂ ਡਾਟਾ ਕੰਮ ਖੋ ਸਕਦਾ ਹੈ ਤਾਂ ਹੀ ਮੋਡਲ ਵਰਤੋ (ਬਿੱਲਿੰਗ ਕਾਰਵਾਈਆਂ, ਡਾਟਾ ਐਡੀਟ, ਸਾਇਨਅੱਪ)। ਜੇ ਤੁਸੀਂ ਮੋਡਲ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਲੋਕਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਪਿਰਸਿਸਟੈਂਟ ਬੈਨਰ ਰੱਖੋ।
ਟੋਸਟ ਛੋਟੀ, ਘੱਟ-ਖਤਰੇ ਵਾਲੀਆਂ ਅਪਡੇਟਾਂ ਲਈ ਵਧੀਆ ਹਨ (ਉਦਾਹਰਨ ਲਈ, “ਐਕਸਪੋਰਟ 10 ਮਿੰਟ ਲਈ ਹੌਲੀ ਹੋ ਸਕਦੇ ਹਨ”)। ਉਨ੍ਹਾਂ ਨੂੰ ਲੱਭਣਾ ਅਸਾਨ ਨਹੀਂ, ਇਸ ਲਈ ਅਸਲੀ ਡਾਊਨਟਾਈਮ ਲਈ ਉਹ ਵਰਤੋ ਨਹੀਂ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ:
ਜੇ ਉਪਭੋਗਤਾ ਲੌਗਿਨ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਹੋ ਸਕਦੇ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਲੌਗਿਨ ਸਕਰੀਨ 'ਤੇ ਇਕੋ ਜਿਹਾ ਸੁਨੇਹਾ ਦਿਖਾਓ। panic ਇਥੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਇਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਦਾ ਖਾਤਾ ਖਰਾਬ ਹੋ ਗਿਆ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਨੋਟ ਜਿਵੇਂ ਕਿ “02:00-02:30 UTC ਦੇ ਦੌਰਾਨ ਲੌਗਿਨ ਅਸਫਲ ਹੋ ਸਕਦੇ ਹਨ” ਟਿਕੱਟਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾ ਦਿੰਦਾ ਹੈ।
ਆਪਣੇ ਸਟੇਟਸ ਪੇਜ ਨੂੰ ਲਗਾਤਾਰ ਅਪਡੇਟਾਂ ਅਤੇ ਇਤਿਹਾਸ ਲਈ ਵਰਤੋ (ਕੀ ਬਦਲਿਆ, ਕੀ ਅਜੇ ਪ੍ਰਭਾਵਤ ਹੈ, ਕੀ ਠੀਕ ਹੋ ਚੁੱਕਾ)। ਇਨ-ਐਪ ਨੋਟਿਸ ਨੂੰ ਉਹੀ ਰੱਖੋ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਹੁਣ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਰੁਕੋ, ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਐਕਸਪੋਰਟ ਤੋਂ ਬਚੋ ਆਦਿ)। ਜ਼ਰੂਰੀ ਵੇਰਵੇ ਸਿਰਫ ਸਟੇਟਸ ਪੇਜ 'ਤੇ ਨਾ ਛੱਡੋ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ ਉਸਨੂੰ ਨਹੀਂ ਦੇਖਦੇ।
ਈਮੇਲ ਅਤੇ ਪੁਸ਼ ਸੂਚਨਾਵਾਂ ਉਚਿਤ ਹਨ ਜਦ ਪ੍ਰਭਾਵ ਵੱਡਾ ਹੋਵੇ ਅਤੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਯੋਜਨਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇ। ਨਹੀਂ ਤਾਂ ਉਹ ਸ਼ੋਰ ਵਾਲੇ ਲੱਗਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇਨ-ਐਪ ਕਾਪੀ ਨਾਲ ਸੰਘਰਸ਼ਿਤ ਰੱਖੋ।
ਅੰਤ ਵਿੱਚ, ਸਪੋਰਟ ਨਾਲ ਵੀ ਇੱਕੋ ਜਿਹਾ ਭਾਸ਼ਾ ਰੱਖੋ। ਤੁਹਾਡੀ ਆਟੋ-ਰਿਪਲਾਈ ਬੈਨਰ ਟੈਕਸਟ ਅਤੇ ਸਟੇਟਸ ਅਪਡੇਟ ਨਾਲ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ ਮੈਸੈਜਾਂ ਵਿੱਚ ਉਲਝਣ ਨਾ ਮਹਿਸੂਸ ਕਰਨ।
ਲੋਕ ਮੈਂਟੇਨੈਂਸ ਨੋਟਿਸਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਜਦ ਉਹ ਸਪਸ਼ਟ, ਇਮਾਨਦਾਰ ਅਤੇ ਵਰਤੋਂਯੋਗ ਹੁੰਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਲੰਮਾ ਸੁਨੇਹਾ ਨਹੀਂ। ਮਤਲਬ ਉਹ ਹੈ ਕਿ ਇੱਕ ਤਣਾਅ ਵਿੱਚ ਪਏ ਉਪਭੋਗਤਾ ਦੇ ਪਹਿਲੇ 10 ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹੋਏ ਸਪਸ਼ਟ ਸਮਾਂ ਅਤੇ ਯੋਜਨਾ ਦਿਤੀ ਜਾਵੇ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ਨੋਟਿਸ ਵਿੱਚ ਪੰਜ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਸਮਾਂ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸੁਨੇਹੇ ਅਕਸਰ ਭਰੋਸਾ ਗੁਆਂਦੇ ਹਨ। ਲੋਕਾਂ ਨੂੰ ਸਮਝ ਆਉਣ ਵਾਲੀ ਵਿੰਡੋ ਵਰਤੋ, ਜਿਵੇਂ “Jan 16, 01:00 to 02:30 UTC.” ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਵਿਸ਼ਵ-ਵਿਆਪੀ ਦਰਸ਼ਕ ਹਨ, ਤਾਂ ਦੂਜਾ ਰੈਫਰੈਂਸ ਟਾਈਮ ਵੀ ਦਿਓ ਜੋ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, “08:00 to 09:30 Singapore time”). “02:17 'ਤੇ ਵਾਪਸੀ” ਵਰਗੇ ਫਾਲਸ ਪ੍ਰਿਸੀਜ਼ਨ ਤੋਂ ਬਚੋ। “30 to 60 minutes” ਵਰਗੇ ਰੇਂਜ ਜ਼ਿਆਦਾ ਇਮਾਨਦਾਰ ਲੱਗਦੇ ਹਨ ਅਤੇ ਗੁੱਸੇ ਭਰੇ ਰਿਫਰੇਸ਼ ਚੱਕਰਾਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਜੇ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਪਤਾ, ਤਾਂ ਦੱਸੋ ਤੁਸੀਂ ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਕੀ ਜਾਂਚ ਰਹੇ ਹੋ। ਉਦਾਹਰਨ: “ਅਸੀਂ ਡੇਟਾਬੇਸ ਉੱਤੇ ਵਧੀਕ ਲੋਡ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ ਅਤੇ ਹਾਲੀਆ ਡਿਪਲੋਇਆਂ ਅਤੇ ਸਲੋ ਕਵੈਰੀਜ਼ ਦੇਖ ਰਹੇ ਹਾਂ। ਅਗਲਾ ਅਪਡੇਟ 14:30 UTC ਤੱਕ ਮਿਲੇਗਾ।” ਇਕ वਾਕ੍ਯ ਚੁੱਪੀ ਨੂੰ ਇੱਕ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਹਮੇਸ਼ਾਂ ਅਗਲੇ ਅਪਡੇਟ ਦਾ ਸਮਾਂ ਦਿਓ, ਭਾਵੇਂ ਉਹ ਜਲਦੀ ਹੋਵੇ ਅਤੇ ਭਾਵੇਂ ਕੁਝ ਨਹੀਂ ਬਦਲੇ। “ਅਗਲਾ ਅਪਡੇਟ 20 ਮਿੰਟ ਵਿੱਚ” ਲੋਕਾਂ ਨੂੰ ਸ਼ਾਂਤ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕ ਵਾਅਦਾ ਸੈਟ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ।
ਭਰੋਸਾ ਬਣਾਉਣ ਵਾਲਾ ਉਦਾਹਰਨ: “ਫਾਈਲ ਐਕਸਪੋਰਟ ਸਧਾਰਣ ਨਾਲੋਂ 10 ਤੋਂ 30 ਮਿੰਟ ਵੱਧ ਲੈ ਸਕਦੇ ਹਨ। ਇਸ ਦੌਰਾਨ, ਤੁਸੀਂ ਰਿਪੋਰਟਸ ਨੂੰ ਇਨ-ਐਪ ਵੇਖ ਸਕਦੇ ਹੋ। ਅਸੀਂ 16:10 UTC ਤੱਕ ਅਗਲਾ ਅਪਡੇਟ ਪੋਸਟ ਕਰਾਂਗੇ।”
ਚੰਗੀਆਂ ਮੈਂਟੇਨੈਂਸ ਨੋਟਿਸਾਂ ਸ਼ਾਂਤ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਪਸ਼ਟ ਅਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਐਲਾਨ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ, ਚੈਕਲਿਸਟ ਵਾਂਗੋ ਵਾਪਰੋ।
ਪਹਿਲਾ ਡਰਾਫਟ ਸਪਸ਼ਟ ਪਲੇਸਹੋਲਡਰਾਂ ਨਾਲ ਲਿਖੋ। ਸ਼ੁਰੂ ਕਰੋ: ਕੀ ਪ੍ਰਭਾਵਤ ਹੈ, ਇਹ ਕਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਹ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਰਹਿ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਪ੍ਰਭਾਵਤ ਹੈ। ਬ੍ਰੈਕਟ ਲਈ ਥਾਂ ਛੱਡੋ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ (ਨਿਰਧਾਰਤ ਅੰਤ ਸਮਾਂ, ਪ੍ਰਭਾਵਤ ਖੇਤਰ, ਫੀਚਰ ਦਾ ਨਾਮ)। ਇਹ ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਜਲਦੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਸੀਵੇਤੀ ਲੇਬਲ ਚੁਣੋ ਜੋ ਹਕੀਕਤ ਨਾਲ ਮੈਚ ਕਰਦੀ ਹੋਵੇ। ਇੱਕ ਹੀ ਲੇਬਲ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਬੈਨਰ, ਸਟੇਟਸ ਪੇਜ, ਅਤੇ ਈਮੇਲ 'ਚ ਓہی ਰੱਖੋ। ਉਦਾਹਰਨ ਲਈ: Maintenance (ਯੋਜਿਤ), Partial outage (ਕੁਝ ਯੂਜ਼ਰ ਜਾਂ ਫੀਚਰ), Degraded performance (ਸਲੋ ਜਾਂ ਦੇਰੀ ਵਾਲਾ)। ਜੇ ਤੁਸੀਂ ਰੰਗ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਓਹਨਾਂ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖੋ (ਹਰਾ = ਨਾਰਮਲ, ਪੀਲਾ = ਡੀਗਰੇਡਡ, ਲਾਲ = ਆਉਟੇਜ) ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕਣ।
ਇੱਕ ਵਾਕ਼ ਜੋ ਲੇਬਲ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ 'ਚ ਸਮਝਾਵੇ ਜੋੜੋ। “Degraded” ਹਮੇਸ਼ਾਂ ਕੁਝ ਨਿਰਧਾਰਤ ਮਤਲਬ ਰੱਖੇ ਜਿਵੇਂ “ਐਕਸਪੋਰਟ 5-15 ਮਿੰਟ ਲੈ ਸਕਦੇ ਹਨ।”
ਮੁੰਮਕਿਨ ਹੋਵੇ ਤਾਂ ਵਰਕਅਰਾਊਂਡ ਦਿਓ। ਛੋਟਾ ਵਿਕਲਪ ਵੀ ਟਿਕਟਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ: “ਜੇ ਤੁਹਾਨੂੰ ਹੁਣੀ ਰਿਪੋਰਟ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਡੈਸ਼ਬੋਰਡ ਤੋਂ CSV ਡਾਊਨਲੋਡ ਵਰਤੋ ਜਦੋਂ ਸ਼ੈਡਿਊਲਡ ਐਕਸਪੋਰਟ ਦੇਰੀ ਵਿੱਚ ਹੋਣ।” ਜੇ ਕੋਈ ਵਰਕਅਰਾਊਂਡ ਨਹੀਂ ਹੈ, ਤਾਂ ਇੱਕ ਵਾਰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਕਹਿ ਦਿਓ।
ਪਬਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਅਪਡੇਟ ਪਲਾਨ ਕਰੋ। ਦੋ ਰੀਮਾਈਂਡਰ ਸ਼ੈਡਿਊਲ ਕਰੋ: ਇੱਕ ਵਿੰਡੋ ਤੋਂ ਥੋੜ੍ਹਾ ਪਹਿਲਾਂ, ਅਤੇ ਇੱਕ “ਹੁਣ ਸ਼ੁਰੂ” ਸੁਨੇਹਾ ਸਹੀ ਸ਼ੁਰੂ ਸਮੇਂ 'ਤੇ। ਜੇ ਸਮਾਂ ਬਦਲਦਾ ਹੈ, ਪਹਿਲਾਂ ਨੋਟਿਸ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਰੀਮਾਈਂਡਰ ਭੇਜੋ।
ਆਖਰੀ ਅਪਡੇਟ ਨਾਲ ਲੂਪ ਬੰਦ ਕਰੋ। ਦੱਸੋ ਕਿ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ ਰੀਸਟੋਰ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਜੇ ਕੋਈ ਚੀਜ਼ ਅਜੇ ਵੀ ਗਲਤ ਲੱਗਦੀ ਹੋਵੇ ਤਾਂ ਉਪਭੋਗਤਾ ਕੀ ਕਰੇ (ਰਿਫਰੇਸ਼, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼, ਜਾਂ ਖਾਸ ਵੇਰਵਾ ਨਾਲ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ)।
ਇਨ੍ਹਾਂ ਟੈਮਪਲੇਟਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤ ਦੇ ਨੁਕਤੇ ਵਜੋਂ ਵਰਤੋ, ਫਿਰ ਵੇਰਵੇ ਆਪਣੇ ਉਤਪਾਦ ਦੇ ਅਨੁਸਾਰ ਢਾਲੋ। ਟੋਨ ਸ਼ਾਂਤ ਅਤੇ ਸਧਾਰਨ ਰੱਖੋ। ਇਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਦਿਓ ਜੋ ਉਪਭੋਗਤਾ ਕਰ ਸਕਦੇ ਹਨ।
Subject/Title: Planned maintenance on [Day], [Date] at [Start time] [TZ]
Message: We have scheduled maintenance on [Day, Date] from [Start time] to [End time] [TZ].
During this window, [what will be unavailable]. [what will still work] will remain available.
If you need to prepare: please [recommended action, e.g., finish exports, save drafts] before [time]. We’ll post updates here during the window.
Title: Maintenance is now in progress
Message: Maintenance has started and is expected to take until [End time] [TZ].
Right now, [what is unavailable]. If you try to [common task], you may see [expected error/behavior].
Next update at [time] (or sooner if anything changes).
Title: Maintenance is taking longer than planned
Message: Maintenance is taking longer than expected. The new estimated end time is [New end time] [TZ].
What this means for you: [impact in one sentence]. What you can do now: [safe workaround or “please try again after X”].
Sorry for the disruption - we’ll share another update at [time].
Title: Maintenance is complete
Message: Maintenance is complete as of [time] [TZ].
You can now [top 2-3 key actions to verify, e.g., sign in, run an export, submit a payment]. If something still looks wrong, try [simple step like refresh/re-login] and then contact support with [what info to include, e.g., time, account, screenshot].
Title: Monitoring after maintenance
Message: Systems are back online, and we’re monitoring closely for the next [X hours].
You might notice [minor symptom, e.g., slower loading, delayed emails] while queues catch up. If you hit errors, please retry after [time].
Next update at [time] (or sooner if we spot an issue).
ਜਦ ਐਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਾਊਨ ਨਹੀਂ ਹੁੰਦਾ, ਅਸਪਸ਼ਟ ਬੈਨਰ ਸਭ ਤੋਂ ਵੱਧ ਪੈਨਿਕ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਕੀ ਪ੍ਰਭਾਵਤ ਹੈ (ਫੀਚਰ, ਖੇਤਰ, ਜਾਂ ਕਦਮ), ਕੀ ਕਾਮ ਕਰਦਾ ਰਹੇਗਾ, ਅਤੇ ਹੁਣ ਉਪਭੋਗਤੋਂ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ—ਇਹ ਸਭ ਸਪਸ਼ਟ ਕਰੋ।
Use when most of the product works, but one area doesn’t.
Template
Title: Partial outage: [feature/service] unavailable in [region/account type]
Body: We’re seeing an issue where [feature] isn’t working for [who is affected]. Other parts of the app, including [what still works], are operating normally. Our team is working on a fix.
Impact: You may see [error message/symptom] when you try to [action].
Workaround: Until this is fixed, please [safe alternative action].
Next update: By [time + timezone] (or sooner if resolved).
Use when requests succeed, but feel broken because they’re slow.
Template
Title: Degraded performance: slower than normal [area]
Body: Some actions are taking longer than usual, especially [specific actions]. You might see timeouts or retries, but data should not be lost.
What to do: If you hit an error, wait [X minutes] and try again. Avoid repeating the same action many times (it can create duplicates).
Next update: By [time + timezone].
Use when the hardest part is uncertainty.
Template
Title: Intermittent issue: [feature] may fail or succeed unpredictably
Body: We’re investigating an issue where [feature] works for some attempts but fails for others. If it fails, it’s safe to retry after [X minutes].
How to help: If you contact support, include [request ID / time range / affected region].
Use when users can’t get in. Keep it calm and direct.
Template
Title: Login issues: some users may not be able to sign in
Body: We’re seeing elevated login failures for [who is affected]. If you’re blocked, please don’t reset your password repeatedly unless you see a clear password error.
What to try: Refresh once, then wait [X minutes] and try again. If you use SSO, note whether the issue is SSO only or all login methods.
Use when users think data is missing.
Template
Title: Data delay: [reports/sync/analytics] may be behind by [X minutes/hours]
Body: New activity may take longer to appear in [area]. Your data is still being collected, but processing is delayed.
What this means: Exports/reports created during this time may be incomplete. If possible, wait until [time] to run critical reports.
Next update: By [time + timezone].
ਜਿਆਦਾਤਰ ਸਪੋਰਟ ਸਪਾਈਕਸ ਮੈਂਟੇਨੈਂਸ ਦੇ ਦੌਰਾਨ ਸੁਨੇਹੇ ਵਾਲੇ ਸ਼ਬਦਾਂ ਕਾਰਨ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਉਹਨਾਂ ਸ਼ਬਦਾਂ ਤੋਂ ਹੁੰਦੇ ਹਨ ਜੋ ਲੋਕਾਂ ਨੂੰ ਇਹ ਅਨੁਮਾਨ ਲਾਉਣ 'ਤੇ ਮਜਬੂਰ ਕਰ ਦਿੰਦੇ ਹਨ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਦੋਂ ਖਤਮ ਹੋਵੇਗਾ। ਜੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਉਹ ਟਿਕੱਟ ਖੋਲ੍ਹਦੇ ਹਨ।
ਉਹ ਨਮੂਨੇ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਪੈਨਿਕ ਪੈਦਾ ਕਰਦੇ ਹਨ:
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਤੁਹਾਡਾ ਐਕਸਪੋਰਟ ਟੂਲ ਸਲੋ ਹੈ, ਪਰ ਬਾਕੀ ਐਪ ਕੰਮ कर ਰਿਹਾ ਹੈ। ਜੇ ਤੁਹਾਡा ਬੈਨਰ कहੇ “Service outage,” ਤਾਂ ਉਹ ਯੂਜ਼ਰ ਜੋ ਐਕਸਪੋਰਟ ਨਹੀਂ ਕਰ ਰਹੇ, ਉਹ ਵੀ ਰੁਕ ਜਾਣਗੇ ਅਤੇ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰਨਗੇ। ਜੇ ਇਹ ਕਹਿੰਦਾ “ਐਕਸਪੋਰਟ 10-20 ਮਿੰਟ ਲਈ ਲੰਮੇ ਲੱਗ ਸਕਦੇ ਹਨ; ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਐਡਿਟਿੰਗ ਸਧਾਰਨ ਹਨ। ਅਗਲਾ ਅਪਡੇਟ 14:30 UTC,” ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਬਸ ਉਡੀਕ ਕਰਨਗੇ।
ਜੇ ਤੁਸੀਂ ਮੇਸੇਜ ਟੈਮਪਲੇਟ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਲਈ ਲਕੜੀ-ਸਿਲਸਿਲਾ ਰੱਖੋ ਜੋ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਛੇਤੀ ਦੇ: ਕੀ ਪ੍ਰਭਾਵਤ ਹੈ, ਹੁਣ ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਅਪਡੇਟ ਕਦੋਂ ਆਏਗਾ।
ਪਬਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸੁਨੇਹੇ ਨੂੰ ਇੱਕ ਫਿਕਰਮੰਦ ਗਾਹਕ ਵਾਂਗ ਪੜ੍ਹੋ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣਾ।
ਸੁਨਿੱਕ ਹੋਵੋ ਕਿ ਬੈਨਰ, ਈਮੇਲ, ਹੇਲਪ ਡੈੱਸਕ ਮੈਕਰੋ, ਅਤੇ ਸਟੇਟਸ ਮੈਸੇਜਿੰਗ ਵਿਚ ਵਰਡਿੰਗ ਇੱਕੋ ਜਿਹੀ ਹੋ। ਜੇ ਇੱਕ ਕਹਿੰਦਾ “ਡਿਗਰੇਡਡ” ਅਤੇ ਦੂਜਾ ਕਹਿੰਦਾ “ਡਾਊਨ,” ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੁਝ ਛਪਾ ਰਹੇ ਹੋ।
ਟੋਨ ਨੂੰ ਠੰਢਾ ਅਤੇ ਤੱਥ-ਅਧਾਰਿਤ ਰੱਖੋ। ਹਾਈਪ, ਮਜ਼ਾਕ, ਜਾਂ “ਕੋਈ ਚਿੰਤਾ ਨਹੀਂ” ਵਰਗੇ ਫਰੇਜ਼ ਤੋਂ ਬਚੋ। ਇੱਕ ਸਧਾਰਨ, ਸਥਿਰ ਲਾਈਨ ਜਿਵੇਂ “ਅਸੀਂ ਸਲੋ ਐਕਸਪੋਰਟ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ” ਉਮੀਦਾਂ ਤੋਂ ਬਿਹਤਰ ਕੰਮ ਕਰਦੀ ਹੈ।
ਕਲੀਰਿਟੀ ਟੈਸਟ ਕਰੋ: ਕੀ ਇੱਕ ਨਵਾਂ ਯੂਜ਼ਰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਆਪਣੀ ਧਾਰਣਾ ਜੋੜੇ? ਜੇ ਨਹੀਂ, ਫਿਰ ਲਿਖੋ।
ਜਦ ਇਹ ਖਤਮ ਹੋ ਜਾਵੇ, ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰੋ: ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਹੱਲ ਹੋ ਗਿਆ, ਬਹਾਲੀ ਸਮਾਂ ਦਿਓ, ਅਤੇ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਦੱਸੋ ਕਿ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ (ਉਦਾਹਰਨ: “ਆਪਣਾ ਐਕਸਪੋਰਟ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ,” ਜਾਂ “ਜੇ ਤੁਸੀਂ ਹੇਠਾਂ ਅਜੇ ਵੀ ਏਰਰ ਵੇਖਦੇ ਹੋ, ਤਾੰ ਰਿਫਰੇਸ਼ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ”)।
ਇੱਕ ਆਮ “ਸਭ ਕੁਝ ਖਰਾਬ” ਪਲ ਹੈ ਜਦ ਇੱਕ ਫੀਚਰ ਫੇਲ ਕਰਦਾ ਹੈ ਪਰ ਬਾਕੀ ਐਪ ਠੀਕ ਲੱਗਦੀ ਹੈ। ਸੋਚੋ ਇਕ ਫਾਈਨੈਂਸ ਟੂਲ: ਬਿੱਲਿੰਗ ਪੇਜ ਲੋਡ ਹੁੰਦੀ ਹੈ, ਇਨਵੌਇਸ ਦਿਖਦੇ ਹਨ, ਅਤੇ ਭੁਗਤਾਨ ਠੀਕ ਜਾ ਰਹੇ ਹਨ। ਪਰ CSV ਐਕਸਪੋਰਟ ਕੁਝ ਯੂਜ਼ਰਾਂ ਲਈ ਟਾਈਮਆਊਟ ਹੋਣ ਲੱਗਦਾ ਹੈ। ਲੋਕ ਰਿਫਰੇਸ਼ ਕਰਦੇ ਹਨ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਸਪੋਰਟ ਟਿਕੱਟ ਖੋਲ੍ਹਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸੋਚਦੇ ਹਨ ਡੇਟਾ ਗੁਆ ਚੁੱਕੀ ਹੈ।
ਪਹਿਲਾ ਸੁਨੇਹਾ ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਕੀ ਨਹੀਂ, ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੈ, ਅਤੇ ਹੁਣ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ:
“Exporting invoices to CSV is currently timing out for some accounts. Billing pages and payments are working normally. If you need data urgently, use the on-screen filters and copy results, or try exporting a smaller date range. We’re investigating and will update here in 15 minutes.”
ਅਗਲੇ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਅਪਡੇਟਾਂ ਨੂੰ “ਅਸੀਂ ਦੇਖ ਰਹੇ ਹਾਂ” ਤੋਂ “ਇਹ ਬਦਲਿਆ” ਵੱਲ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ:
ਅਖੀਰਲਾ ਸੁਨੇਹਾ ਲੂਪ ਬੰਦ ਕਰਦਾ ਹੈ। ਇਹ ਫਿਕਸ, ਸਕੋਪ, ਅਤੇ ਸਪੋਰਟ ਦੇ ਰਾਹ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ:
“Resolved: we increased export worker capacity and adjusted timeout settings. From 10:05-11:05 UTC, some CSV exports failed, but billing and payments stayed available. If you still cannot export, reply to your last ticket with the export time and invoice range.”
ਜਿਹੜੀਆਂ ਟੀਮਾਂ ਇਸ ਤਰ੍ਹਾਂ ਸੰਚਾਰ ਕਰਦੀਆਂ ਹਨ ਉਨ੍ਹਾਂ ਕੋਲ ਆਮ ਤੌਰ ਤੇ ਘੱਟ ਟਿਕੱਟ ਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਤਿੰਨ ਚੀਜ਼ਾਂ ਜਲਦੀ ਸਿੱਖ ਲੈਂਦੇ ਹਨ: ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਹੈ, ਹੁਣ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਅਗਲਾ ਅਪਡੇਟ ਕਦੋਂ ਮਿਲੇਗਾ।
ਮੈਂਟੇਨੈਂਸ ਮੈਸੇਜਿੰਗ ਨੂੰ ਇੱਕ ਇਕ-ਵਾਰੀ ਮਾਫੀ ਦੇ ਤੌਰ 'ਤੇ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਛੋਟੀ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਵਾਂਗੋ ਟ੍ਰੀਟ ਕਰੋ। ਮਕਸਦ ਇਕਸਾਰਤਾ ਹੈ: ਉਪਭੋਗਤਾ ਨੂੰ ਪੈਟਰਨ ਪਹਿਚਾਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਕਰਨਾ ਹੈ, ਅਤੇ ਭਰੋਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਸਮੇਂ 'ਤੇ ਅਪਡੇਟ ਕਰੋਗੇ।
ਆਪਣੀ ਸਿਖਰ ਦੀ ਕਾਪੀ ਨੂੰ ਮੁੜ-ਉਪਯੋਗ ਬਲਾਕਾਂ ਵਿੱਚ ਬਦਲੋ ਜਿਸ ਵਿੱਚ ਸਪਸ਼ਟ ਵੇਰੀਏਬਲ ਹੋਣ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਇਕ ਥਾਂ ਰੱਖੋ ਤਾਂ ਕਿ ਟੀਮ ਦਾ ਕੋਈ ਵੀ ਮੈਂਬਰ ਨੋਟਿਸ ਬਿਨਾਂ ਨਵਾਂ ਲਿਖੇ ਪਬਲਿਸ਼ ਕਰ ਸਕੇ। ਸ਼ੁਰੂਆਤੀ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਜਿਵੇਂ ਸ਼ੁਰੂ ਸਮਾਂ, ਅਨੁਮਾਨਿਤ ਅੰਤ ਸਮਾਂ, ਪ੍ਰਭਾਵਤ ਫੀਚਰ, ਖੇਤਰ, ਅਤੇ ਕੌਣ ਪ੍ਰਭਾਵਤ ਹੈ (ਸਾਰੇ ਯੂਜ਼ਰ ਜਾਂ ਕੋਈ ਉਪਸੈਟ) ਨੂੰ ਮਿਆਰੀਕਰਣ ਕਰੋ।
ਦਾਅਵਾ ਅਤੇ ਇੱਕ ਸਧਾਰਾ ਅਨੁਮੋਦਨ ਫਲੋ ਲਿਖੋ। ਇੱਕ ਵਿਅਕਤੀ ਡਰਾਫਟ ਕਰੇ, ਇੱਕ ਮਨਜ਼ੂਰ ਕਰੇ, ਅਤੇ ਇੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇ, ਭਾਵੇਂ ਛੋਟੀ ਟੀਮਾਂ ਵਿੱਚ ਇਹ ਇਕੋ ਵਿਅਕਤੀ ਹੋ ਸਕਦੇ ਹਨ। ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਅਪਡੇਟ ਕੈਡੈਂਸ ਪਹਿਲਾਂ ਤੋਂ ਸੈਟ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਹਰ 30 ਮਿੰਟ) ਤਾਂ ਕਿ ਸਪੋਰਟ ਅਨੁਮਾਨ ਨਾ ਲਗਾਏ ਕਿ ਅਗਲਾ ਸੁਨੇਹਾ ਕਦੋਂ ਆਏਗਾ।
“Snapshots” ਅਤੇ “rollback” ਭਾਸ਼ਾ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਕੇਵਲ ਉਹੀ ਵਾਅਦੇ ਕਰੋ ਜੋ ਤੁਸੀਂ ਦੇਣ ਯੋਗ ਹੋ। ਜੇ ਰੋਲਬੈਕ ਸੰਭਵ ਹੈ ਪਰ ਗਾਰੰਟੀ ਨਹੀਂ, ਤਾਂ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕਹੋ ਅਤੇ ਉਪਭੋਗਤਿਆਂ ਲਈ ਜਿਸ 'ਤੇ ਉਹ ਭਰੋਸਾ ਕਰ ਸਕਣ ਉੱਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇਹ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਵਾਰੀ ਡਿਲਿਵਰੀ ਪੁਇੰਟਸ ਬਣਾਉ: ਇੱਕ ਇਨ-ਐਪ ਬੈਨਰ ਕੰਪੋਨੈਂਟ, ਇੱਕ ਹਲਕੀ ਫੁਲਕੀ ਸਟੇਟਸ ਪੇਜ, ਅਤੇ ਇੱਕ ਪੋਸਟ-ਮੈਂਟੇਨੈਂਸ “ਆਲ ਕਲਿਆਰ” ਫਲੋ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ Koder.ai (koder.ai) ਨਾਲ ਪ੍ਰੋਡਕਟ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਨ UI ਟੁਕੜੇ ਅਤੇ ਅਪਡੇਟ ਫਲੋ ਇੱਕ ਚੈਟ-ਚਲਾਏ ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਬਣਾਈਆ ਅਤੇ ਫਿਰ ਕਾਪੀ ਅਤੇ ਵੇਰੀਏਬਲ ਬਿਨਾਂ ਪੂਰੀ ਐਪ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਦੇ ਬਦਲ ਸਕਦੇ ਹੋ।
ਅੰਤ ਵਿੱਚ, ਨੀਚੇ ਇੱਕ ਘੱਟ-ਖਤਰੇ ਵਾਲੀ ਮੈਂਟੇਨੈਂਸ ਵਿੰਡੋ ਦੌਰਾਨ ਇੱਕ ਡ੍ਰਾਈ ਰਨ ਚਲਾਓ। ਅਸਲ ਟੈਮਪਲੇਟ ਵਰਤੋ, ਹਕੀਕਤੀ ਸਰਫੇਸਾਂ 'ਤੇ ਪਬਲਿਸ਼ ਕਰੋ, ਅਪਡੇਟ ਦਾ ਸਮਾਂ ਮਾਪੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜੋ ਹੋਇਆ ਉਸਦਾ ਸਮੀਖਿਆ ਕਰੋ:
ਇਕ ਵਾਰੀ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਲੂਪ ਹੋ ਜਾਵੇ, ਤੁਹਾਡੇ ਟੈਮਪਲੇਟ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਰਹਿੰਦੇ; ਉਹ ਇੱਕ ਆਦਤ ਬਣ ਜਾਂਦੇ ਹਨ।
Start with what’s affected, how long it will last, and what the user should do right now. A plain line like “Exports may take 10–20 minutes longer; dashboards work normally; next update at 14:30 UTC” prevents guessing and cuts tickets.
Use Maintenance for planned work with a defined window, Partial outage when a specific feature/region is down, and Degraded performance when things work but are slow or error-prone. Pick the label that matches what users feel, not the internal cause.
Write what the user will notice in one sentence, then quantify it if you can. For example: “Exports may take 10–30 minutes and may time out on large date ranges,” instead of “We’re seeing degraded performance.”
Use an in-app banner for most situations so people can keep working. Use a modal only when continuing could cause errors or lost work (like billing actions or data edits), and keep a persistent banner afterward so the message doesn’t disappear.
Put the same message on the login screen whenever sign-in might fail, because that’s where panic starts. If you only post updates inside the app, locked-out users will assume their account is broken and flood support.
Avoid false certainty like “No impact expected” unless you’re truly sure. Say what you know, what you don’t know yet, and when you’ll update next; that honesty reads as competence, not weakness.
Always include a specific next update time, even if nothing changes. “Next update in 20 minutes” sets a promise users can rely on and reduces the refresh-and-ticket cycle.
Give one safe action that reduces risk and duplicates. For example: “Retry once after 2 minutes,” “Avoid repeating the same export,” or “Use a smaller date range,” and if there’s no workaround, say so clearly once.
State what’s affected, what still works, and what to do if they’re blocked. Tell users not to do high-risk actions repeatedly (like password resets or repeated submissions) unless the message specifically tells them to.
Close with an explicit “resolved” note that includes the time, what was restored, and what to try if something still looks wrong (refresh, re-login, retry once). If users may still see edge cases, say you’re monitoring and when you’ll post the final confirmation.
