You will be able to work out net time saved per task from your logs, not from impressions.
In week two, Priya would have told you AI was saving "loads". Supplier replies felt instant and the Monday report seemed to run itself. In week four, after an afternoon spent fixing a regional update the assistant had muddled, the answer might have been "honestly, not sure". Both answers came from memory, and memory shifts with whatever happened most recently. Lesson 1.3 explained why memory is the wrong instrument for judging time saved. You now have better material: a baseline, measured before you changed anything, and several weeks of logs measured after.
Lesson 1.2 gave you an early estimate: the old time minus the time spent on prompts, checks and fixes. You can now refine that with measured times and add one cost the estimate left out, which is waiting. Net time saved per task is the baseline time minus the full new time. The full new time has four parts: prompting, waiting for the output, checking and fixing.
Waiting counts as a cost. A research mode might take five minutes, an upload might be slow, or a transcript might take ten minutes to process. If you genuinely worked on something else during that time, you can leave the waiting out. If you sat and watched the progress bar, count it.
The exercises asked you to time each task from start to finish, so your logs should already include most of these costs. Confirm that they do. If any entry timed only the assistant's part, either adjust it to cover the whole task or exclude it.
A saving on one task matters only in proportion to how often the task comes up. The weekly saving is the net saving per occurrence multiplied by the number of times the task happens in a typical week. For a monthly task, divide by four to get a weekly figure.
Use the average run for each task. A manager will plan around the figure you give, so it has to reflect the typical case. Your average should cover all the runs you logged after you settled into the method. Early runs where you were still learning a lot can be reported separately as setup time. Slow runs that happened after the learning period stay in the average.
Priya's figures, which are example numbers, worked out as follows:
Supplier replies took 6 minutes each at baseline and now average 4.5 minutes. Priya writes 40 a week, so the saving is 60 minutes a week. The best run was 3 minutes per reply, which would have suggested 120 minutes a week, twice what the average gives. The Monday report took 120 minutes at baseline and now averages 45 minutes. It happens once a week, saving 75 minutes a week. Meeting notes took 25 minutes at baseline and now average 16 minutes. With one meeting a week, the saving is 9 minutes a week. The monthly regional update took 60 minutes at baseline and now averages 65 minutes, because the assistant kept misreading the regional figures and the output needed fixing every time. That is a loss of 5 minutes a month, a little over one minute a week.
To get the net weekly figure, add the savings and subtract the losses: 60 + 75 + 9 - about 1 = roughly 143 minutes, or about two hours and twenty minutes a week.
Record one-off setup time separately from the recurring weekly saving, then compare the two. Priya spent 90 minutes rebuilding the report and 30 minutes writing and testing the email prompt, 120 minutes in all. With a weekly saving of about 143 minutes, that time was recovered within the first week.
Time alone misses part of the picture, so compare the quality notes in your baseline logs with those in your new logs. Quality gains count even when the time saving is small. They include fewer rounds of edits from your manager, fewer errors caught later, and errors caught earlier because you added a check. Priya's meeting notes saved only 9 minutes a week, but at baseline the notes missed an action item in two of four meetings, and the checked summaries missed none in six. In the Monday report, the check cell caught an error the old method had been missing for weeks.
Every task you tested gets one of three labels: saving, no change or loss. If a task shows no saving or a loss, neither you nor the course has failed. It is a useful finding, and you should record it as carefully as you record a saving. A loss means you either stop, change the method, or drop AI for that task.
Priya moved the regional update back to the old method and wrote down why: the figures came in a format the assistant consistently misread, and checking the output took longer than writing the update by hand. Without that note, Priya or a colleague might try the same thing again in six months and get the same result.
Now work through your own logs. For each task, take the baseline time and check that the new times run from start to finish, covering prompting, waiting, checking and fixing. Average every run since you settled into the method and subtract that average from the baseline. Multiply by how often the task happens in a typical week, then add up the tasks and subtract the losses. Record setup time separately and compare your quality notes. Finally, mark every task you tested with one of three labels: saving, no change or loss.
Calculate net time saved for each target task from your baseline and course logs, and mark each as a saving, no change or a loss.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).