Codex ਦੇ ਨਾਲ ਖੁਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਵਾਲੇ ਟੈਕਸ ਏਜੰਟ ਤਿਆਰ ਕਰਨਾ
ਟੈਕਨੀਕਲ ਸਟਾਫ ਦੇ ਮੈਂਬਰਾਂ ਵੱਲੋਂ: ਅਰਵਿੰਦ ਸ੍ਰੀਨਿਵਾਸਨ ਅਤੇ ਸਮਯ ਸ਼ਾਮਦਾਸਾਨੀ (Thrive Holdings), ਆਰਥਰ ਫਰਨਾਂਡੀਜ਼ ਅਰਾਊਜੋ ਅਤੇ ਜੌਨ ਡੇ ਵਾਸੇਜ (OpenAI)
ਕਿਵੇਂ Thrive Holdings ਅਤੇ OpenAI ਨੇ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੀ ਮਹਾਰਤ ਨੂੰ Codex-ਸੰਚਾਲਿਤ ਲੂਪ ਨਾਲ ਜੋੜ ਕੇ Crete ਅਕਾਊਂਟੈਂਟਾਂ ਲਈ Tax AI ਸਾਂਝੇ ਤੌਰ 'ਤੇ ਵਿਕਸਿਤ ਕੀਤਾ
ਅਸਲ ਦੁਨੀਆ ਦੇ ਸਿਸਟਮ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲੈਬ ਨਾਲੋਂ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਡਿਪਲੋਇਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਇਹ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਲੱਭਦੀਆਂ ਹਨ, ਫਿਰ ਉਹ ਐੱਜ ਕੇਸਾਂ ਦੀ ਜਾਂਚ, ਪ੍ਰੌੰਪਟਾਂ ਦੀ ਸਮਾਂਜਸਤਾ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਫੀਡਬੈਕ ਨੂੰ ਟਿਕਾਊ ਪ੍ਰੋਡਕਟ ਸੁਧਾਰਾਂ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਹਫ਼ਤੇ ਲਗਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਫੀਡਬੈਕ ਲੂਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੈਨੂਅਲ ਅਤੇ ਹੌਲੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਅੱਗੇ ਵਧਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਇੰਜੀਨੀਅਰ ਇਸ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਅੱਜ, ਸੋਚ-ਸਮਝ ਕੇ ਡਿਜ਼ਾਇਨ ਕੀਤੇ ਈਵੈਲ ਢਾਂਚੇ, ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਅਤੇ ਅਸਲ ਦੁਨੀਆ ਦੇ ਵਾਤਾਵਰਣਾਂ ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ, ਅਤੇ Codex ਦੀਆਂ ਅਤਿ-ਆਧੁਨਿਕ ਏਜੰਟਿਕ ਸਮਰੱਥਾਵਾਂ ਨਾਲ ਤੁਸੀਂ ਅਜਿਹੇ ਏਜੰਟ ਬਣਾ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਖੁਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹਨ।
ਇਸ ਪੋਸਟ ਵਿੱਚ, ਅਸੀਂ ਵਿਸਤਾਰ ਵਿੱਚ ਦੱਸਾਂਗੇ ਕਿ ਅਸੀਂ ਇਸ ਕਿਸਮ ਦਾ ਏਜੰਟ ਬਣਾਉਣ ਲਈ Codex ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕੀਤੀ। ਪਿਛਲੇ ਛੇ ਮਹੀਨਿਆਂ ਦੌਰਾਨ OpenAI ਦੇ ਫਾਰਵਰਡ ਡਿਪਲੋਇਡ ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਖੋਜਕਰਤਾਵਾਂ ਨੇ Thrive Holdings ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਮਿਲ ਕੇ Crete(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦੇ 30 ਤੋਂ ਵੱਧ ਅਕਾਊਂਟਿੰਗ ਫਰਮਾਂ ਦੇ ਨੈੱਟਵਰਕ ਲਈ ਅਤੇ ਉਸਦੇ ਨਾਲ ਮਿਲ ਕੇ Tax AI ਬਣਾਇਆ,ਤਾਂ ਜੋ ਦਿਨੋਂ-ਦਿਨ ਗੁੰਝਲਦਾਰ ਹੁੰਦੀਆਂ ਜਾ ਰਹੀਆਂ ਟੈਕਸ ਰਿਟਰਨਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਜਾ ਸਕੇ। ਹਰ ਅਸਫਲਤਾ ਨੂੰ ਲੱਭਣ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਇੰਜੀਨੀਅਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ, Tax AI ਪ੍ਰੋਡਕਸ਼ਨ ਦੇ ਦੌਰਾਨ ਹੋਣ ਵਾਲੀ ਵਰਤੋਂ ਨੂੰ ਅਜਿਹੇ ਸੰਰਚਿਤ ਸੰਕੇਤਾਂ ਵਿੱਚ ਬਦਲਣ ਲਈ Codex ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਸਵੈਚਾਲਿਤ ਸੁਧਾਰ ਨੂੰ ਹੁਲਾਰਾ ਦਿੰਦੇ ਹਨ।
Crete ਦੇ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਹਰ ਸੀਜ਼ਨ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਟੈਕਸ ਰਿਟਰਨਾਂ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਜਿਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਲੱਖਾਂ ਮੂਲ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਦਰਮਿਆਨੀ ਤੋਂ ਉੱਚ ਪੱਧਰ ਦੀਆਂ ਜਟਿਲ ਫਾਈਲਿੰਗਾਂ ਲਈ, ਹਰ ਇੱਕ ਰਿਟਰਨ ਵਿੱਚ ਸਿਰਫ਼ ਡੇਟਾ ਐਂਟਰੀ ਕਰਨ ਵਿੱਚ ਹੀ ਅੱਠ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਅਕਸਰ ਉਲਝੇ ਹੋਏ ਡੇਟਾ ਸਰੋਤ, ਪਿਛਲੇ ਸਾਲ ਦੇ ਦਸਤਾਵੇਜ਼, ਅਤੇ ਮੈਨੂਅਲ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਅਤੇ ਕੈਲਕੂਲੇਸ਼ਨ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਉਹਨਾਂ ਨੇ ਦੱਸਿਆ ਕਿ ਟੈਕਸ ਸੀਜ਼ਨ ਦੇ ਸਭ ਤੋਂ ਵਿਅਸਤ ਸਮੇਂ ਦੌਰਾਨ ਟੈਕਸ ਦੀ ਤਿਆਰੀ ਨੂੰ ਇੱਕ ਵੱਡੀ ਰੁਕਾਵਟ ਹੈ।
ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, Tax AI ਨੇ ਇਸ ਟੈਕਸ ਸੀਜ਼ਨ ਦੌਰਾਨ ਪਾਇਲਟ ਵਿੱਚ ਸ਼ਾਮਲ Crete ਫਰਮਾਂ ਵਿੱਚ 7,000 ਟੈਕਸ ਰਿਟਰਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ। ਇਹ ਸਿਸਟਮ 1040 ਅਤੇ 1041 ਟੈਕਸ ਰਿਟਰਨਾਂ ਤਿਆਰ ਕਰਨ ਦੀ ਸਮੇਂ-ਖਪਤ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਵੱਡੇ ਹਿੱਸੇ ਨੂੰ ਆਟੋਮੈਟਿਕ ਕਰ ਦਿੰਦਾ ਹੈ, ਪਰ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਹੋਏ ਫ਼ਾਇਦੇ ਨਾਲੋਂ ਵੀ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹਿ ਸਿਸਟਮ ਤਿੰਨ ਮਹੀਨੇ ਪਹਿਲਾਂ ਪਹਿਲੀ ਵਾਰ ਡਿਪਲੋਇ ਕੀਤੇ ਗਏ ਸੰਸਕਰਣ ਨਾਲੋਂ ਮਾਪਯੋਗ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਹੈ।
Tax AI ਵਿੱਚ, ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਕਲਾਇੰਟ-ਵਿਸ਼ੇਸ਼ ਨੋਟਸ ਦੇ ਨਾਲ ਸੋਰਸ ਫਾਈਲਾਂ ਅਪਲੋਡ ਕਰਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ, Tax AI ਟੈਕਸ ਇੰਜਣ ਸਬਮਿਸ਼ਨ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਜੋ ਸਮੀਖਿਆ ਲਈ ਬਿਲਕੁਲ ਤਿਆਰ ਹੁੰਦੀ ਹੈ। ਇਹ ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਦਾ ਟੈਕਸ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਲਗਭਗ ਇੱਕ-ਤਿਹਾਈ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, 97% ਤੱਕ ਸ਼ੁੱਧਤਾ ਨਾਲ ਰਿਟਰਨਾਂ ਦਾ ਮਸੌਦਾ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੰਮ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਲਗਭਗ 50% ਵਧਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਨ੍ਹਾਂ ਕੋਲ ਆਪਣੇ ਕਲਾਇੰਟਾਂ ਨਾਲ ਬਿਤਾਉਣ ਲਈ ਵਧੇਰੇ ਸਮਾਂ ਬਚਦਾ ਹੈ।
ਅਸੀਂ ਇਸ ਸੁਧਾਰ ਨੂੰ ਇਹ ਸਮਝ ਕੇ ਮਾਪ ਸਕਦੇ ਹਾਂ ਕਿ Tax AI ਬਾਅਦ ਵਿੱਚ ਸੋਧ ਦੀ ਲੋੜ ਬਿਨਾਂ ਇੱਕ ਰਿਟਰਨ ਕਿੰਨੀ ਸ਼ੁੱਧਤਾ ਨਾਲ ਪੂਰੀ ਕਰ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਸ਼ੁੱਧਤਾ ਨੂੰ ਇਹ ਦੇਖ ਕੇ ਮਾਪਦੇ ਹਾਂ ਕਿ ਕਿੰਨੀ ਰਿਟਰਨਾਂ 75%, 90% ਜਾਂ 100% ਸਹੀ ਫੀਲਡ ਪੂਰਨਤਾ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ। ਲਾਂਚ ਦੇ ਸਮੇਂ, ਕੇਵਲ ਇੱਕ-ਚੌਥਾਈ ਰਿਟਰਨਾਂ ਵਿੱਚ ਹੀ 75% ਸਹੀ ਫੀਲਡ ਮੁਕੰਮਲ ਹੋਏ ਸਨ, ਪਰ ਛੇ ਹਫ਼ਤਿਆਂ ਵਿੱਚ 86% ਰਿਟਰਨਾਂ ਇਸ ਮਾਪਦੰਡ ਤੱਕ ਪਹੁੰਚ ਗਈਆਂ। ਸਿਸਟਮ ਨੇ 90% ਅਤੇ 100% ਸਹੀ ਫੀਲਡ ਮੁਕੰਮਲ ਹੋਣ ਦੇ ਪੱਧਰਾਂ 'ਤੇ ਹੋਰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਵਾਧਾ ਦਿਖਾਇਆ। ਇਹ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸਾਨੂੰ ਵਿਹਾਰਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦਿੰਦੇ ਹਨ ਕਿ ਵੱਖ-ਵੱਖ ਰਿਟਰਨਾਂ ਲਈ ਹਾਲੇ ਵੀ ਕਿੰਨੀ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਫਾਲੋ-ਅਪ ਦੀ ਲੋੜ ਹੈ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ, Tax AI ਨੇ W-2s ਅਤੇ 1099s ਵਰਗੇ ਸਧਾਰਨ ਕੰਮ ਸੰਭਾਲੇ। ਜਿਵੇਂ-ਜਿਵੇਂ ਟੈਕਸ ਦਾ ਸੀਜ਼ਨ ਅੱਗੇ ਵਧਿਆ, ਇਸ ਨੇ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਰਿਟਰਨਾਂ 'ਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਵਿੱਚ K-1s, ਸ਼ਡਿਊਲ ਅਤੇ ਹੋਰ ਮੁਸ਼ਕਲ ਮਾਮਲੇ ਸ਼ਾਮਲ ਸਨ। ਹਰ ਨਵੀਂ ਸਮਰੱਥਾ ਨੇ ਪਿਛਲੀ ਮੁਕਾਬਲੇ ਪ੍ਰਤੀ ਰਿਟਰਨ ਵਧੇਰੇ ਸਮਾਂ ਬਚਾਇਆ ਕਿਉਂਕਿ ਜਿਨ੍ਹਾਂ ਕੰਮਾਂ ਨੂੰ ਇਸ ਨੇ ਸੰਭਾਲਿਆ ਉਹ ਹੱਥੋਂ ਕਰਨ ਲਈ ਹੋਰ ਮੁਸ਼ਕਲ ਅਤੇ ਵੱਧ ਸਮੇਂ ਵਾਲੇ ਸਨ। ਅਸੀਂ ਅੱਜ ਵੀ ਲਗਾਤਾਰ ਪ੍ਰਗਤੀ ਦੇਖ ਰਹੇ ਹਾਂ।
ਅਗਲੇ ਹਿੱਸੇ ਵਿੱਚ, ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਚਰਚਾ ਕਰਾਂਗੇ ਕਿ ਕਿਵੇਂ ਸਾਡੀਆਂ ਟੀਮਾਂ ਨੇ ਤਿੰਨ ਮਹੱਤਵਪੂਰਨ ਪੜਾਵਾਂ ਦਾ ਸਹਾਰਾ ਲੈ ਕੇ Tax AI ਨੂੰ ਸਵੈ-ਸੁਧਾਰਕ ਦੇ ਯੋਗ ਬਣਾਉਣ ਲਈ ਮਿਲ ਕੇ ਕੰਮ ਕੀਤਾ ਹੈ: 1) ਮਾਹਰ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੀ ਫੀਡਬੈਕ, 2) ਪ੍ਰੋਡਕਸ਼ਨ ਟ੍ਰੇਸਿਸ (ਇਨਪੁੱਟ ਤੋਂ ਅੰਤਿਮ ਆਉਟਪੁੱਟ ਤੱਕ ਦਾ ਸੰਰਚਿਤ ਇਤਿਹਾਸ), ਅਤੇ 3) ਲਗਾਤਾਰ ਤੇਜ਼ ਪ੍ਰੋਡਕਟ ਵਿਕਾਸ ਯੋਗ ਬਣਾਉਣ ਲਈ ਖਾਸ ਈਵੈਲਜ਼ 'ਤੇ ਆਧਾਰਿਤ Codex-ਸੰਚਾਲਿਤ ਇਟਰੇਸ਼ਨ ਲੂਪ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡਾ ਇਹ ਅਨੁਭਵ ਉਨ੍ਹਾਂ ਹੋਰ ਨਿਰਮਾਤਾਵਾਂ ਲਈ ਲਾਭਕਾਰੀ ਹੋਵੇਗਾ ਜਿੱਥੇ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੀ ਮਹਾਰਤ ਵੱਡੇ ਸਿਸਟਮ ਅਤੇ ਉਸ ਵਿੱਚ ਚੱਲ ਰਹੇ ਡਾਟਾ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਆਕਾਰ ਦੇਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਜਿਵੇਂ-ਜਿਵੇਂ Tax AI ਹੋਰ ਜਟਿਲ ਫਾਈਲਿੰਗਾਂ ਤੱਕ ਫੈਲਿਆ, ਸਕੋਰ ਕੀਤੀਆਂ ਰਿਟਰਨਾਂ ਵਿੱਚ 75%, 90% ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁਕੰਮਲ ਹੋਣ ਵਾਲਾ ਹਿੱਸਾ ਟੈਕਸ ਸੀਜ਼ਨ ਦੌਰਾਨ ਲਗਾਤਾਰ ਵਧਦਾ ਗਿਆ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਅਸੀਂ ਟੈਕਸ ਤਿਆਰੀ ਦੇ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹਿੱਸਿਆਂ (K-1s, ਰੈਂਟਲ ਰੀਅਲ ਐਸਟੇਟ ਸ਼ਡਿਊਲ, ਅਤੇ ਉਹ ਟੈਕਸ ਫਾਰਮ ਜਿੱਥੇ ਕਈ ਸਰੋਤ ਫਾਈਲਾਂ ਵਿੱਚੋਂ ਅੰਕੜਿਆਂ ਦਾ ਮਿਲਾਨ ਕਰਨਾ ਸੀ) ਵੱਲ ਵਧੇ, ਇਹ ਸਪਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਅਸਲ ਚੁਣੌਤੀ ਇਹ ਸੀ ਕਿ ਕੀ ਪ੍ਰੋਡਕਟ ਸਿਸਟਮ ਦੀਆਂ ਜਟਿਲ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣ, ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਸੁਧਾਰਨਯੋਗ ਬਣਾ ਸਕਦਾ ਹੈ।
ਪ੍ਰੋਡਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ ਸੁਧਾਰ ਖੁਦ ਕੀਤੇ ਜਾਂਦੇ ਸਨ। ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਸਿਸਟਮ ਦੀਆਂ ਗਲਤੀਆਂ ਠੀਕ ਕਰ ਸਕਦੇ ਸਨ, ਪਰ ਪ੍ਰੋਡਕਟ ਉਸ ਦੇ ਪੂਰੇ ਸੰਦਰਭ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ; ਜਿਵੇਂ ਕਿ ਫਾਈਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਿਆ ਗਿਆ ਕੋਈ ਅੰਕੜਾ ਅਸਲ ਵਿੱਚ ਡੇਟਾ ਕੱਢਣ ਦੀ ਗਲਤੀ, ਮੈਪਿੰਗ ਦੀ ਸਮੱਸਿਆ, ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਸਮਰਥਨ ਦੀ ਕਮੀ ਜਾਂ ਵਰਕਫਲੋ ਦੀ ਆਮ ਗੜਬੜੀ ਹੋ ਸਕਦਾ ਸੀ। ਇਨ੍ਹਾਂ ਸਾਰੇ ਮਾਮਲਿਆਂ ਨੂੰ ਵੱਖਰਾ ਕਰਨ ਲਈ ਅਜੇ ਵੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਦੇ ਫਾਲੋ-ਅੱਪ ਦੀ ਲੋੜ ਪੈਂਦੀ ਸੀ। ਹਾਲਾਂਕਿ ਇੰਜੀਨੀਅਰ ਕੋਡਿੰਗ ਏਜੰਟਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਸਨ, ਪਰ ਸਿਸਟਮ ਨੂੰ ਅਜੇ ਤੱਕ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿ ਸੁਧਾਰ ਦੇ ਲੂਪ ਵਿੱਚ AI ਨੂੰ ਅਰਥਪੂਰਨ ਢੰਗ ਨਾਲ ਵਰਤਿਆ ਜਾ ਸਕੇ। ਸਾਡੇ ਕੋਲ ਇਹ ਪਛਾਣਨ ਲਈ ਕੋਈ ਸਪਸ਼ਟ ਸੰਕੇਤ ਨਹੀਂ ਸੀ ਕਿ ਸਾਨੂੰ ਕਿਸ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸੇ ਕਾਰਨ ਅਸੀਂ ਸਿਸਟਮ ਨੂੰ ਤਿੰਨ ਮੁੱਖ ਸਤੰਭਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕੀਤਾ:
- ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨਾ: ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਇਹ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਉਨ੍ਹਾਂ ਦੇ ਹੱਥ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪ੍ਰੋਡਕਟ ਨੇ ਕੀ ਸਿੱਖਣਾ ਹੈ। ਉਨ੍ਹਾਂ ਦਾ ਅਨੁਭਵ ਅਤੇ ਸਮਝ ਇਹ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਅੱਗੇ ਵਰਕਫਲੋ ਦੇ ਕਿਹੜੇ ਹਿੱਸਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
- ਪ੍ਰੋਡਕਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਦੌਰਾਨ ਸਪਸ਼ਟ ਸਬੂਤ ਮਿਲ ਸਕਣ: ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਸਿਰਫ਼ ਇਨਪੁਟ ਅਤੇ ਆਊਟਪੁਟ ਨੂੰ ਹੀ ਰਿਕਾਰਡ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ; ਬਲਕਿ ਇਸ ਵਿੱਚ ਮੂਲ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਲੈ ਕੇ ਕੱਢੇ ਗਏ ਡੇਟਾ ਅਤੇ ਉਸ ਦੇ ਸਰੋਤ, ਅਤੇ ਅੱਗੇ ਫਾਈਲ ਕੀਤੇ ਜਾਣ ਤੋਂ ਲੈ ਕੇ ਮਾਹਿਰਾਂ ਵੱਲੋਂ ਕੀਤੇ ਗਏ ਸੁਧਾਰਾਂ ਤੱਕ ਦੇ ਪੂਰੇ ਸਫ਼ਰ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।
- Codex-ਸੰਚਾਲਿਤ ਸੁਧਾਰ ਲੂਪ ਤਿਆਰ ਕਰਨਾ: ਇੱਕ ਵਾਰ ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਪਸ਼ਟ ਅਤੇ ਇੱਕ ਵਿਵਸਥਿਤ ਰੂਪ ਵਿੱਚ ਸਾਹਮਣੇ ਆ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਮਹੱਤਵਪੂਰਨ ਨਤੀਜਿਆਂ, ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਈਵੈਲਜ਼ ਅਤੇ ਸੀਮਾਬੱਧ ਇੰਜੀਨੀਅਰਿੰਗ ਕਾਰਜਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ, Codex ਸਮੱਸਿਆ ਦੀ ਜਾਂਚ ਕਰਨ, ਬਦਲਾਵਾਂ ਦਾ ਸੁਝਾਅ ਦੇਣ, ਨਿਸ਼ਾਨਾਬੱਧ ਅਤੇ ਰੀਗ੍ਰੈਸ਼ਨ ਈਵੈਲਜ਼ ਰਾਹੀਂ ਉਨ੍ਹਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪ੍ਰੋਡਕਟ ਨੂੰ ਕਿਸੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਥੀਂ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਸੁਧਾਰ ਚੱਕਰ ਦੇ ਮੁਕਾਬਲੇ ਕਿਤੇ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਹੇਠਾਂ ਦਿੱਤੀ ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀ ਦੀ ਉਦਾਹਰਨ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਹ ਲੂਪ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਤੁਹਾਨੂੰ ਇਸ ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਦੱਸੇਗਾ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਵੱਲੋਂ ਕੀਤਾ ਗਿਆ ਸੁਧਾਰ ਪਹਿਲਾਂ ਵਿਵਸਥਿਤ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਫਿਰ ਈਵੈਲ ਟੀਚਾ ਬਣਦਾ ਹੈ ਅਤੇ ਅਖੀਰ ਵਿੱਚ Codex-ਸੀਮਿਤ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀ ਆਮਦਨ ਨੂੰ ਕਿਸੇ ਵਿਅਕਤੀ ਦੇ ਟੈਕਸ ਰਿਟਰਨ ਦੇ ਸ਼ੈਡਿਊਲ E ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਸ ਡੇਟਾ ਨੂੰ ਕੱਢਣ ਦੇ ਕੰਮ ਨੂੰ ਵਰਣਨ ਕਰਨਾ ਤਾਂ ਸੌਖਾ ਹੈ ਪਰ ਇਸ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਨਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ। ਸਿਸਟਮ ਨੂੰ ਉਲਝੀ ਹੋਈ ਸਰੋਤ ਸਮੱਗਰੀ (ਹੱਥ ਨਾਲ ਲਿਖੇ ਨੋਟਸ, ਈਮੇਲਾਂ, ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਅਤੇ ਹੋਰ ਕਲਾਇੰਟ ਫਾਈਲਾਂ) ਨੂੰ ਪੜ੍ਹਨਾ ਪੈਂਦਾ ਹੈ, ਉਹ ਰੈਂਟਲ-ਪ੍ਰਾਪਰਟੀ ਫੀਲਡਾਂ ਕੱਢਣੇ ਪੈਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਸਟਮ ਪੂਰੇ ਭਰੋਸੇ ਨਾਲ ਟੈਕਸ ਇੰਜਨ ਨਾਲ ਮੈਪ ਕਰ ਸਕੇ, ਅਤੇ ਇਸ ਦੇ ਨਾਲ ਹੀ ਇੰਨੇ ਸਬੂਤ ਸੰਭਾਲ ਕੇ ਰੱਖਣੇ ਪੈਂਦੇ ਹਨ ਕਿ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਨਤੀਜੇ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕੇ ਜਾਂ ਉਸ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕੇ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਰਲ ਉਦਾਹਰਨ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਉਹ ਸਰੋਤ ਫਾਈਲਾਂ ਅਤੇ ਕੱਢੇ ਗਏ ਆਉਟਪੁੱਟ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ।
ਇੱਕ ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀ ਦੇ ਸੋਰਸ ਪੈਕੇਜ ਨੂੰ ਡਾਊਨਸਟ੍ਰੀਮ ਟੈਕਸ ਇੰਜਣ ਸੰਕਲਪਾਂ ਨਾਲ ਮੈਪ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹਵਾਲੇ ਦਿੱਤੇ ਖੇਤਰਾਂ ਵਿੱਚ ਸਧਾਰਨੀਕਰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਏਜੰਟ ਵੱਲੋਂ ਅਨੁਮਾਨਿਤ ਮੁੱਲ ਅਤੇ ਫਾਈਲ ਕੀਤੀ ਗਈ ਟੈਕਸ ਰਿਟਰਨ ਦੇ ਅਸਲ ਮੁੱਲ ਵਿਚਕਾਰ ਅੰਤਰ ਸ਼ਾਇਦ ਡੇਟਾ ਕੱਢਣ ਦੀ ਗਲਤੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੀ ਪਸੰਦ, ਟੈਕਸ ਇੰਜਣ ਵਿੱਚ ਪਿਛਲੇ ਸਾਲ ਦੀ ਰਿਟਰਨ ਤੋਂ ਅੱਗੇ ਲਿਆਂਦਾ ਗਿਆ ਮੁੱਲ, ਜਾਂ ਫਾਈਲਿੰਗ ਵਰਕਫਲੋ ਦੇ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂ ਬਦਲਿਆ ਗਿਆ ਮੁੱਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਨੇ ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਅੰਤਰ ਸਮਝਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕੀਤੀ ਤਾਂ ਜੋ ਅਸੀਂ ਇਹ ਪਛਾਣ ਸਕੀਏ ਕਿ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੁਆਰਾ ਸੋਧ ਦੀ ਲੋੜ ਸੀ ਜਾਂ ਕਿਸ ਕਾਰਨ ਸਬਮਿਸ਼ਨ ਰੁਕ ਰਹੀ ਸੀ।
ਕਿਉਂਕਿ ਅਸੀਂ ਇਹਨਾਂ ਸੋਧਾਂ ਨੂੰ ਬਾਰੀਕੀ ਨਾਲ ਦੇਖ ਸਕਦੇ ਸੀ, ਇਸ ਲਈ ਅਸੀਂ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਵਾਲੇ ਇੱਕ ਆਖਰੀ ਕਦਮ ਦੀ ਬਜਾਏ ਨਿਰੰਤਰ ਸਿੱਖਣ ਦੇ ਚੱਕਰ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਅਸੀਂ ਵਰਕਫਲੋ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਹੈ ਕਿ ਮਾਹਰਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੰਰਚਿਤ ਡੇਟਾ ਵਜੋਂ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾ ਸਕੇ। ਹੁਣ, ਹਰ ਇੱਕ ਦਖਲਅੰਦਾਜ਼ੀ ਪ੍ਰੋਡਕਟ ਦੇ ਸੁਧਾਰ ਲੂਪ ਨੂੰ ਹੋਰ ਮਜ਼ਬੂਤ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਬਿਲਕੁਲ ਸਹੀ ਢੰਗ ਨਾਲ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ ਕਿ Tax AI ਨੇ ਕੀ ਸੁਝਾਅ ਦਿੱਤਾ ਸੀ, ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਨੇ ਉਸ ਵਿੱਚ ਕੀ ਬਦਲਾਅ ਕੀਤਾ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਫਾਈਲ ਕੀਤੀ ਗਈ ਰਿਟਰਨ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੋਇਆ।
ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀਜ਼ ਵਰਗੇ ਜਟਿਲ ਵਰਕਫਲੋ ਲਈ ਸਿਸਟਮ ਨੂੰ ਸਰੋਤ ਫਾਈਲਾਂ ਅਤੇ ਫਾਈਲ ਕੀਤੀ ਰਿਟਰਨ ਦੇ ਵਿਚਕਾਰ ਜੋ ਕੁਝ ਹੁੰਦਾ ਹੈ, ਉਹ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ। ਇਸ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਵਿਵਸਥਿਤ, ਵੱਖ ਅਤੇ ਵਰਗੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਰੈਂਟਲ-ਪ੍ਰਾਪਰਟੀ ਫੀਲਡਾਂ ਨੂੰ ਸਰੋਤ ਸਮੱਗਰੀ ਦੇ ਹਵਾਲਿਆਂ ਸਮੇਤ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ; ਉਹਨਾਂ ਮੁੱਲਾਂ ਨੂੰ ਟੈਕਸ ਇੰਜਣ ਵਿੱਚ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਅਤੇ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਫਾਈਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੀ ਉਹਨਾਂ ਵਿੱਚ ਸੋਧ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਪ੍ਰੋਡਕਟ-ਪੱਧਰੀ ਟ੍ਰੇਸਿਸ ਇਹ ਜਾਂਚਣਾ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ ਅਸਫਲਤਾ ਕਿੱਥੇ ਹੋਈ ਸੀ। ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਸੋਧਾਂ ਨੂੰ ਲਾਭਕਾਰੀ ਈਵੈਲ ਟੀਚਿਆਂ ਵਿੱਚ ਬਦਲਣ ਲਈ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਤਿੰਨ ਕਦਮਾਂ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ:
- ਅੰਤਰ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ: Tax AI ਦੇ ਆਉਟਪੁੱਟ ਦੀ ਫਾਈਲ ਕੀਤੀ ਰਿਟਰਨ ਨਾਲ ਤੁਲਨਾ ਕਰਕੇ ਫੀਲਡ-ਪੱਧਰੀ ਸਮੀਖਿਆ ਕਤਾਰਾਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜੋ ਉਮੀਦਿਤ ਮੁੱਲ, ਅਨੁਮਾਨਿਤ ਮੁੱਲ ਅਤੇ ਇਸ ਗੱਲ ਨੂੰ ਦਰਜ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕੀ ਉਹ ਅੰਤਰ ਕਾਰਵਾਈ-ਯੋਗ ਲੱਗਦਾ ਹੈ।
- ਸੰਬੰਧਿਤ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਮੂਹਬੱਧ ਕਰਨਾ: ਇੱਕੋ ਜਿਹੀਆਂ ਸਮੀਖਿਆ ਕਤਾਰਾਂ ਨੂੰ ਸਮੂਹਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀਆਂ ਪ੍ਰੋਡਕਟ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਆਮ ਵਰਕਫਲੋ ਦੀ ਆਮ ਗੜਬੜੀ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕੇ। ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੁਆਰਾ ਵਾਰ-ਵਾਰ ਕੀਤੇ ਗਏ ਸੁਧਾਰ ਇਹ ਦਰਸਾ ਸਕਦੇ ਹਨ ਕਿ Tax AI ਅਕਸਰ “ਫੇਅਰ-ਰੈਂਟਲ-ਡੇਅ” ਦੇ ਫੀਲਡਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, “ਹੋਰ ਖਰਚਿਆਂ” ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ, ਜਾਂ ਇੱਕੋ ਸਰੋਤ ਪੈਕੇਜ ਵਿੱਚ ਮੌਜੂਦ ਕਈ ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀਆਂ ਵਿਚਕਾਰ ਉਲਝ ਜਾਂਦਾ ਹੈ।
- ਵਾਰ-ਵਾਰ ਸਾਹਮਣੇ ਆਉਣ ਵਾਲੇ ਪੈਟਰਨਾਂ ਨੂੰ ਈਵੈਲ ਟੀਚਿਆਂ ਵਿੱਚ ਬਦਲੋ: ਇੱਕ ਵਾਰ ਸਮੀਖਿਆ ਅਤੇ ਮਾਪ ਜਾਣ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਇਹ ਵਾਰ-ਵਾਰ ਸਾਹਮਣੇ ਆਉਣ ਵਾਲੇ ਨਤੀਜੇ Codex ਦੇ ਸੁਧਾਰ ਲਈ ਸਪੱਸ਼ਟ ਈਵੈਲ ਟੀਚੇ ਬਣ ਜਾਂਦੇ ਹਨ।
ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀ ਸਮੀਖਿਆ ਕਤਾਰਾਂ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀਆਂ ਪ੍ਰੋਡਕਟ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਉਮੀਦ ਕੀਤੀ ਗਈ ਆਮ ਗੜਬੜੀ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਕਾਰਵਾਈਯੋਗ ਮਾਮਲਿਆਂ ਨੂੰ ਈਵੈਲ ਟੀਚਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ ਜੋ Codex ਨੂੰ ਅੱਗੇ ਵਧਣ ਲਈ ਇੱਕ ਚੁਣੌਤੀ ਦਿੰਦੇ ਹਨ।
ਤੀਜਾ ਸਤੰਭ ਅਜਿਹਾ ਇੰਜੀਨੀਅਰਿੰਗ ਲੂਪ ਬਣਾਉਣਾ ਹੈ ਜੋ ਇਹਨਾਂ ਨਵੇਂ ਈਵੈਲਜ਼ ਦੇ ਅਧਾਰ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇ। ਇੱਥੇ Codex ਕੇਂਦਰੀ ਬਣ ਜਾਂਦਾ ਹੈ।
ਮੰਨ ਲਓ ਕਿ ਸਾਡੀ ਈਵੈਲਜ਼ ਪਾਈਪਲਾਈਨ ਇਹ ਪਛਾਣ ਕਰਦੀ ਹੈ ਕਿ Tax AI ਲਗਾਤਾਰ "ਫੇਅਰ-ਰੈਂਟਲ-ਡੇਅਜ਼" ਫੀਲਡ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਇਸ ਨੂੰ ਭਰ ਦਿੰਦੇ ਹਨ। ਕਿਉਂਕਿ ਇਹ ਨਤੀਜਾ ਪਹਿਲਾਂ ਹੀ ਨਿਸ਼ਾਨਾਬੱਧ ਈਵੈਲ ਸੈੱਟ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਤੀਨਿਧੀ ਸਰੋਤ ਪੈਕੇਜ ਅਤੇ ਉਮੀਦਿਤ ਆਉਟਪੁੱਟ ਸ਼ਾਮਲ ਹਨ, ਇਸ ਲਈ Codex ਪ੍ਰੋਡਕਟ ਸਕੈਫੋਲਡ ਦੇ ਅੰਦਰ ਹੀ ਮੂਲ ਕਾਰਨ ਦੀ ਸਿੱਧੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ।
Codex ਸਿਰਫ਼ ਕਿਸੇ ਔਸਤ ਤੋਂ ਘੱਟ ਅੰਤਿਮ ਆਊਟਪੁੱਟ ਦੇ ਸਹਾਰੇ ਹੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਟ੍ਰੇਸ, ਈਵੈਲ, ਰੈਪੋ ਅਤੇ ਸਕਿੱਲਜ਼ ਦੀ ਇਕੱਠਿਆਂ ਜਾਂਚ ਕਰਦਾ ਹੈ:
- ਪਾਈਪਲਾਈਨ ਦੀ ਜਾਂਚ ਕਰੋ: ਸਰੋਤ ਪੈਕੇਜਾਂ, ਐਕਸਟਰੈਕਸ਼ਨ ਸਕੀਮਾ, ਮੈਪਰ ਦੇ ਵਿਹਾਰ ਅਤੇ ਕੋਡ ਪਾਥਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਪਤਾ ਲਗਾਇਆ ਜਾ ਸਕੇ ਕਿ ਸਮੱਸਿਆ ਅਣ-ਸਮਰਥਿਤ ਫੀਲਡ, ਛੁੱਟ ਗਿਆ ਐਕਸਟਰੈਕਸ਼ਨ ਪੈਟਰਨ, ਸਰੋਤ-ਚੋਣ ਦੀ ਸਮੱਸਿਆ, ਮੈਪਰ ਦੀ ਕਮੀ ਜਾਂ ਗ੍ਰੇਡਰ ਦੀ ਕੋਈ ਸਮੱਸਿਆ ਹੈ।
- ਨਿਸ਼ਾਨਾਬੱਧ ਸੁਧਾਰ ਲਾਗੂ ਕਰੋ: ਐਕਸਟਰੈਕਸ਼ਨ ਸਕੀਮਾ ਦਾ ਵਿਸਤਾਰ ਕਰੋ, ਰੈਂਟਲ-ਪ੍ਰਾਪਰਟੀ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਸਰੋਤ-ਚੋਣ ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ, ਟੈਕਸ-ਇੰਜਣ ਮੈਪਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ, ਜਾਂ ਜੇਕਰ ਉਮੀਦਿਤ ਵਰਕਫਲੋ ਦੀ ਆਮ ਗੜਬੜੀ ਨੂੰ ਅਸਫਲਤਾ ਵਜੋਂ ਗਿਣਿਆ ਜਾ ਰਿਹਾ ਹੈ ਤਾਂ ਗ੍ਰੇਡਰ ਨੂੰ ਹੋਰ ਬਿਹਤਰ ਬਣਾਓ।
- ਪ੍ਰਮਾਣਿਤ ਕਰੋ ਅਤੇ ਪ੍ਰਸਤਾਵ ਦਿਓ: ਨਿਸ਼ਾਨਾਬੱਧ ਈਵੈਲ ਨੂੰ ਮੁੜ ਚਲਾਓ, ਵਿਆਪਕ ਰਿਗ੍ਰੇਸ਼ਨ ਸੂਟ ਚਲਾਓ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੀਖਿਆ ਲਈ ਸੰਭਾਵੀ ਪੁੱਲ ਰਿਕਵੈਸਟ ਪੇਸ਼ ਕਰੋ।
- ਲੂਪ ਨੂੰ ਪੂਰਾ ਕਰੋ: ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਸੋਧ ਨੂੰ ਮਾਪਯੋਗ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਵਿੱਚ ਬਦਲੋ। ਜੇਕਰ ਸਬੂਤ ਅਸਪਸ਼ਟ ਹੋਣ ਜਾਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਆਟੋਮੇਟ ਨਾ ਕੀਤੇ ਜਾ ਸਕਣ, ਤਾਂ ਮਾਮਲਾ ਲੂਪ ਵਿੱਚ ਜ਼ਬਰਦਸਤੀ ਧੱਕਣ ਦੀ ਬਜਾਏ ਮੁੜ ਪ੍ਰੋਡਕਟ ਟੀਮ ਕੋਲ ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਖੁਦ-ਸੁਧਾਰ ਦਾ ਲੂਪ: ਪ੍ਰੋਡਕਸ਼ਨ ਟ੍ਰੇਸਿਜ਼ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀਆਂ ਫੀਲਡ-ਪੱਧਰੀ ਸੋਧਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ, ਜੋ ਅਸਫਲਤਾ ਦੇ ਸੰਕੇਤ ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ Codex ਟ੍ਰੇਸ, ਈਵੈਲਜ਼, ਰੈਪੋ ਅਤੇ ਸਕਿੱਲਜ਼ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ। ਕਾਰਵਾਈਯੋਗ ਪੈਟਰਨ ਸੀਮਿਤ ਈਵੈਲਜ਼ ਅਤੇ ਸੰਭਾਵੀ ਪ੍ਰੋਡਕਟ ਬਦਲਾਵਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ; ਅਸਪਸ਼ਟ ਮਾਮਲੇ ਸਮੀਖਿਆ ਲਈ ਮੁੜ ਇੰਜੀਨੀਅਰਾਂ ਕੋਲ ਭੇਜ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਹਰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੁਧਾਰ ਅਗਲੇ ਚੱਕਰ ਲਈ ਨਵਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸਬੂਤ ਬਣਾਉਂਦਾ ਹੈ।
ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀ ਦੀ ਇਹ ਉਦਾਹਰਨ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਵਿਆਪਕ ਪੈਟਰਨ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦੀ ਹੈ: ਏਜੰਟ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਸੁਧਾਰਣ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਆਰਟੀਫੈਕਟ ਅਤੇ ਟ੍ਰੇਸਿਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾ ਤੋਂ ਸਮੀਖਿਆ ਕੀਤੇ ਨਤੀਜੇ, ਸਰੋਤ ਟ੍ਰੇਸਿਸ, ਟੈਕਸ-ਇੰਜਣ ਦਾ ਉਮੀਦਿਤ ਆਉਟਪੁੱਟ, ਸੰਬੰਧਿਤ ਕੋਡ ਉਦਾਹਰਨਾਂ ਅਤੇ ਈਵੈਲ ਕਮਾਂਡਾਂ ਨੂੰ ਇਨਪੁੱਟ ਦੇ ਇੱਕ ਸੈੱਟ ਵਜੋਂ ਲੈ ਕੇ Codex ਆਉਣ ਵਾਲੇ ਹਫ਼ਤਿਆਂ ਅਤੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸ਼ੁੱਧਤਾ ਵਿੱਚ ਠੋਸ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਸਾਡੇ ਹਾਰਨੈਸ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਸਿੰਫਨੀ ਦੇ ਕੰਮ ਵਿੱਚ ਵਰਣਿਤ ਸਿਧਾਂਤਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਜੋ ਵਿਸਤਾਰ ਵਿੱਚ ਦੱਸਦੇ ਹਨ ਕਿ ਕਾਰਜਾਂ ਨੂੰ Codex ਲਈ ਕਿਵੇਂ ਸਪਸ਼ਟ ਬਣਾਉਣਾ ਹੈ, ਸੀਮਿਤ ਸੰਦਰਭ ਅਤੇ ਟੂਲਸ ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕਰਨੇ ਹਨ, ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਅਤੇ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਨੂੰ ਸਿਸਟਮ ਦੇ ਮਾਹੌਲ ਦਾ ਹਿੱਸਾ ਕਿਵੇਂ ਬਣਾ ਕੇ ਰੱਖਣਾ ਹੈ।
ਉਹ ਸਬੂਤ ਆਪਣੇ ਆਪ Codex ਦੇ ਕਾਰਜ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੇ ਹਨ। ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਸੋਧ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਕਮੀ, ਮੈਪਿੰਗ ਦੀ ਸਮੱਸਿਆ, ਪ੍ਰੋਡਕਟ ਦੇ ਅਣ-ਸਮਰਥਿਤ ਵਿਹਾਰ, ਟੈਕਸ ਦੇ ਫੈਸਲੇ ਜਾਂ ਉਮੀਦਿਤ ਵਰਕਫਲੋ ਦੀ ਆਮ ਗੜਬੜੀ ਦੇ ਕਾਰਨ ਹੋ ਸਕਦੀ ਹੈ। ਕੇਵਲ ਵਾਰ-ਵਾਰ ਸਾਹਮਣੇ ਆਉਣ ਵਾਲੇ ਅੰਤਰਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਨਤੀਜੇ ਵਿੱਚ ਸਮੂਹਬੱਧ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਸਫਲਤਾ ਦੀ ਸ਼ਰਤ ਵਾਲੇ ਸੀਮਿਤ ਕਾਰਜ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਅਸੀਂ ਇਹ ਆਟੋਮੇਸ਼ਨ ਪ੍ਰੋਡਕਟ ਦੀ ਇੱਕ ਸੀਮਿਤ ਪਰਤ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਾਂ। ਇਹ ਪਰਤ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਦਾ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਸਰੋਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਟੈਕਸ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਮੈਪ ਕਰਦੀ ਹੈ। ਇੰਜੀਨੀਅਰ ਹਾਲੇ ਵੀ ਆਰਕੀਟੈਕਚਰ, ਪ੍ਰੋਡਕਟ ਦੇ ਫੈਸਲਿਆਂ ਅਤੇ ਸ਼ਿਪਿੰਗ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ। ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਕੀਤੇ ਜਾ ਰਹੇ ਆਪਣੇ ਕੰਮ ਰਾਹੀਂ ਇਸ ਸੁਧਾਰ ਲੂਪ ਨੂੰ ਸੇਧ ਦਿੰਦੇ ਹਨ: ਜਿਵੇਂ ਕਿ ਕੱਢੇ ਮੁੱਲਾਂ ਨੂੰ ਸੋਧਣਾ, ਰਿਟਰਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨਾ ਅਤੇ ਅੰਤਿਮ ਫਾਈਲਿੰਗਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ।
Codex ਲਈ, ਇਸਦਾ ਨਤੀਜਾ ਕੋਈ ਅਸਪਸ਼ਟ ਅਲਰਟ ਨਹੀਂ ਹੁੰਦਾ, ਬਲਕਿ ਸਬੂਤਾਂ, ਸੋਧਯੋਗ ਪ੍ਰੋਡਕਟ ਸਰਫੇਸਿਸ ਅਤੇ ਸਪਸ਼ਟ ਵੈਲੀਡੇਸ਼ਨ ਗੇਟਸ ਦੇ ਨਾਲ ਇੱਕ ਸੀਮਿਤ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀ ਕੰਮ ਲਈ ਸੰਦਰਭ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਅਨੁਸਾਰ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ:
ਇਹੀ ਲੂਪ ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀਜ਼ ਤੋਂ ਪਰੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਰੈਂਟਲ ਪ੍ਰਾਪਰਟੀਜ਼ ਦੇ ਮਾਮਲੇ ਵਿੱਚ 90% ਸ਼ੁੱਧਤਾ ਅਤੇ ਰੀਕਾਲ ਹਾਸਲ ਕਰਨ ਲਈ ਲਗਭਗ ਛੇ ਹਫ਼ਤਿਆਂ ਦਾ ਸਮਾਂ ਅਤੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਨਿਗਰਾਨੀ ਦੀ ਲੋੜ ਪਈ ਸੀ, ਪਰ ਉਸ ਕੰਮ ਨੇ ਅਜਿਹੇ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਮਾਡਲ, ਸਮੀਖਿਆ ਦਸਤਾਵੇਜ਼, ਈਵੈਲ ਨਿਯਮ ਅਤੇ ਲਾਗੂਕਰਨ ਦੇ ਤਰੀਕੇ ਤਿਆਰ ਕੀਤੇ, ਜਿਨ੍ਹਾਂ ਨੇ ਸ਼ੈਡਿਊਲ C ਅਤੇ ਸ਼ੈਡਿਊਲ A ਵਰਗੇ ਹੋਰਨਾਂ ਗੁੰਝਲਦਾਰ ਸ਼ੈਡਿਊਲਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਬਣਾ ਦਿੱਤਾ।
Tax AI ਨੇ ਖ਼ੁਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਵਾਲੇ ਏਜੰਟਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਦਾ ਸਹੀ ਰਸਤਾ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਹੈ। ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਟੈਕਸ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋਏ ਬਹੁਤ ਹੀ ਮਹੱਤਵਪੂਰਨ ਫੀਡਬੈਕ ਸੰਕੇਤ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਪ੍ਰੋਡਕਟ ਵਰਕਫਲੋ ਉਨ੍ਹਾਂ ਸੰਕੇਤਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਸਬੂਤ ਵਜੋਂ ਸੰਭਾਲ ਕੇ ਰੱਖਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ, ਮੁਲਾਂਕਣ-ਆਧਾਰਿਤ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਸੁਧਾਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਏਜੰਟ-ਸੰਚਾਲਿਤ ਲੂਪ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਲਗਾਤਾਰ ਖ਼ੁਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਦੇ ਨਿਰੰਤਰ ਪ੍ਰਵਾਹ ਵਿੱਚ ਬਣਾਈ ਰੱਖਦਾ ਹੈ।
Thrive Holdings ਦੀ ਬਣਤਰ ਸਾਨੂੰ ਖਾਸ ਉਦਯੋਗਾਂ ਵਿੱਚ ਇਸ ਕਿਸਮ ਦੇ ਮਾਹੌਲ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। Holdings ਮਾਲਕ ਅਤੇ Operator ਦੋਵੇਂ ਹੈ, ਇਸ ਲਈ ਸਾਡੀਆਂ ਸੰਯੁਕਤ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ Crete ਵਰਗੇ ਕਾਰੋਬਾਰਾਂ ਦੇ ਅੰਦਰੋਂ ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾ ਨਾਲ ਸਿੱਧਾ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਕਿਸੇ ਵੈਂਡਰ ਵਜੋਂ ਨਹੀਂ ਬਲਕਿ ਭਾਗੀਦਾਰਾਂ ਵਜੋਂ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਟੈਕਨੋਲੋਜੀ, ਪ੍ਰੋਡਕਟ ਅਤੇ ਸੇਵਾ ਸਭ ਇੱਕੋ ਛੱਤ ਹੇਠ ਉਪਲਬਧ ਹਨ, ਜੋ ਸਾਨੂੰ ਵਧੇਰੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਅਤੇ ਬੇਮਿਸਾਲ ਪ੍ਰੋਡਕਟ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਇੱਕ ਸੀਨੀਅਰ ਅਕਾਊਂਟੈਂਟ ਜਿਸ ਨੇ ਪਿਛਲੇ ਸਾਲ ਟੈਕਸ ਤਿਆਰ ਕਰਨ ਵਿੱਚ 180 ਘੰਟੇ ਲਗਾਏ ਸਨ, ਇਸ ਸਾਲ ਕੇਵਲ 15 ਘੰਟੇ ਲਗਾਏ। ਉਸਨੇ ਇਸ ਬਚੇ ਹੋਏ ਸਮੇਂ ਦਾ ਕੁਝ ਹਿੱਸਾ ਆਪਣੇ ਹਰੇਕ ਕਲਾਇੰਟ ਨੂੰ ਫ਼ੋਨ ਕਰਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀਆਂ ਰਿਟਰਨਾਂ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਸਮਝਾਉਣ ਲਈ ਲਗਾਇਆ, ਅਜਿਹੀ ਉੱਚ-ਪੱਧਰੀ ਨਿੱਜੀ ਸੇਵਾ ਜੋ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਸੰਭਵ ਨਹੀਂ ਸੀ। ਬਾਕੀ ਬਚਿਆ ਸਮਾਂ ਉਸਨੇ ਨਵੇਂ ਕਲਾਇੰਟਸ ਬਣਾਉਣ ਅਤੇ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਦਾ ਦਾਇਰਾ ਵਧਾਉਣ ਲਈ ਵਰਤਿਆ।
ਹੁਣ ਸਾਡੀਆਂ ਟੀਮਾਂ ਮਿਲ ਕੇ Tax AI ਦੇ ਇਸੇ ਤਿੰਨ-ਹਿੱਸਿਆਂ ਵਾਲੇ ਡਿਜ਼ਾਇਨ ਨੂੰ Thrive Holdings(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)ਦੇ ਹੋਰ ਖੇਤਰਾਂ ਦੇ ਵਰਕਫਲੋ ਬਣਾਉਣ ਲਈ ਬਲੂਪ੍ਰਿੰਟ ਵਜੋਂ ਵਰਤ ਰਹੀਆਂ ਹਨ; ਜਿਵੇਂ ਬੁੱਕਕੀਪਿੰਗ ਅਤੇ ਆਡਿਟ ਵਰਗੇ ਅਕਾਊਂਟਿੰਗ ਵਰਕਫਲੋ, ਅਤੇ IT ਹੈਲਪ ਡੈਸਕ ਆਟੋਮੇਸ਼ਨ ਵਰਗੇ ਆਪਰੇਸ਼ਨਲ ਵਰਕਫਲੋ। ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਅਤੇ ਉਦਯੋਗਾਂ ਵਿੱਚ, ਸਵੈ-ਸੁਧਾਰ ਕਰਨ ਵਾਲੇ ਏਜੰਟਾਂ ਦਾ ਵਿਆਪਕ ਵਾਅਦਾ ਕਾਇਮ ਰਹਿੰਦਾ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਏਜੰਟ ਲੋਕਾਂ ਦੀ ਦਿਸ਼ਾ ਨਾਲ ਸਿੱਖਦੇ ਹਨ ਤਾਂ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਹੋਰ ਸਮਰੱਥ, ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਅਤੇ ਹੋਰ ਕੀਮਤੀ ਬਣ ਸਕਣ।
ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ OpenAI ਟੀਮ ਬਾਰੇ ਹੋਰ ਜਾਣਨ ਲਈ, ਸੰਪਰਕ ਕਰੋ।
