23 ਦਸੰ 2025·8 ਮਿੰਟ
ਐਡਮਿਨ ਪੈਨਲ ਸਕ੍ਰੀਨਸ: ਓਪਸ ਅਤੇ ਸਪੋਰਟ ਲਈ 12 ਲਾਜ਼ਮੀ ਦਰਸ਼ਨ
ਇਹ ਲੇਖ 12 ਐਡਮਿਨ ਪੈਨਲ ਸਕ੍ਰੀਨਾਂ ਦੀ ਵਰਤਮਾਨ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜੋ ਆਮ ਸਪੋਰਟ ਅਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ, ਨਾਲ ਹੀ ਪਹਿਲਾਂ ਕੀ ਬਣਾਉਣਾ ਇਸ ਦੀ ਤਰਜੀਹ ਕਰਨ ਦਾ ਇੱਕ ਆਸਾਨ ਢੰਗ।
ਇਹ ਲੇਖ 12 ਐਡਮਿਨ ਪੈਨਲ ਸਕ੍ਰੀਨਾਂ ਦੀ ਵਰਤਮਾਨ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜੋ ਆਮ ਸਪੋਰਟ ਅਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ, ਨਾਲ ਹੀ ਪਹਿਲਾਂ ਕੀ ਬਣਾਉਣਾ ਇਸ ਦੀ ਤਰਜੀਹ ਕਰਨ ਦਾ ਇੱਕ ਆਸਾਨ ਢੰਗ।
ਇੱਕ ਐਡਮਿਨ ਪੈਨਲ ਜੋ “80% ਓਪਰੇਸ਼ਨਜ਼” ਕਵਰ ਕਰਦਾ ਹੈ, ਉਹੀ ਨਹੀਂ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸੈਟਿੰਗਾਂ ਰੱਖਦਾ ਹੈ। ਉਹ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੇ ਟੀਮ ਨੂੰ ਆਮ ਸਪੋਰਟ ਅਤੇ ਓਪਰੇਸ਼ਨਸ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਬਿਨਾਂ ਹਰ ਇਕ ਮਾਮਲੇ ਲਈ ਇੰਜੀਨੀਅਰ ਨੂੰ ਖਿੱਚਣ ਦੇ।
ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਡਕਟ ਫੀਚਰਾਂ ਨੂੰ ਸਪੋਰਟ ਟੂਲਜ਼ ਤੋਂ ਵੱਖਰਾ ਕਰਨਾ। ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਅੰਤ-ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਸਪੋਰਟ ਟੂਲਜ਼ ਤੁਹਾਡੀ ਅੰਦਰੂਨੀ ਟੀਮ ਨੂੰ ਇਹ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ: “ਕੀ ਹੋਇਆ? ਕਿਸ ਨੇ ਕੀਤਾ? ਅਸੀਂ ਕੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਾਂ?” ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਕੰਟਰੋਲ ਬਹੁਤ ਭੇਜ ਦਿੰਦੀਆਂ ਹਨ, ਪਰ ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਸਪੋਰਟ ਅਜੇ ਵੀ ਨੈਰ ਹੀ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨਹੀਂ ਦੇਖ ਸਕਦੀ—ਹੋਨਹਾਰ, ਬਿਲਿੰਗ ਸਥਿਤੀ, ਤਾਜ਼ਾ ਤਰੁੱਟੀਆਂ, ਜਾਂ ਬਦਲਾਅਾਂ ਦਾ ਸਾਫ ਇਤਿਹਾਸ।
ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਐਡਮਿਨ ਪੈਨਲ ਨੂੰ ਵੱਖਰੇ ਮਕਸਦ ਲਈ ਵਰਤਦੀਆਂ ਹਨ। ਸਪੋਰਟ ਨੂੰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਨਬਲੋਕ ਕਰਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਾਅ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਫਾਇਨੈਂਸ ਨੂੰ ਬਿਲਿੰਗ, ਇਨਵੌਇਸ, ਰੀਫੰਡ ਅਤੇ ਟੈਕਸ ਰਿਕਾਰਡ ਚਾਹੀਦੇ ਹਨ। ਓਪਸ ਨੂੰ ਓਰਗ ਦੀ ਸਿਹਤ, ਵਰਤੋਂ ਰੁਝਾਨ, ਰਿਸਕ ਚੈਕ ਅਤੇ ਐਕਸਪੋਰਟ ਚਾਹੀਦੇ ਹਨ। ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਡਿਬੱਗਿੰਗ breadcrumbs ਜਿਵੇਂ ਲੌਗਸ ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਚਾਹੀਦੇ ਹਨ (ਪੂਰੀ observability ਨਹੀਂ)।
ਅਰਥ ਤੇ ਪ੍ਰਭਾਵ ਨੂੰ ਦੇਖ ਕੇ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ 80% ਵਿੱਚ ਕੀ ਆਉਂਦਾ ਹੈ। ਫ੍ਰਿਕ੍ਵੈਂਸੀ ਦੇ ਅਰਥ ਹਨ ਕਿ ਅਰਜ਼ੀ ਕਿੰਨੀ ਵਾਰ ਆਉਂਦੀ ਹੈ। ਪ੍ਰਭਾਵ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ ਕਿੰਨੀ ਨੁਕਸਾਨਕਾਰੀ ਹੋ ਸਕਦਾ ਹੈ (ਖੋਇਆ ਰੈਵਨਿਊ, churn ਰਿਸ্ক, ਕੰਪਲਾਇੰਸ ਰਿਸਕ)।
ਸਾਦਾ ਤਰੀਕਾ:
ਜੇ ਇੱਕ ਯੂਜ਼ਰ ਕਹਿੰਦਾ ਹੈ, “ਮੇਰੇ ਤੋਂ Pro ਲਈ ਚਾਰਜ ਹੋਇਆ ਪਰ ਮੈਂ ਐਕਸੈੱਸ ਨਹੀਂ ਕਰ ਸਕਦਾ,” ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ ਚੈਕਲਿਸਟ ਉਹੀ ਹੈ ਜੋ ਸਪੋਰਟ ਨੂੰ user lookup ਤੋਂ subscription status ਤੇ invoice ਅਤੇ ਕਾਰਵਾਈ ਤੱਕ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ, ਹਰ ਬਦਲਾਅ ਲਈ audit trail ਦੇ ਨਾਲ।
ਇੱਕ ਐਡਮਿਨ ਪੈਨਲ ਆਪਣੀ ਕਦਰ ਉਸ ਵੇਲੇ ਕਮਾਉਂਦਾ ਹੈ ਜਦੋ ਇਹ ਤੁਹਾਨੂੰ ਟਿਕਟ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬੰਦ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਸਹੀ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਚੁਣਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਸਪੋਰਟ ਦੀ ਹਕੀਕਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ, ਨਾ ਕਿ ਕਿ ਇਹ “ਪੂਰਾ” ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸਿਖਰ ਦੇ 20 ਸਵਾਲ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ (ਜਾਂ ਪਹਿਲੇ 90 ਦਿਨਾਂ ਵਿੱਚ ਉਮੀਦ ਕਰਦੇ ਹੋ)। ਆਪਣੀ inbox, chat ਲੌਗਾਂ, ਅਤੇ ਰੀਫੰਡ ਨੋਟਸ ਦੇਖੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਕੁਝ ਬਣਾਉਂਦੇ ਹੋ, ਉਦਾਹਰਨਾਂ ਹਨ: “ਮੈਂ ਲਾਗਿਨ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦਾ?” “ਕਿਸ ਨੇ ਇਹ ਸੈਟਿੰਗ ਬਦਲੀ?” “ਮੈਨੂੰ ਦੋ ਵਾਰ ਚਾਰਜ ਕਿਉਂ ਕੀਤਾ ਗਿਆ?” “ਕੀ ਤੁਸੀਂ ਮੇਰਾ ਡਾਟਾ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ?” “ਕੀ ਐਪ ਸਾਰਿਆਂ ਲਈ ਡਾਊਨ ਹੈ?”
ਫਿਰ ਉਹ ਸਵਾਲ ਥੀਮਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ: access (users, orgs, roles), money (billing, invoices, usage), data (exports, deletions, retention), ਅਤੇ incidents (audit, logs, status)।
ਫਿਰ ਹਰ ਥੀਮ ਨੂੰ ਇੱਕ ਸਕ੍ਰੀਨ ਵਿੱਚ ਬਦਲੋ, ਨਾਲ ਹੀ 2–3 ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈਆਂ ਜੋ ਜ਼ਿਆਦਾਤਰ ਟਿਕਟਾਂ ਹੱਲ ਕਰਦੀਆਂ ਹਨ। “ਸੁਰੱਖਿਅਤ” ਦਾ ਮਤਲਬ ਹੈ reversable, logged, ਅਤੇ ਗਲਤੀ ਨਾਲ ਘੱਟ ਨੁਕਸਾਨ ਕਰਨਯੋਗ। ਉਦਾਹਰਨਾਂ: invite ਮੁੜ ਭੇਜੋ, MFA ਰੀਸੈਟ ਕਰੋ, ਭੁਗਤਾਨ retry ਕਰੋ, ਐਕਸਪੋਰਟ ਮੁੜ ਬਣਾਓ, ਜਾਂ config ਬਦਲਾਅ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰੋ।
ਹਰ ਪ੍ਰਸਤਾਵਿਤ ਸਕ੍ਰੀਨ ਲਈ ਇਸੇ ਸਕੋਰਿੰਗ ਲੈਂਸ ਦੀ ਵਰਤੋਂ ਕਰੋ:
ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਵਰਜ਼ਨ ਬਣਾਓ ਜੋ ਟਿਕਟਾਂ ਨੂੰ end to end ਹੱਲ ਕਰਦਾ ਹੋਵੇ। ਇੱਕ ਵਧੀਆ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਕੀ ਸਪੋਰਟ ਏਜੰਟ ਇੱਕ ਅਸਲੀ ਕੇਸ ਨੂੰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਪੂਛੇ ਬਿਨਾਂ ਸੰਭਾਲ ਸਕਦਾ ਹੈ। ਜੇ ਨਹੀਂ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਕ੍ਰੀਨ ਵਿੱਚ ਇੱਕ ਵਿਸਥਾਰ ਦੀ ਕਮੀ ਹੁੰਦੀ ਹੈ (ਜਿਵੇਂ last login, billing status, ਜਾਂ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ, ਅਤੇ ਕਿਸ ਨੇ)।
ਇਹ ਤਿੰਨ ਸਕ੍ਰੀਨ روزਮਰਾ ਦੇ ਕੰਮਾਂ ਦਾ ਬਹੁਤ ਹਿੱਸਾ ਨਿਭਾਉਂਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ: “ਹੁਣ ਕੀ ਸੰਗਤ ਹੈ?” ਅਤੇ “ਕੋਣ ਪ੍ਰਭਾਵਿਤ ਹੈ?”
Overview ਇੱਕ ਛੋਟੀ, ਭਰੋਸੇਯੋਗ pulse check ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸਨੂੰ ਅੱਜ ਅਤੇ ਪਿਛਲੇ 24 ਘੰਟਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਰੱਖੋ: ਨਵੇਂ ਸਾਈਨਅਪ, ਸਰਗਰਮ ਯੂਜ਼ਰ, ਭੁਗਤਾਨ ਫੇਲਿਊਰ, ਅਤੇ ਕੋਈ ਵੀ ਤਰੁੱਟੀਆਂ ਦੀਆਂ ਛੁੱਟੀਆਂ। ਇੱਕ ਛੋਟੀ alerts ਇਲਾਕਾ ਸ਼ਾਮਲ ਕਰੋ ਜਿੱਥੇ ਸਪੋਰਟ ਨੂੰ ਛੱਡਣਾ ਨਹੀਂ ਚਾਹੀਦਾ—ਜਿਵੇਂ ਉ atypical login failures, webhook errors, ਜਾਂ refunds ਵਿੱਚ ਅਚਾਨਕ ਵਾਧਾ।
ਇੱਕ ਚੰਗੀ ਨਿਯਮ: ਇਸ ਪੇਜ 'ਤੇ ਹਰ ਮੈਟਰਿਕ ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਲਿੱਕ ਦਿਖਾਵੇ, ਆਮ ਤੌਰ ਤੇ Users, Organizations, ਜਾਂ Logs ਵੱਲ।
Users ਸਕ੍ਰੀਨ ਨੂੰ ਬਹੁਤ ਵਧੀਆ search ਚਾਹੀਦੀ ਹੈ। ਸਪੋਰਟ ਲੋਗਾਂ ਨੂੰ email, name, user ID, ਅਤੇ organization ਨਾਲ ਖੋਜ ਸਕਣ। status ਅਤੇ trust ਸੰਕੇਤ ਅੱਗੇ ਰੱਖੋ: verified email ਜਾਂ phone (ਜੇ ਤੁਸੀਂ ਇਕੱਠੇ ਕਰਦੇ ਹੋ), last login, ਅਤੇ ਖਾਤਾ active ਹੈ, suspended ਹੈ, ਜਾਂ invited-but-not-joined ਹੈ।
ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਇੱਕ ਲਗਾਤਾਰ ਥਾਂ 'ਤੇ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਓ: deactivate ਜਾਂ reactivate, access ਰੀਸੈਟ (sessions, MFA, ਜਾਂ password), ਅਤੇ invite ਮੁੜ ਭੇਜੋ। ਇੱਕ ਅੰਦਰੂਨੀ ਨੋਟਸ ਫੀਲਡ ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ “Jan 9 ਨੂੰ invoice ਬਦਲਾਅ ਮੰਗੀ ਗਈ” ਤਾਂ ਕਿ ਟਿਕਟਾਂ ਸਿਰਫ਼ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਹੋਣ।
ਇਹ ਸਕ੍ਰੀਨ ਮੈਂਬਰਸ਼ਿਪ, ਮੌਜੂਦਾ ਯੋਜਨਾ, ਵਰਤੋਂ ਬਨਾਮ ਸੀਮਾਵਾਂ, ਅਤੇ ਮਾਲਕ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਪੋਰਟ ਅਕਸਰ “ਗਲਤ ਵਿਅਕਤੀ ਕੋਲ ਐਕਸੈਸ ਹੈ” ਅਤੇ “ਅਸੀਂ ਸੀਮਾ ਪਾਰ ਕਰ ਗਏ” ਵਾਲੇ ਮਾਮਲਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ownership transfer ਅਤੇ membership management ਸ਼ਾਮਲ ਕਰੋ।
ਇਹ ਦਰਸ਼ਨਾਂ ਨੂੰ ਫਿਲਟਰ, sorting, ਅਤੇ saved searches ਨਾਲ ਤੇਜ਼ ਰੱਖੋ ਜਿਵੇਂ “payment failed,” “no login in 30 days,” ਜਾਂ “over limit.” ਹੌਲੀ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਸਧਾਰਨ ਟਿਕਟਾਂ ਨੂੰ ਲੰਬੀਆਂ ਬਣਾਉਂਦੀਆਂ ਹਨ।
Roles ਅਤੇ permissions ਉਹੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸਪੋਰਟ ਜਿੱਤਦੀ ਜਾਂ ਹਾਰਦੀ ਹੈ। ਜੇ ਕੋਈ ਕਹਿੰਦਾ ਹੈ “ਮੈਂ X ਨਹੀਂ ਕਰ ਸਕਦਾ,” ਤਾਂ ਤੁਹਾਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਸਕ੍ਰੀਨ ਨੂੰ role based access control ਦਾ ਸਪੱਸ਼ਟ, ਪੜ੍ਹਨਯੋਗ ਦ੍ਰਿਸ਼ ਬਣਾਓ, ਨਾ ਕਿ ਇੱਕ ਡਿਵੈਲਪਰ ਟੂਲ।
ਦੋ ਸਾਦੇ ਟੇਬਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: roles (ਓਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ) ਅਤੇ ਲੋਕ (ਕਿਸ ਕੋਲ ਕੀ ਹੈ)। ਸਭ ਤੋਂ ਉਪਯੋਗੀ ਵਿਸਥਾਰ effective access ਹੈ। ਇਕ ਯੂਜ਼ਰ ਦੇ roles, ਕੋਈ org-ਲੈਵਲ role, ਅਤੇ ਕੋਈ overrides ਇੱਕ ਥਾਂ 'ਤੇ ਦਿਖਾਓ, ਨਾਲ ਹੀ ਇੱਕ ਸਧਾਰਨ-ਭਾਸ਼ਾ ਸੰਖੇਪ ਜਿਵੇਂ “Can manage billing: Yes.”
ਇੱਕ ਸੁਰੱਖਿਅਤ permission editor ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ role ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਖਾਤਿਆਂ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ। ਸੇਵ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਿਵੀਊ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਦਿਖਾਵੇਗਾ ਕਿ ਠੀਕ ਕੀ ਬਦਲੇਗਾ: ਕਿਹੜੀਆਂ ਯੋਗਤਾਵਾਂ ਜੋੜੀਆਂ ਜਾਂ ਹਟਾਈਆਂ ਜਾ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਿਤ ਹੋਣਗੇ।
ਸਪੋਰਟ-ਫ੍ਰੈਂਡਲੀ ਰੱਖਣ ਲਈ, “Why can't they do this?” troubleshooter ਸ਼ਾਮਲ ਕਰੋ। ਸਪੋਰਟ ਇੱਕ ਕਾਰਵਾਈ ਚੁਣਦਾ ਹੈ (ਜਿਵੇਂ “export data” ਜਾਂ “invite user”), ਯੂਜ਼ਰ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਸਕ੍ਰੀਨ ਘੱਟ ਰਹਿ ਗਈ permission ਅਤੇ ਓਥੇ ਕਿੱਥੇ ਦਿੰਨੀ ਚਾਹੀਦੀ ਹੈ (role vs org policy) ਦੱਸ ਦਿੰਦੀ ਹੈ। ਇਹ ਲੰਬੀ ਬਾਅਦ-ਚੌਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ escalation ਘਟਾਉਂਦਾ ਹੈ।
ਉੱਚ-ਖਤਰੇ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਵਧੀਆ ਪੁਸ਼ਟੀ ਮੰਗੋ। ਆਮ ਹਨ: admin roles ਬਦਲਣਾ, billing ਜਾਂ payouts ਲਈ ਐਕਸੈਸ ਦੇਣਾ, production ਐਕਸੈਸ/ਡਿਪਲੌਯਮੈਂਟ ਪਰਮੀਸ਼ਨ ਦੇਣਾ, ਅਤੇ MFA ਜਿਹੇ ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਨੂੰ ਬੰਦ ਕਰਨਾ।
ਅੰਤ ਵਿੱਚ, permission ਬਦਲਾਅ auditable ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਹਰ ਸੋਧ ਲਾਗ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ: ਕਿਸ ਨੇ ਬਦਲਿਆ, ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕੀਤਾ, before/after values, ਅਤੇ ਕਾਰਨ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਵਿੱਚ, ਉਹ ਇਤਿਹਾਸ ਸਪੋਰਟ ਨੂੰ ਬਤਾਉਂਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਅਚਾਨਕ export source code, deploy, ਜਾਂ custom domain manage ਕਿਉਂ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਬਿਲਿੰਗ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਟਿਕਟ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ। ਇਹ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਸਪਸ਼ਟ, ਤੇਜ਼ ਅਤੇ ਗਲਤੀ-ਘਟਾਉਣ ਵਾਲੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਚੀਜ਼ ਠੀਕ ਕਰ ਸਕਦੇ, ਤਾਂ ਉਹ ਹੋਵੇ: “ਉਹ ਕਿਸ ਯੋਜਨਾ 'ਤੇ ਹਨ, ਉਹ ਕੀ ਭੁਗਤਾਨ ਕੀਤਾ, ਅਤੇ ਐਕਸੈੱਸ ਕਿਉਂ ਬਦਲਿਆ?”
ਮੌਜੂਦਾ ਯੋਜਨਾ, ਨਵੀਨੀਕਰਨ ਦੀ ਤਾਰੀਖ, ਸਥਿਤੀ (active, trial, past due, canceled), ਸੀਟ ਗਿਣਤੀ, ਅਤੇ ਕਿਸ ਨੇ billing ਮਾਲਕੀ ਹੈ ਇਹ ਦਿਖਾਓ। ਸਚਾਈ ਦਾ ਸਰੋਤ ਉੱਪਰ ਰੱਖੋ, ਅਤੇ ਇਤਿਹਾਸ ਹੇਠਾਂ ਰੱਖੋ (ਯੋਜਨਾ ਬਦਲਾਅ, ਸੀਟ ਬਦਲਾਅ)। ਖਤਰਨਾਕ ਕੰਟਰੋਲ (cancel, change plan, restart) ਨੂੰ ਵੇਖਣ ਤੋਂ ਦੂਰ ਰੱਖੋ, ਪੁਸ਼ਟੀ ਅਤੇ ਲਾਜ਼ਮੀ ਕਾਰਨ ਨਾਲ।
ਸਪੋਰਟ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਇਨਵੌਇਸ ਲਿਸਟ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਤਾਰੀਖਾਂ, ਰਕਮ, ਟੈਕਸ, ਅਤੇ ਸਥਿਤੀ (paid, open, failed, refunded) ਹੋਣ। ਭੁਗਤਾਨ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਅਸਫਲਤਾ ਕਾਰਨ ਸ਼ਾਮਲ ਕਰੋ, ਜਿਵੇਂ card declined ਜਾਂ authentication required। ਰਸੀਦਾਂ ਨੂੰ ਇਨਵੌਇਸ ਰੋਅ ਤੋਂ ਇੱਕ-ਕਲਿੱਕ ਵਿੱਚ ਪਹੁੰਚਯੋਗ ਬਣਾਓ, ਪਰ ਇੱਥੇ ਸੰਪਾਦਨ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਵਾਕਈ ਲੋੜ ਨਾ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਵਰਤੋਂ ਅਨੁਸਾਰ ਚਾਰਜ ਕਰਦੇ ਹੋ ਜਾ credits ਨੂੰ ਵਰਤਦੇ ਹੋ ਤਾਂ ਇੱਕ ਮੀਟਰ ਦਿਖਾਓ ਜੋ ਗਾਹਕ ਦੇ ਵੇਖੇ ਹੋਏ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। ਮੌਜੂਦਾ ਪੀਰੀਅਡ ਵਰਤੋਂ, ਸੀਮਾਵਾਂ, ਓਵਰਜ, ਅਤੇ ਕਿਸੇ ਵੀ caps ਨੂੰ ਦਿਖਾਓ। ਇੱਕ ਛੋਟੀ “ਕਿਉਂ ਉਹ ਬਲਾਕ ਹੋਏ” ਸੰਖੇਪ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਸਪੋਰਟ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾ ਸਕੇ।
ਸਧਾਰਨ ਸਪੋਰਟ ਕਾਰਵਾਈਆਂ ਇੱਥੇ ਹੋਣ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਰੱਖੋ: ਇੱਕ ਵਾਰੀ ਦਾ ਕ੍ਰੈਡਿਟ (ਮਿਆਦ ਅਤੇ ਅੰਦਰੂਨੀ ਨੋਟ ਨਾਲ), ਟ੍ਰਾਇਲ ਵਧਾਉਣਾ (ਸੀਮਾਵਾਂ ਨਾਲ), ਟੈਕਸ ਜਾਂ ਬਿਲਿੰਗ ਪਤਾ ਅਪਡੇਟ ਕਰਨਾ (ਟ੍ਰੈਕ ਕੀਤਾ ਹੋਵੇ), ਅਸਫਲ ਭੁਗਤਾਨ ਨੂੰ retry ਕਰਨਾ, ਜਾਂ ਸਾਡੀਆਂ ਸੀਟਾਂ ਜੁੜਨਾ ਬਿਨਾਂ ਯੋਜਨਾ ਬਦਲਣ ਦੇ।
ਰੁਕੀ ਹੋਈ ਫੀਲਡਾਂ ਨੂੰ ਦਰਸ਼ਨ ਵਿੱਚ ਵੱਖਰਾ ਕਰੋ—ਉਦਾਹਰਨ ਵਜੋਂ, “Plan: Business (read-only)” ਨੂੰ “Seat count (editable)” ਦੇ ਕੋਲ ਦਿਖਾਓ ਤਾਂ ਕਿ ਏਜੰਟ ਅਚਾਨਕ ਯੋਜਨਾ ਬਦਲ ਨਾ ਦੇ।
ਜਦ ਸਪੋਰਟ ਕਹਿੰਦੀ ਹੈ “ਕੁਝ ਬਦਲਿਆ,” ਇਹ ਦੋ ਸਕ੍ਰੀਨ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ। ਆਡਿਟ ਲੌਗ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸ ਨੇ ਕੀ ਕੀਤਾ। ਸਿਸਟਮ ਲੌਗ ਦੱਸਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਨੇ ਕੀ ਕੀਤਾ ਜਾਂ ਨਾਕਾਮ ਕੀਤਾ। ਇਕੱਠੇ ਉਹ follow-up ਸਵਾਲ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਜਵਾਬ ਦੇਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਆਡਿਟ ਲੌਗ ਤਿੰਨ ਸਵਾਲ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਜਵਾਬ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ: ਕਿਸ ਨੇ ਕਾਰਵਾਈ ਕੀਤੀ, ਉਸਨੇ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਕਦੋਂ ਹੋਇਆ। ਜੇ ਤੁਸੀਂ ਥਾਂ (IP address, device, approximate location) ਵੀ ਕੈਪਚਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸ਼ੱਕੀ ਪਹੁੰਚਾਂ ਨੂੰ ਪਛਾਣ ਸਕਦੇ ਹੋ ਅਤੇ ਦੇਖੇ ਗਏ ਅਸੰਭਵ ਵਰਤੋਂ ਨੂੰ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦੇ।
ਸਪੋਰਟ-ਫ੍ਰੈਂਡਲੀ ਫਿਲਟਰ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ: actor (admin, support agent, end user, API key), user ਅਤੇ organization, ਸਮਾਂ-ਵਿੰਡੋ, ਕਾਰਵਾਈ ਦੀ ਕਿਸਮ (login, role change, billing change, export), ਅਤੇ target object (account, project, subscription)।
ਹਰ ਰੋਅ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ: ਕਾਰਵਾਈ ਦਾ ਨਾਂ, before/after ਸੰਖੇਪ, ਅਤੇ ਇੱਕ stable event ID ਜੋ ਇੰਜੀਨੀਅਰਿੰਗ ਨਾਲ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕੇ।
System logs ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿਥੇ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ “ਇਹ ਟੁੱਟਿਆ” ਵੱਸ ਨਹੀਂ “ਇਹ ਕੰਮ ਕੀਤਾ ਪਰ ਦੇਰ ਹੋਈ।” ਇਸ ਸਕ੍ਰੀਨ ਨੂੰ errors, retries, ਅਤੇ background jobs ਨੂੰ ਗਰੁੱਪ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇੱਕੋ ਸਮੇਂ ਵਿੱਚ ਅੰਦਾਜ਼ਾ ਕੀ ਹੋਇਆ ਸੀ।
ਟਾਈਮਸਟੈਂਪ ਅਤੇ severity, request ID ਅਤੇ correlation ID, service ਜਾਂ job ਦਾ ਨਾਂ (API, worker, billing sync), error message ਨਾਲ ਛੋਟਾ stack trace (ਜੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ), retry count, ਅਤੇ final status ਵਰਗੇ ਫ਼ੀਲਡ ਇੱਕ ਦਿੱਖ ਰੱਖੋ।
ਇਸ ਨਾਲ follow-up ਘੱਟ ਹੁੰਦਾ ਹੈ। ਸਪੋਰਟ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ: “ਤੁਹਾਡਾ ਐਕਸਪੋਰਟ 10:14 'ਤੇ ਸ਼ੁਰੂ ਹੋਇਆ, ਦੋ ਵਾਰੀ retry ਕੀਤਾ ਗਿਆ, ਅਤੇ timeout ਨਾਲ ਫੇਲ੍ਹ ਹੋ ਗਿਆ। ਅਸੀਂ ਇਸਨੂੰ ਮੁੜ ਚਲਾਇਆ ਅਤੇ 10:19 'ਤੇ ਮੁਕੰਮਲ ਹੋ ਗਿਆ। Request ID: abc123.”
ਫੀਚਰ ਫਲੈਗਜ਼ ਇੱਕ ਤੇਜ਼ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ ਸਪੋਰਟ ਗਾਹਕ ਦੀ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਪੂਰੇ ਰਿਲੀਜ਼ ਦੀ ਉਡੀਕ ਕੀਤੇ। ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਉਹ ਬਿਨਾਂ ਉਤਸ਼ਾਹ ਦੇ, ਸਪਸ਼ਟ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਚੰਗਾ flags ਵਿਊ ਪਰ-ਯੂਜ਼ਰ ਅਤੇ ਪਰ-ਸੰਗਠਨ ਟੌਗਲ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ, ਨਾਲ ਹੀ staged rollouts (ਜਿਵੇਂ 5%, 25%, 100%)। ਇਸਨੂੰ ਸੰਦਰਭ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਕਿ ਰਾਤ ਦੇ 2 ਵਜੇ ਕਿਸੇ ਨੂੰ ਅਟਕਲ ਨਾ ਹੋਵੇ ਕਿ ਇੱਕ ਫਲੈਗ ਦਾ ਕੀ ਅਸਰ ਹੈ।
ਸਕ੍ਰੀਨ ਨੂੰ ਛੋਟਾ ਪਰ ਕਠੋਰ ਰੱਖੋ। ਹਰ ਫਲੈਗ ਲਈ ਸਪਸ਼ਟ ਵਰਣਨ ਹੋਵੇ ਕਿ ਉਪਭੋਗਤਾ-ਮੁਖੀ ਪ੍ਰਭਾਵ ਕੀ ਹੈ, ਇਕ ਮਾਲਕ, ਸਮੀਖਿਆ ਜਾਂ ਮੁਅੱਤਲ ਤਾਰੀਖ, ਸਕੋਪ ਨਿਯਮ (user, org, environment), ਅਤੇ ਬਦਲਾਅ ਇਤਿਹਾਸ ਜੋ ਦਿਖਾਵੇ ਕਿ ਕਿਨ੍ਹਾਂ ਨੇ ਕਦੋਂ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ।
ਸਪੋਰਟ ਵਰਕਫਲੋ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਅਸਥਾਈ ਰੂਪ ਵਿੱਚ enable ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ ਇੱਕ ਛੋਟੀ ਨੋਟ ਦੇ ਨਾਲ (ਉਦਾਹਰਨ: “Org 143 ਲਈ 2 ਘੰਟਿਆਂ ਲਈ enable ਕਰੋ ਤਾ ਕਿ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਹੋ ਸਕੇ”)। ਜਦ ਟਾਈਮਰ ਖਤਮ ਹੋਵੇ, ਇਹ auto-revert ਹੋ ਜਾਵੇ ਅਤੇ audit log ਵਿੱਚ ਇੱਕ ਟ੍ਰੇਲ ਛੱਡੇ।
ਫਲੈਗਜ਼ experiments ਅਤੇ safe rollouts ਲਈ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਹ ਇੱਕ ਲੰਬੀ-ਅਵਧੀ ਚੋਣ ਹੈ ਜੋ ਗਾਹਕ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਕੰਟਰੋਲ ਕਰੇਗਾ, ਤਾਂ ਇਹ ਅਕਸਰ ਸੈਟਿੰਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ਼ਾਰੇ: ਆਨবোਡਿੰਗ ਜਾਂ ਰੀਨਿਊਅਲ ਦੌਰਾਨ ਬਾਰ-ਬਾਰ ਬੇਨਤੀਆਂ, ਬਿਲਿੰਗ/ਸੀਮਾਵਾਂ/ਕੰਪਲਾਇੰਸ ਵਿੱਚ ਬਦਲਾਅ, UI label ਅਤੇ help text ਦੀ ਲੋੜ, ਜਾਂ ਟੀਮਾਂ ਵਿੱਚ ਸਥਾਈ ਡੀਫਾਲਟ ਫਰਕ।
ਉਦਾਹਰਨ: ਜੇ ਇਕ Koder.ai ਗਾਹਕ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਨਵਾਂ build step ਕੇਵਲ ਉਹਨਾਂ ਦੇ ਵਰਕਸਪੇਸ ਲਈ ਟੁੱਟ ਰਿਹਾ ਹੈ, ਸਪੋਰਟ ਉਸ ਓਰਗ ਲਈ ਅਸਥਾਈ ਤੌਰ ਤੇ ਇਕ compatibility flag enable ਕਰ ਸਕਦੀ ਹੈ, ਰੂਟ ਕਾਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੀ ਹੈ, ਫਿਰ ਜਾਂ ਤਾਂ ਫਿਕਸ ship ਕਰਨਾ ਜਾਂ ਬਰਤਾਓ ਨੂੰ ਇੱਕ ਅਸਲ ਸੈਟਿੰਗ ਵਜੋਂ ਬਦਲ ਦينا।
ਐਕਸਪੋਰਟ ਨਿਰਦੋਸ਼ ਲੱਗਦੇ ਹਨ, ਪਰ ਉਹ ਡਾਟਾ ਲੀਕ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਬਣ ਸਕਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਐਡਮਿਨ ਪੈਨਲਾਂ ਵਿੱਚ, ਐਕਸਪੋਰਟ ਇੱਕ ਐਸਾ ਕਾਰਵਾਈ ਹੈ ਜੋ ਇੱਕ ਕਲਿੱਕ ਵਿੱਚ ਬਹੁਤ ਸੀੰਸਿਟਿਵ ਜਾਣਕਾਰੀ ਦੀ ਨਕਲ ਕਰ ਸਕਦੀ ਹੈ।
ਛੋਟੇ ਸੈਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: users, organizations, billing ਅਤੇ invoices, usage ਜਾਂ credits, ਅਤੇ activity (ਉਪਭੋਗਤਾ ਜਾਂ ਵਰਕਸਪੇਸ ਨਾਲ ਜੁੜੇ events)। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਟ ਯੂਜ਼ਰ-ਨਿਰਮਿਤ ਸਮੱਗਰੀ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਉਸ ਲਈ ਵੱਖਰਾ ਐਕਸਪੋਰਟ ਸੋਚੋ ਅਤੇ ਕੜੀ ਪਰਵਾਨਗੀ ਰੱਖੋ।
ਸਪੋਰਟ ਨੂੰ ਕੰਟਰੋਲ ਦਿਓ ਬਿਨਾਂ ਐਕਸਪੋਰਟ UI ਨੂੰ ਜਟਿਲ ਬਣਾਏ। ਇੱਕ ਮਜ਼ਬੂਤ ਐਕਸਪੋਰਟ ਫਲੋ ਵਿੱਚ ਤਾਰੀਖ ਰੇਂਜ, ਕੁਝ ਮੁੱਖ ਫਿਲਟਰ (status, plan, workspace), ਅਤੇ ਵਿਕਲਪਿਕ ਕਾਲਮ ਚੋਣ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਫ਼ਾਈਲ ਪੜ੍ਹਨਯੋਗ ਹੋਵੇ। ਤੇਜ਼ ਸਹਾਇਤਾ ਲਈ CSV ਬੇਹਤਰ ਹੈ; ਡੀਪ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ JSON ਵਧੀਆ।
ਐਕਸਪੋਰਟਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਤੋਂ ਸੁਰੱਖਿਅਤ ਬਣਾਓ। ਐਕਸਪੋਰਟ ਨੂੰ role-based access control ਦੇ ਪਿੱਛੇ ਰੱਖੋ (ਸਿਰਫ਼ “admin” ਹੀ ਨਹੀਂ), ਸੀਕਰੇਟਸ ਨੂੰ ਡੀਫਾਲਟ ਰੂਪ ਵਿੱਚ redact ਕਰੋ (API keys, tokens, ਪੂਰਾ ਕਾਰਡ ਡੇਟਾ) ਅਤੇ ਜ਼ਰੂਰਤ ਹੋਏ ਤੱਤੇ PII ਮਾਸਕ ਕਰੋ, ਐਕਸਪੋਰਟਾਂ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਵਜੋਂ ਚਲਾਓ ਜਿਸ ਵਿੱਚ ਸਥਿਤੀ (queued, running, ready, failed) ਹੋਵੇ, ਡਾਊਨਲੋਡ ਲਈ ਮਿਆਦ ਰੱਖੋ, ਅਤੇ ਬਹੁਤ ਵੱਡੇ ਐਕਸਪੋਰਟਾਂ ਲਈ ਰੇਟ-ਲਿਮਿਟ ਲਗਾਓ ਜਦ ਤੱਕ ਉੱਚ ਰੋਲ ਮਨਜ਼ੂਰ ਨਾ ਕਰੇ।
ਹਰ ਐਕਸਪੋਰਟ ਨੂੰ ਇੱਕ ਆਡਿਟ ਯਤDeclared event ਵਜੋਂ ਵਰਤੋ। ਲਿਖੋ ਕਿ ਕਿਸ ਨੇ ਐਕਸਪੋਰਟ ਕੀਤਾ, ਕੀ ਕਿਸਮ ਐਕਸਪੋਰਟ ਕੀਤਾ (ਟਾਈਪ, ਫਿਲਟਰ, ਤਾਰੀਖ ਰੇਂਜ, ਕਾਲਮ), ਅਤੇ ਕਿੱਥੇ ਇਹ ਡਿਲਿਵਰ ਕੀਤਾ ਗਿਆ।
ਉਦਾਹਰਨ: ਇੱਕ ਗਾਹਕ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਨੂੰ ਚਾਰਜ ਕੀਤਾ ਗਿਆ। ਸਪੋਰਟ ਆਖਰੀ 30 ਦਿਨਾਂ ਦੀਆਂ ਇਨਵੌਇਸ ਅਤੇ ਵਰਤੋਂ ਐਕਸਪੋਰਟ ਕਰਦੀ ਹੈ, ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਕਾਲਮ (invoice id, amount, period, payment status) ਨਾਲ। ਆਡਿਟ ਲਾਗ ਐਕਸਪੋਰਟ ਵੇਰਵੇ ਕੈਪਚਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਫ਼ਾਈਲ ਨੌਕਰੀ ਖਤਮ ਹੋਣ ਉੱਤੇ ਡਿਲਿਵਰ ਹੁੰਦੀ ਹੈ ਬਿਨਾਂ ਭੁਗਤਾਨ ਵਿਵਰਣ ਦਿਖਾਏ।
ਇੱਕ ਚੰਗਾ support workspace ਟਿਕਟਾਂ ਨੂੰ ਲੋਕਾਂ ਵਿਚਕਾਰ bounce ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਸਵਾਲ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣੇ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: “ਇਸ ਗਾਹਕ ਨਾਲ ਕੀ ਹੋਇਆ, ਅਤੇ ਅਸੀਂ ਪਹਿਲਾਂ ਕੀ-ਕਿਆ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ?”
ਇਕ ਗਾਹਕ ਟਾਈਮਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਿਸਟਮ ਘਟਨਾਵਾਂ ਅਤੇ ਮਨੁੱਖੀ ਸੰਦਰਭ ਨੂੰ ਮਿਲਾਵੇ। ਅੰਦਰੂਨੀ ਨੋਟਸ (ਗਾਹਕ ਨੂੰ ਨਾ ਦਿਖਾਉਣ ਵਾਲੀਆਂ), ਟੈਗ (routing ਲਈ ਜਿਵੇਂ “billing”, “login”, “bug”), ਅਤੇ ਇੱਕ activity feed ਦੁਹਰਾਏ ਕੰਮ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਹਰ ਐਡਮਿਨ ਕਾਰਵਾਈ ਨੂੰ ਉਸੇ ਟਾਈਮਲਾਈਨ ਵਿੱਚ ਦਿਖਾਓ ਜਿਸ ਵਿੱਚ ਕਿਸ ਨੇ ਕਦੋਂ ਕੀ ਕੀਤਾ ਅਤੇ before/after ਕੀ ਸੀ।
ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਾਧਾਰਣ ਰੱਖੋ। ਸਪੋਰਟ ਨੂੰ ਐਸੇ ਟੂਲ ਦਿਓ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਯੂਜ਼ਰ ਨੂੰ ਅਨਬਲੋਕ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਣ ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਡਿਵੈਲਪਰ ਨਹੀਂ ਬਣਾਉਂਦੇ: account lock/unlock (ਕਾਰਨ ਲਾਜ਼ਮੀ), active sessions ਨੂੰ ਅਣਵੈਧ ਕਰਨਾ (force re-login), verification ਜਾਂ password reset emails ਮੁੜ ਭੇਜਣਾ, “recalculate access” ਜਾਂ “refresh subscription status” ਜੌਬ ਟ੍ਰਿਗਰ ਕਰਨਾ, ਜਾਂ ਇੱਕ ਅਸਥਾਈ hold note ਲਗਾਉਣਾ (ਉਦਾਹਰਨ: “review ਤੱਕ refund ਨਾ ਕਰੋ”)।
ਜੇ ਤੁਸੀਂ “login as user” ਜਾਂ ਕਿਸੇ ਕਿਸਮ ਦੀ admin access ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ privileged operation ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ। ਸਪਸ਼ਟ ਯੂਜ਼ਰ ਸਹਿਮਤੀ ਲਾਜ਼ਮੀ ਕਰੋ, ਉਸਨੂੰ ਦਰਜ਼ ਕਰੋ, ਅਤੇ ਪੂਰਾ session start/stop audit trail ਵਿੱਚ ਲਾਗ ਕਰੋ।
ਛੋਟੇ ਟੈਮਪਲੇਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਸਪੋਰਟ ਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦੇ ਹਨ ਕਿ escalation ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਇਕੱਠਾ ਕਰਨਾ ਹੈ: exact error message, timestamp/timezone, ਪ੍ਰਭਾਵਿਤ account ਜਾਂ organization, ਕੀ ਕਦਮ ਲਏ ਗਏ, ਅਤੇ admin ਵਿੱਚ ਪਹਿਲਾਂ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ।
ਉਦਾਹਰਨ: ਇੱਕ ਗਾਹਕ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਦੋ ਵਾਰੀ ਚਾਰਜ ਕੀਤਾ ਗਿਆ। ਸਪੋਰਟ workspace ਖੋਲ੍ਹਦੀ ਹੈ, ਵੇਖਦੀ ਹੈ ਕਿ ਪਹਿਲਾਂ session reset ਕੀਤਾ ਗਿਆ ਸੀ, billing ਸਥਿਤੀ ਜਾਂਚਦੀ ਹੈ, ਫਿਰ ਨੋਟ ਲਿਖਦੀ ਹੈ ਜਿਸ ਵਿੱਚ invoice IDs, ਗਾਹਕ ਦੀ ਪੁਸ਼ਟੀ, ਅਤੇ ਕੀ refund ਕੀਤਾ ਗਿਆ, ਦਰਜ ਹੋਵੇ। ਅਗਲਾ ਏਜੰਟ ਇਹ ਸਭ ਤੁਰੰਤ ਵੇਖ ਲੈਂਦਾ ਹੈ ਅਤੇ ਦੋਹਰਾਉਂਦਾ ਨਹੀਂ।
ਜ਼ਿਆਦਾਤਰ ਐਡਮਿਨ ਪੈਨਲ ਸੁਸਤੀ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਨਈਂ ਕਿ ਟੀਮ ਨੇ ਕੋਈ ਬਹੁਤ ਹੀ ਨਵਾਂ ਫੀਚਰ ਛੱਡ ਦਿੱਤਾ—ਪਰ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਦੈਨਿਕ ਸਪੋਰਟ ਨੂੰ ਸਲੋ, ਖਤਰਨਾਕ, ਜਾਂ ਉਲਝਾਉਣ ਵਾਲਾ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਜੋ ਗਲਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਐਡਮਿਨ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਸਮੇਂ-ਬਚਾਉਣ ਵਾਲਿਆਂ ਦੀ ਥਾਂ ਸਮੱਸਿਆ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਸਪੋਰਟ ਨੂੰ ਇੱਕ ਗਾਹਕ ਦੀ ਮਦਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਬਿਲਿੰਗ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਲਾਗਿਨ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਖੋਜ ਬਿਨਾਂ, ਉਹ ਖਾਤਾ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭ ਸਕਦੇ। audit log ਬਿਨਾਂ, ਉਹ ਪੱਕਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਕੀ ਬਦਲਿਆ। ਬਿਨਾਂ ਢੰਗ ਦੀ role-based access control ਦੇ, ਉਹ ਜਾਂ ਤਾਂ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੁਝ ਕਰ ਕੇ Incident ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਉੱਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਵਜੋਂ ਟਰੀਟ ਕਰੋ: ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਾਹ ਨੂੰ ਆਸਾਨ ਰਾਹ ਬਣਾਓ, ਅਤੇ ਖਤਰਨਾਕ ਰਾਹ ਨੂੰ ਹੌਲਰਾ ਅਤੇ ਤੇਜ਼ ਰੋਕੋ।
“ਮੁਕੰਮਲ” ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹਕੀਕਤ-ਚੈੱਕ ਚਲਾਓ। ਸਭ ਤੋਂ ਵਧੀਆ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਉਹ ਹਨ ਜੋ ਸਪੋਰਟ ਜ਼ੋਰ-ਵਾਲੇ ਦਬਾਅ ਹੇਠ ਵਰਤ ਸਕੇ, ਘੱਟ ਸੰਦਰਭ ਨਾਲ, ਅਤੇ ਚੀਜ਼ਾਂ ਤੋੜਨ ਦੇ ਡਰ ਤੋਂ ਬਿਨਾਂ।
ਸ਼ੁਰੂ ਕਰੋ ਗਤੀ ਨਾਲ। ਜੇ ਇੱਕ ਸਪੋਰਟ ਏਜੰਟ ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ 10 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ (email, ID, ਜਾਂ org ਨਾਲ) ਲੱਭ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਟਿਕਟ ਇੱਕਠੇ ਹੋ ਜਾਣਗੇ। ਪਹਿਲੇ ਐਡਮਿਨ ਦ੍ਰਿਸ਼ 'ਤੇ search ਬਾਕਸ ਦਿੱਖਣਯੋਗ ਰੱਖੋ, ਅਤੇ ਉਹ ਖੇਤਰ ਦਿਖਾਓ ਜੋ ਸਪੋਰਟ ਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਚਾਹੀਦੇ ਹਨ: status, last login, org, plan।
ਅਗਲਾ, ਦੇਖੋ ਕਿ ਬਿਲਿੰਗ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਜਵਾਬਯੋਗ ਹੈ। ਸਪੋਰਟ ਨੂੰ ਮੌਜੂਦਾ ਯੋਜਨਾ, billing status, last payment result, ਅਤੇ ਅਗਲੀ renewal date ਉਹੀ ਪੇਜ ਤੇ ਵੇਖਣ ਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਗਾਹਕ ਦਿਤੀ ਗਈ ਹੈ। ਜੇ ਉਹਨਾਂ ਨੂੰ ਤਿੰਨ ਟੈਬ ਖੋਲ੍ਹਣ ਪੈਂਦੀਆਂ ਹਨ, ਤਾਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਚੈੱਕਲਿਸਟ:
ਹਰ ਖਤਰਨਾਕ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਪਾਵਰ ਟੂਲ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ। ਓਸ ਨੂੰ ਸਹੀ ਪ੍ਰਵਾਨਗੀਆਂ ਪਿੱਛੇ ਰੱਖੋ, ਇੱਕ ਸਪਸ਼ਟ ਪੁਸ਼ਟੀ ਹੋਵੇ, ਅਤੇ ਲਾਗ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਇਹ ਐਡਮਿਨ ਸਕ੍ਰੀਨਸ Koder.ai ਜਿਵੇਂ ਟੂਲ ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਚੈੱਕ ਆਪਣੇ ਪਹਿਲੇ ਵਰਜ਼ਨ ਵਿੱਚ ਬੇਕ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਆ retrofit ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਏ।
ਇੱਕ ਗਾਹਕ ਲਿਖਦਾ ਹੈ: “ਮੈਂ ਯੋਜਨਾ ਬਦਲੀ ਅਤੇ ਹੁਣ ਮੈਂ ਲਾਗਿਨ ਨਹੀਂ ਕਰ ਸਕਦਾ।” ਚੰਗੇ ਐਡਮਿਨ ਸਕ੍ਰੀਨਸ ਇੱਥੇ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਸਪੋਰਟ ਹਰ ਵਾਰ ਇੱਕੋ ਰਾਹ ਫੋਲੋ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਤੋਂ ਬਚ ਸਕਦੀ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਲੌਕਆਊਟ ਨੂੰ ਸਮਝਾਉਣ ਵਾਲੇ ਚੈੱਕਸ: identity, membership, billing state, ਫਿਰ permissions। ਆਮ ਕਾਰਨ ਇਹ ਹਨ ਕਿ ਯੂਜ਼ਰ ਅਜੇ ਵੀ active ਹੈ, ਪਰ ਉਹਨਾਂ ਦੀ organization ਕਿਸੇ ਹੋਰ ਯੋਜਨਾ 'ਤੇ ਚਲੀ ਗਈ, ਭੁਗਤਾਨ past due ਹੈ, ਜਾਂ upgrade ਦੌਰਾਨ role ਬਦਲ ਗਿਆ।
ਪ੍ਰਯੋਗਿਕ ਕ੍ਰਮ:
ਜੇ ਸਭ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਤਾਂ feature flags ਜਾਂਚੋ। ਇੱਕ ਫਲੈਗ ਕਿਸੇ ਨਵੀਂ auth ਵਿਧੀ ਨੂੰ ਕੁਝ ਓਰਗਾਂ ਲਈ ਚਾਲੂ ਕਰ ਸਕਦੀ ਹੈ, ਜਾਂ legacy login ਨੂੰ ਕਿਸੇ ਯੋਜਨਾ ਲਈ ਅਣ-ਚਾਲੂ ਕਰ ਸਕਦੀ ਹੈ। ਲੌਗਸ ਅਤੇ ਫਲੈਗ ਸਥਿਤੀ ਆਮ ਤੌਰ 'ਤੇ ਦੱਸ ਦਿੰਦੇ ਹਨ ਕਿ ਇਹ ਬਗ ਹੈ ਜਾਂ ਕੰਫਿਗਰੇਸ਼ਨ।
ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਪੋਰਟ ਨੋਟਸ ਸਪੱਸ਼ਟ ਲਿਖੋ ਤਾਂ ਕਿ ਅਗਲਾ ਏਜੰਟ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਨਾ ਹੋਵੇ:
ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ escalation ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੇਵਲ ਉਸ ਵੇਲੇ ਜਾਓ ਜਦੋ ਤੁਸੀਂ ਉਪਯੋਗੀ ਸੰਦਰਭ ਜੋੜ ਦਿੰਦੇ ਹੋ: user ID, org ID, timestamps, relevant audit entries, ਅਤੇ ਫਲੈਗ ਸਥਿਤੀ ਉਸ ਸਮੇਂ।
ਵਧੀਆ ਪਹਿਲੀ ਰਿਲੀਜ਼ “ਸਭ ਸਕ੍ਰੀਨ” ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਸਭ ਤੋਂ ਛੋਟਾ ਸੈਟ ਹੁੰਦਾ ਹੈ ਜੋ ਸਪੋਰਟ ਨੂੰ ਬਿਨਾਂ ਇੰਜੀਨੀਅਰ ਦੀ ਮਦਦ ਲਈ ਜ਼ਿਆਦਾਤਰ ਟਿਕਟਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਸ਼ਿਪ ਕਰੋ, ਦੇਖੋ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਫਿਰ ਸਿਰਫ਼ ਉਹੀ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਆਪਣੀ ਜਗ੍ਹਾ ਕਮਾਉਂਦਾ ਹੈ।
v1 ਲਈ, ਉਹ ਛੇ ਸਕ੍ਰੀਨ ਚੁਣੋ ਜੋ ਸਭ ਤੋਂ ਆਮ ਬੇਨਤੀਆਂ ਨੂੰ ਅਨਬਲੋਕ ਕਰਦੀਆਂ ਹਨ: Overview (status + key counts), Users, Organizations, Roles and permissions (RBAC), Billing and usage, ਅਤੇ Logs (audit + system). ਜੇ ਸਪੋਰਟ ਗਾਹਕ ਦੀ ਪਛਾਣ, ਐਕਸੈੱਸ ਦੀ ਪੁਸ਼ਟੀ, ਵਰਤੋਂ ਦੀ ਸਮਝ, ਅਤੇ ਕੀ ਬਦਲਿਆ ਉਸਦੀ ਜਾਣਕਾਰੀ ਦੇ ਸਕਦੀ ਹੈ, ਤਾਂ ਤੁਹੀਂ ਦਿਨ-ਦਰ-ਦਿਨ ਦੇ ਕੰਮ ਦਾ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਹਿੱਸਾ ਕਵਰ ਕਰੋਗੇ।
v1 ਵਰਤੋਂ ਵਿੱਚ ਆਉਣ ਮਗਰੋਂ, ਅਗਲਾ ਸੈਟ ਮਾਪੇ ਹੋਏ ਸਪੋਰਟ ਵਾਲੀਮ ਦੇ ਆਧਾਰ ਤੇ ਚੁਣੋ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਹੁੰਦਾ ਹੈ: invoice/payment ਵੇਰਵੇ, ਡਾਟा ਐਕਸਪੋਰਟ, ਫੀਚਰ ਫਲੈਗਜ਼, support workspace (ਨੋਟਸ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈਆਂ), ਅਤੇ ਕੋਈ ਪ੍ਰੋਡਕਟ-ਖਾਸ ਸੈਟਿੰਗਜ਼ ਜੋ “ਕਿਰਪਾ ਕਰਕੇ ਇਹ ਮੇਰੇ ਲਈ ਬਦਲੋ” ਵਾਲੀਆਂ ਟਿਕਟਾਂ ਚਲਾਉਂਦੀਆਂ ਹਨ।
ਸੀਧੇ ਸਿਗਨਲ ਨਾਲ ਮਾਪੋ ਅਤੇ ਹਫ਼ਤਾਵਾਰ ਸਮੀਖਿਆ ਕਰੋ: ਸਿਖਰ ਟਿਕਟ ਸ਼੍ਰੇਣੀਆਂ ਗਿਣਤੀ ਅਨੁਸਾਰ, ਪਹਿਲੀ ਮਤਲਬਪੂਰਨ ਜਵਾਬ ਤੱਕ ਸਮਾਂ, ਨਿਰਾਖਣ ਤੱਕ ਸਮਾਂ, ਸਪੋਰਟ ਕਿੰਨੀ ਵਾਰ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ escalate ਕਰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਵਰਤੀ ਜਾਂਦੀਆਂ ਹਨ।
ਸਿਖਰ 10 ਕਾਰਵਾਈਆਂ ਲਈ ਛੋਟੇ admin runbooks ਲਿਖੋ (ਹਰ ਇੱਕ 2–5 ਕਦਮ)। ਦਰਜ ਕਰੋ ਕਿ “ਵਧੀਆ” ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ, ਕੀ ਤੋੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ ਰੁਕ ਕੇ escalate ਕਰਨਾ ਹੈ।
ਅਖ਼ੀਰ ਵਿੱਚ, config ਬਦਲਾਅ ਦੇ rollback ਅਤੇ versioning ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਕੋਈ ਵੀ ਸੁਇਚ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ (permissions, flags, billing settings) ਉਸਦੇ ਬਦਲਾਅ ਨੋਟ, ਕਿਸ ਨੇ ਬਦਲਿਆ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ revert ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਇੱਕ ਵਿਕਲਪ ਹੈ ਜੋ ਚੈਟ ਤੋਂ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ planning mode ਅਤੇ snapshots ਨਾਲ ਇਟਰੇਟ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਖਤਰਨਾਕ ਬਦਲਾਅ ਰੋਲਬੈਕ ਕਰਨਾ ਆਸਾਨ ਰਹੇ।
ਉਦੇਸ਼ ਇੱਕ ਐਸਾ ਛੋਟਾ ਸੈਟ ਹੈ ਜੋ ਸਪੋਰਟ ਨੂੰ ਬਿਨਾਂ ਇੰਜੀਨੀਅਰ ਦੀ ਮਦਦ ਲਈ ਜਿਆਦਾਤਰ ਟਿਕਟਾਂ ਨੂੰ end-to-end ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ।
ਇੱਕ ਤਰਤੀਬੀ v1 ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦੀ ਹੈ:
ਪਿਛਲੇ ਮਹੀਨੇ ਦੇ ਆਪਣੇ ਟਿਕਟਾਂ (ਜਾਂ ਪਹਿਲੇ 90 ਦਿਨਾਂ ਲਈ ਉਮੀਦ ਕੀਤੇ ਗਏ ਸਵਾਲਾਂ) ਨੂੰ ਖਿੱਚੋ ਅਤੇ ਹਰ ਨਿਵੇਦਨ ਨੂੰ ਸਕੋਰ ਕਰੋ।
ਸਾਦਾ ਤਰੀਕਾ:
ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਸਪੋਰਟ ਫਲੋ ਦੀ ਆਸ ਦੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਇੱਕ ਚੰਗੀ ਸਕ੍ਰੀਨ ਇੱਕ ਏਜੰਟ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ:
ਜੇ ਏਜੰਟ ਨੂੰ ਹਾਲੇ ਵੀ ਇੰਜੀਨੀਅਰ ਨੂੰ ਪੁੱਛਣਾ ਪੈਂਦਾ ਹੈ “ਇੱਕ ਘੱਟ ਜਾਣਕਾਰੀ” ਲਈ, ਤਾਂ ਸਕ੍ਰੀਨ ਅਜੇ ਵੀ ਅਧੂਰੀ ਹੈ।
ਮੁਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਖੋਜ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ: email, user ID, name ਅਤੇ organization.
ਭਾਈਚਾਰੇ ਅਤੇ ਸਥਿਤੀ ਫੀਲਡ ਜੋ ਸਪੋਰਟ ਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਚਾਹੀਦੇ ਹਨ:
ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਕ ਰੁਟੀਨ ਥਾਂ 'ਤੇ ਰੱਖੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਓ, ਜਿਵੇਂ , , ਅਤੇ , ਜਿਨ੍ਹਾਂ ਲਈ ਲਾਜ਼ਮੀ ਕਾਰਨ ਅਤੇ audit entry ਹੋਵੇ।
ਸਪੋਰਟ ਨੂੰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਬਿਲਿੰਗ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਲਈ ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਹ ਦਿਖਾਓ:
ਖਤਰਨਾਕ ਕੰਟਰੋਲ (cancel/change plan/restart) ਨੂੰ ਦੇਖਣ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ, ਜਿਨ੍ਹਾਂ ਲਈ ਪੁਸ਼ਟੀ ਅਤੇ ਕਾਰਨ ਲਾਜ਼ਮੀ ਹੋਵੇ।
ਇਨਵੌਇਸਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣ ਲਈ optimize ਕਰੋ, ਸੰਪਾਦਨ ਲਈ ਨਹੀਂ।
ਸ਼ਾਮਲ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਕਾਰਵਾਈ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ ਤਾਂ ਉਹ ਸੰਕੁਚਿਤ ਰੱਖੋ (ਉਦਾਹਰਨ: retry payment), ਅਤੇ ਹਰ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਲਾਗ ਕਰੋ।
ਮੀਟਰ ਨੂੰ ਗਾਹਕ ਦੇ ਵੇਖੇ ਹੋਏ ਨਾਲ ਮਿਲਾਓ।
ਘੱਟੋ-ਘੱਟ ਦਿਖਾਓ:
ਸੰਯੰਤਰਿਤ ਨਿਯੰਤਰਿਤ ਕਾਰਵਾਈਆਂ ਹਨ: , , ਜਾਂ , ਸਾਰੇ ਨੋਟਸ ਅਤੇ audit logging ਨਾਲ।
ਹਾਂ—ਦੋਹਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ।
ਇਕੱਠੇ, ਇਹ ਸਪੋਰਟ ਨੂੰ “ਕੀ ਹੋਇਆ” ਬਿਨਾਂ ਅੰਦਾਜ਼ੇ ਦੇਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਕਿਸੇ ਉੱਲਝਣ ਦੇ ਸਮੇਂ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਇੱਕ ਸਥਿਰ event/request ID ਦਿੰਦੇ ਹਨ।
ਫਲੈਗਜ਼ ਨੂੰ ਇੱਕ ਨਿਯੰਤ੍ਰਿਤ ਸਪੋਰਟ ਟੂਲ ਵਜੋਂ ਦੇਖੋ।
ਵਧੀਆ ਡਿਫ਼ਾਲਟ:
ਜੇ ਇਕ ਫਲੈਗ ਲੰਬੇ ਸਮੇਂ ਲਈ ਗਾਹਕ ਕੰਟਰੋਲ ਵਾਂਗ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸੈਟਿੰਗ ਵਿੱਚ ਬਦਲ ਦਿਓ ਅਤੇ UI ਅਤੇ ਹੇਲਪ ਟੈਕਸਟ ਦਿਓ।
ਐਕਸਪੋਰਟ ਡਾਟਾ ਲੀਕ ਕਰਨ ਦੇ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਇਸ ਲਈ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਓ।
ਇਹ ਕਰੋ:
ਸਮਰਥਨ ਲਈ ਸਧਾਰਣ ਫ਼ਲੋ: ਤਾਰੀਖ ਰੇਂਜ, ਕੁਝ ਮੁੱਖ ਫਿਲਟਰ, ਅਤੇ CSV/JSON ਵਿਕਲਪ।