ਇੱਕ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਵਰਤੋ ਤਾਂ ਜੋ ਫੋਟੋਆਂ ਕੈਪਚਰ ਹੋਣ, ਜ਼ਿੰਮੇਵਾਰੀ ਨਿਰਧਾਰਿਤ ਹੋਵੇ, ਅਤੇ ਇੰਟੇਕ ਤੋਂ ਵਾਪਸੀ ਤੱਕ ਮਰammat ਟਰੈਕ ਕੀਤਾ ਜਾ ਸਕੇ, ਤਾਂ ਜੋ ਡਿਵਾਈਸ ਗੁੰਮ ਨਾ ਹੋਣ।
ਕਲਾਸਰੂਮ ਦਾ ਇੱਕ ਡਿਵਾਈਸ ਆਮ ਤੌਰ 'ਤੇ ਨਾਟਕੀਆ ਢੰਗ ਨਾਲ “ਗੁੱਬ” ਨਹੀਂ ਹੁੰਦਾ। ਜ਼ਿਆਦਾਤਰ ਵਾਰ, ਇਹ ਇੱਕ ਵਿਅਸਤ ਦਿਨ ਮਗਰੋਂ ਦਿਸ਼ਾ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਣਦਾ ਹੈ: ਕਿਸੇ ਨੇ ਕ੍ਰੈਕ ਸਕ੍ਰੀਨ ਦੀ ਗੱਲ ਕੀਤੀ, ਡਿਵਾਈਸ ਡੈਸਕ 'ਤੇ ਰੱਖ ਦਿੱਤਾ ਗਿਆ, ਅਤੇ ਫਿਰ ਇਹ ਕਈ ਹੱਥਾਂ ਵਿਚੋਂ ਲੰਘਦਾ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਸਪਸ਼ਟ ਰਿਕਾਰਡ ਦੇ।
ਮੁਢਲਾ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਰਿਪੋਰਟ ਅਤੇ ਡਿਵਾਈਸ ਅਲੱਗ-ਅਲੱਗ ਯਾਤਰਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਵਿਦਿਆਰਥੀ ਅਧਿਆਪਕ ਨੂੰ ਦੱਸਦਾ ਹੈ, ਅਧਿਆਪਕ IT ਨੂੰ ਈਮੇਲ ਕਰਦਾ ਹੈ, IT ਸੀਰੀਅਲ ਨੰਬਰ ਮੰਗਦਾ ਹੈ, ਅਤੇ ਡਿਵਾਈਸ ਇੱਕ ਦਰਾਜ਼ ਵਿੱਚ ਬੈਠਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਸਾਰੇ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਇੱਕ ਹਫ਼ਤਾ ਬਾਅਦ, ਕੋਈ ਯਾਦ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਸਨੂੰ ਲਿਆ ਗਿਆ ਸੀ, ਮੁਰੰਮਤ ਹੋਈ ਸੀ ਜਾਂ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਸੀ।
ਈਮੇਲ ਇਸਨੂੰ ਹੋਰ ਭੀ ਖ਼ਰਾਬ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਗੱਲਬਾਤ ਲਈ ਬਣੀ ਹੈ, ਨਾਂ ਕਿ ਟਰੈਕਿੰਗ ਲਈ। ਵੇਰਵੇ ਜਵਾਬਾਂ ਵਿੱਚ ਫੈਲ ਜਾਂਦੇ ਹਨ, ਫੋਟੋਆਂ ਗੁੰਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਨਵੇਂ ਕਰਮਚਾਰੀ ਪੂਰੇ ਮਾਮਲੇ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦੇ। ਜੇ ਡਿਵਾਈਸ ਕਮਰੇ, ਇਮਾਰਤ ਜਾਂ ਸਬਸਟੀਟਿਊਟ ਨੂੰ ਮਿਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਾਗਜ਼ੀ ਟਰੇਲ ਟੁੱਟ ਜਾਂਦੀ ਹੈ।
ਔਰ ਨੀਮ ਹੁਣੇ ਹੀ ਮੁੜ-ਮੁੜ ਦਰਸਾਈਆਂ ਜਾਂਦੀਆਂ ਗਲਤੀਆਂ ਹਨ:
ਇੱਕ ਚੰਗਾ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਇਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ: “ਕਿਸੇ ਨੇ ਕਿਹਾ ਇਹ ਟੁੱਟਿਆ” ਨੂੰ ਇੱਕ ਇਕੱਲੀ ਰਿਕਾਰਡ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜੋ ਡਿਵਾਈਸ ਦੇ ਨਾਲ ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਥਾਂ ਤੇ ਕੀ ਹੋਇਆ ਲਗਾਓ, ਫੋਟੋ ਜੁੜੋ, ਅਤੇ ਹਰ ਹਵਾਲੇ ਨੂੰ ਨੋਟ ਕਰੋ—ਇਸ ਨਾਲ ਜਵਾਬ ਤੁਰੰਤ ਮਿਲ ਜਾਣਗੇ: ਇਹ ਕਿੱਥੇ ਹੈ? ਕੀ ਖਰਾਬ ਹੈ? ਅਸੀਂ ਕਿਸ ਚੀਜ਼ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ?
ਕੁਝ ਸਕੂਲ ਇਸਨੂੰ ਇੱਕ ਸਾਹਮਣੇ-ਸਾਧਾ ਅੰਦਰੂਨੀ ਟੂਲ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਫਾਰਮ, ਸਥਿਤੀ ਅੱਪਡੇਟ ਅਤੇ ਮਰammat ਇਤਿਹਾਸ ਇਕੱਠੇ ਰਹਿਣ। ਉਦਾਹਰਣ ਲਈ, ਟੀਮਾਂ ਕਈ ਵਾਰੀ Koder.ai ਵਰਤ ਕੇ ਆਪਣੇ ਵਰਕਫਲੋ ਅਨੁਸਾਰ ਇੱਕ ਲਾਈਟਵੇਟ ਟਰੈਕਰ ਚੈਟ-ਬਿਲਡ ਕਰਦੀਆਂ ਹਨ। ਟੂਲ ਘੱਟ ਮਹੱਤਵਪੂਰਣ ਹੈ—ਆਦਤ ਜ਼ਰੂਰੀ ਹੈ: ਇੱਕ ਰਿਪੋਰਟ, ਇੱਕ ਡਿਵਾਈਸ, ਇੱਕ ਟਾਈਮਲਾਈਨ।
ਇੱਕ ਚੰਗਾ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਇੱਕ ਸਵਾਲ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਵੇ: ਇਹ ਠੀਕ ਕਿਹੜਾ ਡਿਵਾਈਸ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਭਾਗ ਧੁੰਦਲਾ ਹੋਵੇ, ਤਾਂ ਡਿਵਾਈਸ ਦਰਾਜ਼ ਵਿੱਚ ਬੈਠ ਸਕਦਾ ਹੈ, ਗਲਤ ਕਾਰਟ ਵਿੱਚ ਵਾਪਸ ਚਲੇ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਰਿਕਾਰਡ ਤੋਂ ਬਿਨਾਂ “ਉਧਾਰ” ਮਿਲ ਸਕਦਾ ਹੈ।
ਪਹਿਲਾਂ ਐਸੇ ਪਛਾਣ-ਸੂਤਰ ਲਿਖੋ ਜੋ ਯਾਦ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਣ: ਐਸੈੱਟ ਟੈਗ (ਸਟਾਫ਼ ਦੇਖ ਸਕਦੇ ਹਨ), ਸੀਰੀਅਲ ਨੰਬਰ (ਵਾਰੰਟੀ ਅਤੇ ਵੈਂਡਰ ਰਿਪੇਅਰ ਲਈ), ਅਤੇ ਡਿਵਾਈਸ ਮਾਡਲ। ਜੇ ਸਕੂਲ ਕਾਰਟ ਵਰਤਦੇ ਹਨ, ਤਾਂ ਕਾਰਟ ਨੰਬਰ ਅਤੇ ਸਲਾਟ ਪੋਜ਼ੀਸ਼ਨ ਵੀ ਜੋੜੋ ਤਾਂ ਕਿ ਸਟਾਫ਼ ਮਰammat ਮਗਰੋਂ ਸਹੀ ਢੰਗ ਨਾਲ ਵਾਪਸ ਰੱਖ ਸਕਣ।
ਫਿਰ ਉਹਨਾਂ ਦੀ ਪਕੜ ਲਿਖੋ ਜਿਨ੍ਹਾਂ ਕੋਲ ਡਿਵਾਈਸ ਸੀ ਜਦੋਂ ਸਮੱਸਿਆ ਨੋਟੀਸ ਹੋਈ: ਵਿਦਿਆਰਥੀ ਦਾ ਨਾਮ ਜਾਂ ID, ਅਧਿਆਪਕ, ਕਲਾਸ ਪੀਰੀਅਡ, ਅਤੇ ਰੂਮ ਨੰਬਰ। ਇਹ ਵੇਰਵੇ ਨਿਰਧਾਰਤ ਪੈਟਰਨ (ਉਹੀ ਕਮਰਾ, ਓਹੀ ਕਾਰਟ, ਇਕੋ ਸਮਾਂ) ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਨੂੰ ਦੋਸ਼ੀ ਬਣਾਉਣ ਦੇ।
ਇਨਸਿਡੈਂਟ ਲਈ, ਸੰਖੇਪ ਅਤੇ ਸਪਸ਼ਟ ਰਖੋ: ਕੀ ਹੋਇਆ, ਕਦੋਂ, ਅਤੇ ਕਿੱਥੇ। ਇੱਕ ਵਾਕ ਜਿਵੇਂ “Room 204 ਵਿੱਚ 3rd period ਦੌਰਾਨ ਡੈਸਕ ਤੋਂ ਡਿੱਗਿਆ” ਲੰਮੇ ਕਹਾਣੀ ਨਾਲੋਂ ਵਧੇਰੇ ਉਪਯੋਗੀ ਹੈ।
ਇਕ ਛੋਟਾ ਯੂਜ਼ਬਿਲਟੀ ਫੀਲਡ ਜੋੜੋ ਤਾਂ ਕਿ IT ਤੁਰੰਤ ਤਯਾਰ ਕਰ ਸਕੇ:
ਅਖੀਰ 'ਤੇ, ਤੁਰੰਤ ਕੀ ਕਾਰਵਾਈ ਕੀਤੀ ਗਈ ਉਸਨੂੰ ਰਿਕਾਰਡ ਕਰੋ: ਕੀ ਡਿਵਾਈਸ ਬੰਦ ਕੀਤਾ ਗਿਆ, ਸਟਾਫ਼ ਨੇ ਇਕੱਠਾ ਕੀਤਾ, ਲੇਬਲ ਕੀਤਾ ਗਿਆ ਬਿਨ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ, ਅਤੇ ਕੀ ਲੋਨਰ ਦਿੱਤਾ ਗਿਆ। ਉਦਾਹਰਣ: “Power off ਕੀਤਾ, ਟੈਗ ਕੀਤਾ, ਲੋਨਰ Chromebook #C-118 ਵਿਦਿਆਰਥੀ ਨੂੰ ਦਿੱਤਾ।”
ਫੋਟੋਆਂ ਇੱਕ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਨੂੰ ਜ਼ਿਆਦਾ ਭਰੋਸੇਮੰਦ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਇਹਨਾਂ ਗੱਲਾਂ ਨੂੰ ਘੱਟ ਕਰਦੀਆਂ ਹਨ: ਕੀ ਹੋਇਆ ਬਾਰੇ ਝਗੜੇ, IT ਨੂੰ ਸਹੀ ਪਾਰਟ ਆਰਡਰ ਕਰਨ ਵਿੱਚ ਮਦਦ, ਅਤੇ ਜੇ ਨੁਕਸਾਨ ਬਾਅਦ ਵਿੱਚ ਵਧਦਾ ਹੈ ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ “ਪਹਿਲਾਂ” ਰਿਕਾਰਡ।
ਫੋਟੋ ਸੈੱਟ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਕੇਸਾਂ ਵਿੱਚ 2 ਤੋਂ 4 ਫੋਟੋ ਕਾਫੀ ਹੁੰਦੀਆਂ ਹਨ ਜੇ ਉਹ ਨੁਕਸਾਨ ਨੂੰ ਸਾਫ਼ ਦਿਖਾਉਂਦੀਆਂ ਹਨ:
ਕੁਝ ਆਦਤਾਂ ਫੋਟੋਆਂ ਨੂੰ ਵਧੇਰੇ ਉਪਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਚਮਕਦਾਰ, ਇਕਸਾਰ ਰੋਸ਼ਨੀ ਵਿੱਚ ਲਓ; ਡਿਵਾਈਸ ਨੂੰ ਸਥਿਰ ਰੱਖੋ; ਫੋਕਸ ਲਈ ਟੈਪ ਕਰੋ; ਅਤੇ ਚਮਕ ਘਟਾਣ ਲਈ ਥੋੜ੍ਹਾ ਝੁਕਾਓ। ਜੇ ਨੁਕਸਾਨ ਛੋਟਾ ਹੈ (ਜਿਵੇਂ ਕਿਨਾਰੇ 'ਤੇ ਚਿੱਪ), ਤਾਂ ਇੱਕ ਵਿਆਪਕ ਤਸਵੀਰ ਸੰਦਰਭ ਲਈ ਅਤੇ ਇੱਕ ਨਜ਼ਦੀਕੀ-ਸ਼ਾਟ ਵੇਰਵਾ ਲਈ ਲਓ।
ਪ੍ਰਾਈਵੇਸੀ ਪਰਫੈਕਟ ਸਬੂਤ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਵਿਦਿਆਰਥੀ ਦੇ ਚਿਹਰੇ, ਪਰਿਬਿੰਬ ਜੋ ਚਿਹਰੇ ਦਿਖਾਉਂਦੇ ਹਨ, ਨਾਮ ਟੈਗ, ਵਿਦਿਆਰਥੀ ID ਕਾਰਡ, ਅਤੇ ਸਕ੍ਰੀਨ 'ਤੇ ਕੋਈ ਵੀ ਗੋਪਨੀਯ ਜਾਣਕਾਰੀ ਜਿਵੇਂ ਗਰੇਡ, ਸੁਨੇਹੇ ਜਾਂ ਸਿਹਤ ਜਾਣਕਾਰੀ ਤੋਂ ਬਚੋ। ਜੇ ਕੋਈ ਨਾਮ ਜਾਂ ਦਸਤਾਵੇਜ਼ ਦਿੱਸ ਰਿਹਾ ਹੈ, ਤਾਂ ਸਕ੍ਰੀਨ ਬੰਦ ਕਰਕੇ ਫੋਟੋ ਦੁਬਾਰਾ ਲਓ ਜਾਂ ਸੰਵੇਦੀ ਭਾਗ ਨੂੰ ਸਫ਼ੇ ਨਾਲ ਢੱਕੋ।
ਬੇਕਾਰੀ ਸਮੱਸਿਆਵਾਂ (ਰੈਂਡਮ ਰੀਸਟਾਰਟ, ਫਲਿੱਕਰਿੰਗ, ਟਚ ਨਾਹ ਚੱਲਣਾ) ਲਈ ਇੱਕ ਛੋਟੀ 5 ਤੋਂ 10 ਸਕਿੰਟ ਦੀ ਵੀਡੀਓ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਸਿਰਫ ਜੇ ਇਹ ਸਿਰਫ਼ ਡਿਵਾਈਸ ਅਤੇ ਲਕੜੀ ਸਮੱਸਿਆ ਨੂੰ ਦਿਖਾਏ ਅਤੇ ਕੁਝ ਹੋਰ ਨਾ ਸ਼ਾਮਿਲ ਹੋਵੇ।
ਉਦਾਹਰਣ: ਇੱਕ ਵਿਦਿਆਰਥੀ ਨੇ ਟੈਬਲੇਟ 'ਤੇ ਕ੍ਰੈਕ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ। ਅਧਿਆਪਕ ਇੱਕ ਫਰੰਟ ਫੋਟੋ ਸਕ੍ਰੀਨ ਬੰਦ ਰੱਖ ਕੇ, ਇੱਕ ਪਿੱਛੋਂ ਦੀ ਤਸਵੀਰ ਜਿਸ ਵਿੱਚ ਕੋਨਾ ਦਿੱਖ ਰਿਹਾ ਹੈ, ਅਤੇ ਕ੍ਰੈਕ ਦਾ ਨਜ਼ਦੀਕੀ-ਸ਼ਾਟ ਲੈਂਦਾ ਹੈ। IT ਲਈ ਮੁਰammat ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇਹ ਕਾਫੀ ਹੈ ਬਿਨਾਂ ਵਿਦਿਆਰਥੀ ਡੇਟਾ ਇਕੱਠਾ ਕੀਤੇ।
ਮਰammat ਪ੍ਰਕਿਰਿਆ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰ੍ਹਾਂ ਠੰਢੀ ਅਤੇ ਦੁਹਰਾਓਯੋਗ ਹੋਣ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ। ਲਕਸ਼ ਇੱਕੋ-ਹੈ: ਹਰ ਡਿਵਾਈਸ ਇੱਕੋ ਹੀ ਕਦਮਾਂ ਵਿੱਚੋਂ ਲੰਘੇ, ਅਤੇ ਕੋਈ ਵੀ ਵੇਖ ਸਕੇ ਕਿ ਇਹ ਹੁਣ ਕਿੱਥੇ ਹੈ। ਤੁਹਾਡਾ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮਜ਼ ਚੇਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਪਰ ਵਰਕਫਲੋ ਇਸਨੂੰ ਰੁਕੇਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਕੁਝ ਸਥਿਤੀਆਂ ਦੀ ਇੱਕ ਛੋਟੀ ਲਿਸਟ ਵਰਤੋ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਲਈ ਇੱਕ ਮਾਲਿਕ ਨਿਯਤ ਕਰੋ:
ਇੱਕ ਡਿਵਾਈਸ ਨੂੰ Reported ਤੋਂ ਅੱਗੇ ਨਹੀਂ ਜਾਣ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਮੰਗੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਸਮਾਂ ਤੇ ਬਰਬਾਦ ਨਾ ਹੋਵੇ: ਐਸੈੱਟ ਟੈਗ ਜਾਂ ਸੀਰੀਅਲ ਨੰਬਰ, ਮੌਜੂਦਾ ਟਿਕਾਣਾ, ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਾਫ਼ ਫੋਟੋ, ਅਤੇ ਕੀ ਹੋਇਆ ਉਸ ਦੀ ਇੱਕ ਛੋਟੀ ਵਰਣਨਾ ਅਤੇ ਕਦੋਂ। ਜੇ ਕੁਝ ਗ਼ਾਇਬ ਹੈ, ਤਾਂ ਰਿਕਾਰਡ ਪੂਰਾ ਹੋਣ ਤੱਕ ਸਥਿਤੀ ਨੂੰ ਉੱਥੇ ਰੱਖੋ।
ਲੋਨਰ ਅਤੇ ਸਵੈਪ ਉਹਨਾਂ ਥਾਵਾਂ ਹਨ ਜਿੱਥੇ ਡਿਵਾਈਸ ਅਕਸਰ ਗੁੰਮ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਵੈਪ ਨੂੰ ਦੋ ਟ੍ਰੈਕ ਕੀਤੀਆਂ ਚਲਾਂ ਵਾਂਗ ਵਰਤੋਂ: ਖਰਾਬ ਡਿਵਾਈਸ ਇਕੱਠੀ ਕੀਤੀ ਜਾਵੇ, ਅਤੇ ਇੱਕ ਲੋਨਰ ਚੈੱਕ ਆਊਟ ਕੀਤਾ ਜਾਵੇ। ਲੋਨਰ ਦਾ ਐਸੈੱਟ ਟੈਗ, ਕਿਸ ਕੋਲ ਹੈ, ਉਮੀਦਿਤ ਵਾਪਸੀ ਤਾਰੀਖ, ਅਤੇ ਮੂਲ ਡਿਵਾਈਸ ਵਾਪਸ ਆਉਣ 'ਤੇ ਕੀ ਹੋਵੇਗਾ, ਇਹ ਸਾਰਾ ਰਿਕਾਰਡ ਕਰੋ। ਜਦੋਂ ਮੁਰammat ਵਾਪਸ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਲੋਨਰ ਨੂੰ ਇੱਕੋ ਦਿਨ ਵਾਪਸੀ ਮਾਰਕ ਕੀਤਾ ਜਾਵੇ।
ਨੋਟਸ ਇਕ ਸਥਾਨ ਵਿੱਚ ਰੱਖੋ, ਸਥਿਤੀ ਦੇ ਉਹੀ ਰਿਕਾਰਡ ਵਿੱਚ। ਵੈਂਡਰ ਕੋਟਸ, ਮਰammat ਫੈਸਲੇ, ਅਤੇ “ਮਾਪੇ ਨੂੰ ਕਾਲ ਕੀਤਾ” ਅੱਪਡੇਟਸ ਨੂੰ ਇੱਥੇ ਰੱਖੋ, ਈਮੇਲ ਥ੍ਰੈੱਡ ਵਿੱਚ ਨਹੀਂ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਰਿਪੋਰਟ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਉਹ ਹੈ ਜੋ ਲੋਕ ਵਾਸਤੇ ਅਸਲ ਸਮੇਂ 'ਤੇ ਵਰਤਣਗੇ। ਬਹੁਤ ਸਕੂਲ ਹਰ ਡਿਵਾਈਸ ਕਾਰਟ 'ਤੇ QR ਕੋਡ ਲਗਾਉਂਦੇ ਹਨ, ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਸਾਂਝਾ ਇੰਟੇਕ ਟੈਬਲੇਟ ਰੱਖਦੇ ਹਨ, ਜਾਂ ਸਟਾਫ਼ ਪੋਰਟਲ ਵਿੱਚ ਇੱਕ ਸ਼ਾਰਟਕੱਟ ਜੋੜਦੇ ਹਨ।
ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਜ਼ਰੂਰੀ ਫੀਲਡ ਸਪੱਸ਼ਟ ਅਤੇ ਤੇਜ਼ ਹੋਣ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਪਰ ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਫਾਲੋ-ਅੱਪ ਕਾਲ ਦੇ ਬਿਨਾਂ ਡਿਵਾਈਸ ਦੀ ਪਛਾਣ ਅਤੇ ਕੀ ਹੋਇਆ ਜਾਣ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸਾਦਾ ਲਾਜ਼ਮੀ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
ਫੋਟੋ ਅਪਲੋਡ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਸੀਮਾ ਜੋੜੋ। ਦੋ ਤੋਂ ਤਿੰਨ ਫੋਟੋ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦੀਆਂ ਹਨ: ਇੱਕ ਪੂਰਾ ਡਿਵਾਈਸ, ਇੱਕ ਨਜ਼ਦੀਕੀ ਨੁਕਸਾਨ, ਅਤੇ (ਜੇ ਲੋੜ ਹੋਵੇ) ਸਮੱਸਿਆ ਦਿਖਾਉਂਦੀ ਸਕ੍ਰੀਨ। ਅਪਲੋਡ ਤੀਜ਼ ਰਹਿਣ ਲਈ ਸਾਈਜ਼ ਲਿਮਿਟ ਰੱਖੋ ਤਾਂ ਕਿ ਸਕੂਲ Wi-Fi 'ਤੇ ਵੀ ਫਾਸਟ ਰਹੇ।
ਜਦੋਂ ਫਾਰਮ ਸਬਮਿਟ ਹੁੰਦਾ ਹੈ, ਤੁਰੰਤ ਇੱਕ ਟਿਕਟ ਨੰਬਰ ਅਤੇ ਮਾਲਿਕ ਨਿਯਤ ਕਰੋ। ਪਹਿਲਾਂ ਇਹ “IT ਕਿਊ” ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਕਿਸੇ ਵਿਅਕਤੀਗਤ ਟੈਕਨਿਸ਼ਨ ਨੂੰ ਰੀਅਸਾਇਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਰਿਪੋਰਟ ਦਾ ਇੱਕ ਘਰ ਹੋਵੇ, ਭਾਵੇਂ ਮਰammatੋਂ ਪਹਿਲਾਂ।
ਕੇਸਮੇਸ, ਸਰਲ ਰਸੀਦ ਸੁਨੇਹਾ ਦਿਖਾਓ ਜਿਸ ਤੇ ਸਟਾਫ਼ ਕਾਰਵਾਈ ਕਰ ਸਕੇ: ਟਿਕਟ ਨੰਬਰ ਅਤੇ ਅਗਲਾ ਕਦਮ ਸਪੱਸ਼ਟ ਬੋਲੀਆਂ ਵਿੱਚ (ਉਦਾਹਰਣ: “ਡਿਵਾਈਸ ਨੂੰ ਅੱਗੇ ਦਫ਼ਤਰ ਦੇ ਰਿਪੇਅਰ ਬਿਨ ਵਿੱਚ ਛੱਡੋ”)।
ਅਖੀਰ 'ਚ, ਖੁੱਲ੍ਹੇ ਰਿਪੇਅਰਾਂ ਦੀ ਇੱਕ ਬੁਨਿਆਦੀ ਦ੍ਰਿਸ਼ਟੀ ਬਣਾ ਲਵੋ। ਇਸਨੂੰ ਫੈਨਸੀ ਚਾਰਟ ਦੀ ਲੋੜ ਨਹੀਂ—ਸਿਰਫ ਫਿਲਟਰ ਹੋਣ ਚਾਹੀਦੇ ਹਨ: ਨਵਾਂ, ਪਾਰਟਾਂ ਦੀ ਉਡੀਕ, ਵਾਪਸੀ ਲਈ ਤਿਆਰ, ਅਤੇ ਓਵਰਡਿਊ।
ਉਦਾਹਰਣ: ਇੱਕ ਅਧਿਆਪਕ Chromebook ਕਾਰਟ ਦੇ QR ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ, ਇੱਕ ਕ੍ਰੈਕ ਹੋਏ ਹੀੰਜ ਦੀਆਂ ਦੋ ਫੋਟੋਆਂ ਸਬਮਿਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਿਕਟ #1047 ਮਿਲਦਾ ਹੈ। ਡਿਵਾਈਸ ਦਫਤਰ ਬਿਨ ਵਿੱਚ ਰੱਖ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤੇ IT ਤੁਰੰਤ ਖੁੱਲ੍ਹੀ ਸੂਚੀ 'ਚ ਦੇਖ ਸਕਦਾ ਹੈ ਬਜਾਏ ਇਸਦੇ ਕਿ ਇਹ ਹਫ਼ਤਿਆਂ ਤੱਕ ਕਲਾਸਰੂਮ ਕੋਨੇ ਵਿੱਚ ਪੈ ਰਹੇ।
ਮਰammat ਪ੍ਰਕਿਰਿਆ ਫੇਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਡਿਵਾਈਸ ਕਲਾਸਰੂਮ ਛੱਡ ਦੇਂਦਾ ਹੈ ਅਤੇ ਕੋਈ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ: ਇਹ ਹੁਣ ਕਿੱਥੇ ਹੈ, ਆਖ਼ਰੀ ਵਾਰੀ ਕਿਸ ਨੇ ਛੁਹਿਆ, ਅਤੇ ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ। ਤੁਹਾਡੀ ਟਰੈਕਿੰਗ ਵਿਊ ਨੂੰ ਇਹ ਜਵਾਬ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਸਪਸ਼ਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਸਟਾਫ਼ ਲਈ, ਸੂਚੀ ਸਿਮਪਲ ਰੱਖੋ ਤਾਂ ਉਹ ਅਸਲ ਵਿੱਚ ਇਸਦਾ ਉਪਯੋਗ ਕਰਨ। ਉਹਨਾਂ ਨੂੰ ਡਿਵਾਈਸ ID, ਮਾਡਲ, ਮੌਜੂਦਾ ਸਥਿਤੀ, ਆਖ਼ਰੀ ਅਪਡੇਟ ਦੀ ਤਾਰੀਖ (ਅਤੇ ਜਿਸਨੇ ਅਪਡੇਟ ਕੀਤਾ), ਨਿਯੁਕਤ ਮਾਲਿਕ, ਮੌਜੂਦਾ ਟਿਕਾਣਾ, ਅਤੇ ਉਮੀਦਿਤ ਵਾਪਸੀ ਤਾਰੀਖ (ਭੀ ਅੰਦਾਜ਼ਾ ਹੋ ਸਕਦਾ ਹੈ) ਵੇਖਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
IT ਲਈ ਇਕ ਡੂੰਘੀ ਦ੍ਰਿਸ਼ਟੀ ਲੋੜੀਦੀ ਹੈ ਤਾਂ ਕਿ ਅਚਾਨਕ ਖਰਚੇ ਜਾਂ ਦੁਹਰਾਈ ਕੰਮ ਦੂਰ ਰਹਿਣ। ਉਹੀ ਰਿਕਾਰਡ ਵਿੱਚ ਖੇਤਰ ਜੋ ਫੈਸਲੇ ਵਿੱਚ ਮਦਦ ਕਰਨ: ਪ੍ਰਾਇਰਿਟੀ (ਕਲਾਸਰੂਮ-ਆਵਸ਼ਯਕ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲਾ), ਲੋੜੀਂਦੇ ਪਾਰਟ ਅਤੇ ਕੀ ਉਹ ਆਰਡਰ ਹੋ ਚੁੱਕੇ, ਮਰammat ਮਾਰਗ (ਇਨ-ਹਾਊਸ vs ਬਾਹਰੀ), ਵਾਰੰਟੀ ਨੋਟਸ, ਅਤੇ ਛੋਟਾ ਟੈਕ ਨੋਟਸ।
ਲਗਤ ਅਤੇ ਸਮਾਂ ਦਰਜ ਕਰਨ ਲਈ ਤੇਜ਼ ਰੇਂਜੇ ਵਰਤੋ (0 ਤੋਂ 15 ਮਿੰਟ, 15 ਤੋਂ 60, 1 ਤੋਂ 3 ਘੰਟੇ) ਅਤੇ ਇੱਕ ਸਿਰਫ਼ ਪਾਰਟਾਂ ਲਈ ਖਰਚ ਫੀਲਡ। ਜੇ ਬਾਅਦ ਵਿੱਚ ਸਹੀ ਨੰਬਰ ਚਾਹੀਦੇ ਹੋਣ, ਤਾਂ IT ਉਹਨਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਵੇਲੇ ਭਰ ਸਕਦਾ ਹੈ।
ਸਟਾਲ ਹੋਏ ਸਥਿਤੀਆਂ ਨੂੰ ਰਿਮਾਈਂਡਰ ਟ੍ਰਿਗਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ 3 ਸਕੂਲ ਦਿਨਾਂ ਵਿੱਚ ਕੋਈ ਅਪਡੇਟ ਨਹੀਂ, ਤਾਂ ਡਿਵਾਈਸ ਮਾਲਿਕ ਅਤੇ IT ਨੂੰ ਸੂਚਿਤ ਕਰੋ; ਜੇ 7 ਦਿਨ ਬੀਤ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਐਡਮਿਨ ਸਮੀਖਿਆ ਲਈ ਫਲੈਗ ਕਰੋ।
ਹਰ ਟਿਕਟ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜੇ ਨਾਲ ਬੰਦ ਕਰੋ: repaired and returned, replaced, loaner issued, sent to vendor, or written off. ਇਹ ਅਖੀਰੀ ਕਦਮ ਹੀ ਉਹ Accountability ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਰਿਪੋਰਟ ਨੂੰ ਅਸਲ ਜਵਾਬਦੇਹ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਹਰ ਕੋਈ ਆਪਣਾ ਭਾਗ ਜਾਣਦਾ ਹੈ ਅਤੇ ਰਿਕਾਰਡ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ। ਫੈਸਲਾ ਕਰੋ ਕੌਣ ਰਿਪੋਰਟ ਦਾਇਤ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਫਾਇਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਸਕੂਲਾਂ ਲਈ, ਇਹ ਭੂਮਿਕਾਵਾਂ ਸਪਸ਼ਟ ਰੱਖਦੀਆਂ ਹਨ:
ਵਿਦਿਆਰਥੀ ਜਾਣਕਾਰੀ ਘੱਟੋ-ਘੱਟ ਰੱਖੋ। ਤੁਹਾਨੂੰ ਪਰਤਾਉ ਲਈ ਕਾਫੀ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਪੈਟਰਨ ਪਛਾਣਨ ਲਈ, ਪਰ ਇੰਨ੍ਹਾ ਨਹੀਂ ਕਿ ਫਾਰਮ ਇੱਕ ਡਿਸਪਲਿਨ ਫਾਈਲ ਬਣ ਜਾਵੇ।
ਦਰਜ ਕਰੋ: ਵਿਦਿਆਰਥੀ ਦਾ ਨਾਮ (ਜਾਂ ID), ਗਰੇਡ ਜਾਂ ਹੋਮਰੂਮ, ਡਿਵਾਈਸ ਐਸੈੱਟ ਟੈਗ/ਸੀਰੀਅਲ, ਤਾਰੀਖ/ਸਮਾਂ, ਟਿਕਾਣਾ, ਅਤੇ ਜੋ ਨੋਟਿਸ ਕੀਤਾ ਗਿਆ ਉਸਦੀ ਛੋਟੀ ਵਰਣਨਾ।
ਬਚੋ: ਸਿਹਤ ਵੇਰਵੇ, ਸਪੈਸ਼ਲ ਐਜੂਕੇਸ਼ਨ ਨੋਟਸ, ਇਮੀਗ੍ਰੇਸ਼ਨ ਸਥਿਤੀ, ਦੋਸ਼ਾਂ, ਜਾਂ ਵਿਵਰਣਾਂ। ਜੇ ਸੰਦਰਭ ਲੋੜੀਂਦਾ ਹੋਵੇ, ਤਾਂ ਤਟਸਥ ਭਾਸ਼ਾ ਵਰਤੋ ਜਿਵੇਂ “period 3 ਤੋਂ ਬਾਅਦ ਮਿਲਿਆ, ਸਕ੍ਰੀਨ ਟੁੱਟੀ” ਨਾ ਕਿ “ਵਿਦਿਆਰਥੀ ਲਾਪਰਵਾਹ ਸੀ”।
ਪ੍ਰਤੀਰਕ ਨੀਤੀ ਲਗਾਓ ਅਤੇ ਲਿਖੋ। ਇੱਕ ਆਮ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਰਿਪੋਰਟ ਨੂੰ ਮਰammat ਬੰਦ ਹੋਣ ਤਕ ਰੱਖੋ, ਫਿਰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਲਈ ਰੱਖੋ (ਉਦਾਹਰਣ ਲਈ, ਸਕੂਲ ਸਾਲ ਦੇ ਬਾਕੀ ਸਮੇਂ)। ਫੋਟੋਆਂ ਦੀ ਮਿਆਦ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਬੰਦ ਕਰਨ ਤੋਂ 30 ਤੋਂ 90 ਦਿਨਾਂ ਬਾਅਦ ਮਿਟਾਉਣਾ ਜੇਕਰ ਕੋਈ ਵਿਵਾਦ ਨਾ ਹੋਵੇ।
ਵਿਵਾਦ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ ਬਿਨਾਂ ਦੋਸ਼ ਲਾਉਣ ਦੇ। ਉਦਾਹਰਣ: ਚਾਰਜਰ ਟਿੱਪ ਮੁੜਿਆ ਹੋਇਆ ਵਾਪਸ ਆਈ—ਅਧਿਆਪਕ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਪਰ ਵਿਦਿਆਰਥੀ ਕਹਿੰਦਾ ਹੈ ਇਹ ਪਹਿਲਾਂ ਹੀ ਨੁਕਸਾਨੀਹੀ ਸੀ। ਫਾਰਮ ਤਾਂਤੀਕੀ ਤੱਥ ਕੈਪਚਰ ਕਰੇ (ਆਖ਼ਰੀ ਕਿਸ ਕੋਲ ਸੀ, ਕਦੋਂ ਨੋਟਿਸ ਹੋਇਆ, ਅਤੇ ਸਾਫ਼ ਫੋਟੋਆਂ) ਅਤੇ ਫੈਸਲਾ ਇਕ ਵਿਅਕਤੀ ਨੂੰ ਰੂਟ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇ ਐਡਮਿਨ ਜਾਂ IT ਲੀਡ) ਤਾਂ ਕਿ ਇਹ ਲੰਬੀ ਚਰਚਾ ਵਿੱਚ ਨਾ ਫਸੇ।
ਇੱਕ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਓਸ ਵੇਲ੍ਹੇ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਇਕੱਲੀ ਸਥਾਨ ਬਣਦਾ ਹੈ ਜਿੱਥੇ ਸਚਾਈ ਰਹਿੰਦੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਤੋੜ-ਫੋੜ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਲੋਕ ਮੌਕੇ 'ਤੇ ਮਦਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਪਰ ਕਿਸੇ ਖੇਤਰ ਨੂੰ ਛੱਡ ਜਾਂਦੇ ਹਨ ਜਾਂ ਗੱਲ-ਬਾਤ ਕਿਸੇ ਹੋਰ ਥਾਂ 'ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ।
ਪਹਿਲੀ ਨਾਕਾਮੀ ਇਹ ਹੈ ਕਿ ਹਰ ਵਾਰੀ ਇੱਕ ਵਿਲੱਖਣ ਡਿਵਾਈਸ ID ਵਰਤਿਆ ਨਾ ਜਾਵੇ। ਜੇ ਰਿਪੋਰਟ ਕਹਿੰਦੀ ਹੈ “Room 12 ਤੋਂ iPad” ਬਜਾਏ ਐਸੈੱਟ ਟੈਗ ਜਾਂ ਸੀਰੀਅਲ ਨੰਬਰ ਦੇ, ਤਾਂ ਗਲਤ ਡਿਵਾਈਸ ਦੀ ਮੁਰammat ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਬਦਲੀ ਗਲਤ ਕਹਾਣੀ ਵਿੱਚ ਮਿਕਸ ਹੋ ਸਕਦੀ ਹੈ। ਇਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਡਿਵਾਈਸ “ਗੁੰਮ” ਹੋ ਜਾਂਦੇ ਹਨ ਹਾਲਾਂਕਿ ਹਰ ਕੋਈ ਠੀਕ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।
ਫੋਟੋਆਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੂਜੀ ਗੱਲ ਹੈ। ਧੁੰਦਲੇ ਸ਼ਾਟ, ਹਨੇਰੇ ਫੋਟੋ, ਜਾਂ ਬਹੁਤ ਦੂਰ ਤੋਂ ਲਏ ਗਏ ਤਸਵੀਰਾਂ ਬਹੁਤ ਘੱਟ ਮਦਦਗਾਰ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਉਪਯੋਗੀ ਫੋਟੋ ਸੈੱਟ ਪੂਰੇ ਡਿਵਾਈਸ ਅਤੇ ਨੁਕਸਾਨ ਦਾ ਨਜ਼ਦੀਕੀ-ਸ਼ਾਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਐਸੈੱਟ ਟੈਗ ਵੀ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ।
ਜੋ ਗਲਤੀਆਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਹਲਚਲ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਕੋ ਜਿਹੀਆਂ ਹਨ:
ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਣ: ਵਿਦਿਆਰਥੀ ਨੇ ਮੈਥ ਦੌਰਾਨ ਟੈਬਲੇਟ ਦੀ ਸਕ੍ਰੀਨ ਤੋੜ ਦਿੱਤੀ। ਅਧਿਆਪਕ ਇੱਕ ਵਿਦਿਆਰਥੀ ਡਿਵਾਈਸ ਇਨਸਿਡੈਂਟ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਪਰ ਡਿਵਾਈਸ ਕਾਰਟ 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ। IT ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਹੋਰ ਸਮਾਨ ਕੇਸ ਵਾਲਾ ਟੈਬਲੇਟ ਚੁੱਕ ਲੈਂਦਾ, ਉਸਨੂੰ ਮੁਰammat ਕਰਦਾ, ਅਤੇ ਵਾਪਸ ਕਰਦਾ। ਅਸਲੀ ਕ੍ਰੈਕ ਕੀਤਾ ਡਿਵਾਈਸ ਕਲਾਸਰੂਮ ਵਿੱਚ ਰਹਿ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੁਣ ਕੋਈ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕੌਣ-ਕੌਣਸਾ ਡਿਵਾਈਸ ਨੁਕਸਾਨੀਹੀ ਸੀ।
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸਕੂਲਾਂ ਲਈ ਡਿਵਾਈਸ ਮਰammat ਟਰੈਕਿੰਗ ਟਿਕੇ ਰਹੇ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਨਿਯਮ ਬਣਾਓ: ਜੇ ਇਹ ਸਿਸਟਮ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਨਹੀਂ ਹੋਇਆ। ਫਿਰ ਹਰ ਵਾਰੀ ਉਸ ਨਿਯਮ ਨੂੰ ਆਸਾਨ ਬਣਾਓ ਤਾਂ ਲੋਕ ਉਸਨੂੰ ਪਾਲਣ।
ਇੱਕ ਚੰਗਾ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਤਾਂ ਹੀ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹੇ ਬੇਸਿਕ ਇੱਕੋ ਹੀ ਢੰਗ ਨਾਲ ਹਰ ਵਾਰੀ ਕੈਪਚਰ ਹੋਣ। ਇਹ ਚੈਕਲਿਸਟ ਵਰਤੋਂ ਜਦੋਂ ਤੁਸੀਂ ਡਿਵਾਈਸ ਇਕੱਠਾ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਜਦੋਂ ਇਹ ਮਰammat ਕਿਊ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਵੇ।
ਫਾਰਮ ਸਬਮਿਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਡਿਵਾਈਸ ਨੂੰ ਕਦੇ “ਅਸਾਇਨ ਨਾ ਛੱਡੋ।” ਜੇ ਅਗਲਾ ਕਦਮ ਕਿਸੇ ਦੇ ਕੋਲ ਨਹੀਂ, ਤਾਂ ਇਹ ਪੈ ਹੋ ਜਾਏਗਾ।
ਇੱਕ ਗੰਦੇ ਸਾਇੰਸ ਲੈਬ ਮਗਰੋਂ, ਅਧਿਆਪਕ ਨੂੰ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਕਲਾਸਰੂਮ ਟੈਬਲੇਟ ਦੀ ਸਕ੍ਰੀਨ 'ਤੇ ਇੱਕ ਸਪਾਈਡਰਵੇਬ ਕ੍ਰੈਕ ਹੈ। ਇਹ ਹੁਣ ਵੀ ਚਾਲੂ ਹੁੰਦੀ ਹੈ, ਪਰ ਟਚ ਗਲਿਚੀ ਕਰ ਰਹੀ ਹੈ। ਅਧਿਆਪਕ ਇਸਨੂੰ “ਬਾਅਦ ਵਿੱਚ” ਨਹੀਂ ਛੱਡਦਾ ਕਿਉਂਕਿ ਇਸੀ ਤਰ੍ਹਾਂ ਡਿਵਾਈਸ ਗੁੰਮ ਹੋ ਜਾਂਦੇ ਹਨ।
ਦੋ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ, ਅਧਿਆਪਕ ਆਪਣੇ ਫੋਨ 'ਤੇ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਭਰਦਾ ਹੈ। ਉਹ ਐਸੈੱਟ ਟੈਗ ਦਰਜ ਕਰਦਾ ਹੈ, ਟਿਕਾਣਾ (Room 214) ਚੁਣਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਲਿਖਦਾ ਹੈ: “ਲੈਬ ਕਲੀਨਅੱਪ ਤੋਂ ਬਾਅਦ ਸਕ੍ਰੀਨ ਕ੍ਰੈਕ, ਟਚ ਅਕਸਰ ਦਿੱਖਦਾ ਹੈ।” ਉਹ ਦੋ ਫੋਟੋ ਜੋੜਦਾ ਹੈ: ਇੱਕ ਕ੍ਰੈਕ ਦਾ ਨਜ਼ਦੀਕੀ-ਸ਼ਾਟ ਅਤੇ ਇੱਕ ਵਿਆਪਕ ਸ਼ਾਟ ਜੋ ਪੂਰੇ ਫਰੰਟ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਵਿਦਿਆਰਥੀ ਦਾ ਚਿਹਰਾ ਫਰੇਮ ਵਿੱਚ ਨਹੀਂ ਹੈ।
ਅਗਲੇ ਪੀਰੀਅਡ ਤੋਂ ਪਹਿਲਾਂ, ਦਫ਼ਤਰ ਕੰਮਰੇ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਡਿਵਾਈਸ ਨੂੰ ਲੇਬਲ ਕੀਤੇ ਸਲੀਵ ਵਿੱਚ ਭੇਜਣ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਦਫ਼ਤਰ ਸਟਾਫ਼ ਰਿਪੋਰਟ ਦੇ ਮੁਕਾਬਲੇ ਐਸੈੱਟ ਟੈਗ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਫਿਰ ਵਿਦਿਆਰਥੀ ਨੂੰ ਇੱਕ ਲੋਨਰ ਦਿੰਦਾ ਹੈ। ਲੋਨਰ ਦੀ ਰਿਕਾਰਡਿੰਗ ਤਾਰੀਖ, ਅਸਥਾਈ ਨਿਯੋਜਨ, ਅਤੇ ਮਨਜ਼ੂਰੀ ਕਰਨ ਵਾਲੇ ਦਾ ਨਾਮ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
IT ਆਪਣੀ ਰੋਜ਼ਾਨਾ ਰਾਊਂਡ ਦੌਰਾਨ ਖਰਾਬ ਟੈਬਲੇਟ ਉਠਾ ਲੈਂਦਾ ਹੈ। ਟਰੈਕਿੰਗ ਰਿਕਾਰਡ ਵਿੱਚ ਉਹ ਸਥਿਤੀ ਨੂੰ “Received” ਤੋਂ “Diagnosing” 'ਚ ਮੋੜਦਾ ਹੈ ਅਤੇ ਛੋਟੇ ਨੋਟਾਂ ਜੋੜਦਾ ਹੈ:
ਜਦੋਂ ਪਾਰਟ ਆ ਜਾਂਦਾ ਹੈ, IT ਸਥਿਤੀ ਨੂੰ “Repair in progress” ਤੇ ਫਿਰ ਟੈਸਟਿੰਗ ਪੂਰੀ ਹੋਣ 'ਤੇ “Ready for return” ਕਰ ਦਿੰਦਾ ਹੈ। ਦਫ਼ਤਰ ਮੂਲ ਡਿਵਾਈਸ ਵਾਪਸ ਚੁੱਕਦਾ, ਲੋਨਰ ਦੀ ਵਾਪਸੀ ਪੱਕੀ ਕਰਦਾ, ਅਤੇ ਰਿਕਾਰਡ ਨੂੰ ਵਾਪਸੀ ਦੀ ਤਾਰੀਖ ਅਤੇ ਅੰਤਿਮ ਨੋਟਸ ਨਾਲ ਬੰਦ ਕਰਦਾ। ਕੁਝ ਵੀ ਢੇਰ ਵਿੱਚ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ, ਅਤੇ ਹਰ ਕਿਸੇ ਨੂੰ ਹਰ ਕਦਮ ਦਾ ਪਤਾ ਹੁੰਦਾ ਹੈ।
ਸਰਲ ਸੈਟਅੱਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵਰਤਣ: ਇੱਕ ਫਾਰਮ, ਫੋਟੋ ਜੋੜਨ ਦਾ ਆਸਾਨ ਤਰੀਕਾ, ਛੋਟੀ ਸਥਿਤੀਆਂ ਦੀ ਸੂਚੀ, ਅਤੇ ਇੱਕ ਥਾਂ ਜਿੱਥੇ ਸਭ ਕੁਝ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਦਿੱਸੇ। ਜੇ ਕੋਈ ਕਦਮ ਧੀਮਾ ਲੱਗੇ, ਤਾਂ ਸਟਾਫ਼ ਉਸਨੂੰ ਛੱਡ ਦੇਵੇਗਾ, ਅਤੇ ਡਿਵਾਈਸ ਮੁੜ ਤੋਂ ਗੁੰਮ ਹੋਣ ਲੱਗਣਗੇ।
ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਸਲਾਈਨ ਇਹ ਹੋ ਸਕਦੀ ਹੈ:
ਇੱਕ ਕਲਾਸ-ਲੈਵਲ ਜਾਂ ਇੱਕ ਡਿਵਾਈਸ ਕਾਰਟ ਨਾਲ ਦੋ ਹਫ਼ਤੇ ਲਈ ਪਾਇਲਟ ਕਰੋ। ਇੱਕ ਅਸਾਨ-ਵਰਤੋਂ ਵਾਲੇ ਸਮੂਹ ਚੁਣੋ ਅਤੇ ਇੱਕ ਅਧਿਆਪਕ ਜੋ ਜਲਦੀ ਫੀਡਬੈਕ ਦੇਵੇ। ਪਾਇਲਟ ਦੇ ਦੌਰਾਨ ਝਲਸਣ ਵਾਲੇ ਐਜ ਕੇਸਾਂ 'ਤੇ ਨਹੀਂ ਫਸੋ। ਫੋਕਸ ਕਰੋ ਕਿ ਰਿਪੋਰਟਾਂ ਉਹੀ ਦਿਨ ਫਾਇਲ ਹੁੰਦੀਆਂ ਹਨ, ਫੋਟੋਆਂ ਉਪਯੋਗੀ ਹਨ, ਅਤੇ ਡਿਵਾਈਸ ਸਥਿਤੀ ਤੋਂ ਸਥਿਤੀ ਤੱਕ ਵਧਦੀਆਂ ਹਨ।
ਸਟਾਫ਼ ਲਈ ਇੱਕ ਪੰਨਾ ਸਧਾਰਨ ਹਦਾਇਤ ਲਿਖੋ: ਕਦੋਂ ਫਾਰਮ ਫਾਈਲ ਕਰਨਾ ਹੈ, ਕਿੰਨੀਆਂ ਫੋਟੋਆਂ ਲੈਣੀਆਂ ਹਨ, ਅਤੇ ਰਿਪੋਰਟ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਡਿਵਾਈਸ ਨਾਲ ਕੀ ਕਰਨਾ (ਟੈਗ ਕਰੋ, ਸਹੀ ਬਿਨ ਵਿੱਚ ਰੱਖੋ, ਵਿਦਿਆਰਥੀ ਨੂੰ ਵਾਪਸ ਨਾ ਦਿਓ)।
ਪਾਇਲਟ ਤੋਂ ਬਾਅਦ ਦੇਖੋ ਕਿ ਲੋਕ ਕਿਹੜੇ ਫੀਲਡ ਛੱਡਦੇ ਹਨ। ਜੇ ਕੋਈ ਫੀਲਡ ਅਕਸਰ ਖਾਲੀ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਇਹ ਸਚਮੁਚ ਲੋੜੀਦੀ ਹੈ, ਇਸਨੂੰ ਡ੍ਰੌਪਡਾਊਨ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਇਹ IT ਲਈ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਨਾ ਕਿ ਅਧਿਆਪਕਾਂ ਲਈ। ਛੋਟੇ ਤਬਦੀਲੀਆਂ, ਜਿਵੇਂ ਛੋਟੇ ਵਿਕਲਪ ਅਤੇ ਘੱਟ_REQUIRED_ ਫੀਲਡ, ਪੂਰੇ ਪੂਰਨਤਾ ਦਰ ਨੂੰ ਜਲਦੀ ਵਧਾ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਸਕੂਲ ਨੂੰ ਫਾਰਮਾਂ ਅਤੇ ਸ਼ੀਟਾਂ ਦੀ ਥਾਂ ਇੱਕ ਕਸਟਮ ਅੰਦਰੂਨੀ ਟੂਲ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ Koder.ai 'ਤੇ ਚੈਟ ਰਾਹੀਂ ਆਪਣੇ ਵਰਕਫਲੋ ਦੀ ਵਰਣਨਾ ਕਰਕੇ ਇੱਕ ਛੋਟਾ ਟਰੈਕਰ ਬਣਾਇਆ ਜਾਵੇ, ਫਿਰ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰਕੇ ਆਪਣੇ IT ਟੀਮ ਨੂੰ ਦੇ ਦਿੱਤਾ ਜਾਵੇ। ਇਹ ਭੂਮਿਕਾਵਾਂ, ਮਰammat ਸਥਿਤੀ ਟਰੈਕਿੰਗ, ਅਤੇ ਖੋਜਯੋਗ ਇਤਿਹਾਸ ਨੂੰ ਇੱਕ ਥਾਂ ਰੱਖਣ ਦਾ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ।
Use a single report that stays attached to the device from the first note of damage to the final return. The most important fix is to record the device ID and current location immediately, then require a clear handoff so it never sits “somewhere” without an owner.
Start with what uniquely identifies the device and where it is right now: asset tag, serial number if available, model, and current location. Then add who noticed it, when it was noticed, and a short description that helps IT decide the next step without a follow-up conversation.
Keep the description to one plain sentence that includes what happened, when, and where. Example: “Dropped from desk during 3rd period in Room 204; screen cracked.” Long stories usually don’t help triage and often lead to missing the key details.
In most cases, take two to four photos: one full front, one full back, and one close-up of the damage, plus an optional power-on photo that shows the problem. If you can include the asset tag in a clear shot without slowing things down, it reduces mix-ups.
Default to protecting student privacy over collecting “perfect” evidence. Keep faces, reflections, names, and anything sensitive off-screen; if the screen content could reveal student information, turn the screen off and retake the photo.
Use a small set of statuses that anyone can understand, and only allow the device to advance when the record is complete enough to act on. The practical rule is simple: every status change should have an owner and an updated location so you can answer “where is it?” instantly.
Treat a loaner as its own tracked checkout, not a casual swap. Record the loaner’s asset tag, who received it, the date issued, and the expected return date, and close the loop the same day the repaired device is returned so the loaner doesn’t become the new missing device.
Give teachers and front office staff the ability to submit reports and upload photos, and reserve status changes and ticket closure for IT. Keep student data minimal and factual so the record helps returns and pattern-spotting without turning into a discipline file.
Email threads split the timeline across replies, lose attachments, and make it hard for new staff to see the current truth. A single record that holds the device ID, photos, status, location, and notes works better because it stays readable even after handoffs and staff changes.
You can build a lightweight internal tracker by describing your workflow in chat, then storing reports, statuses, and history in one place. Teams sometimes do this with Koder.ai when they want a simple system that fits their exact intake and repair process and can later be exported and deployed.
