Work out the net time saved on each task, using the figures in your logs.
Priya uses an AI assistant for supplier replies, a Monday report, meeting notes and a monthly regional update. 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. As Lesson 1.3 explained, memory changes with whatever happened most recently, so it can't tell you how much time you've saved.
You now have a baseline, which is the time each task took before you changed anything. You also have several weeks of logs measured after the change. The next step is to turn those logs into a weekly figure you can stand behind.
Lesson 1.2 gave you an early estimate: the old time minus the time spent on prompts, checks and fixes. That estimate left out one cost, which is waiting. Net time saved for a 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 includes a research mode that takes five minutes, a slow upload, or a transcript that takes ten minutes to process. You can leave waiting time out only if you genuinely worked on something else during it. If you sat and watched the progress bar, the waiting counts.
The exercises asked you to time each task from start to finish, so most of these costs should already be in your logs. Check that they are. If a log entry timed only the assistant's part, either adjust it to cover the whole task or leave it out.
A saving on one task matters only in proportion to how often that task happens. 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 and ignore your best run. A manager will plan around your figure, so it has to show the typical case. The average covers every run logged after you settled into the method. You can report early runs from the learning period separately as setup time. Slow runs after the learning period stay in the average.
Priya's supplier replies took 6 minutes each at baseline (an example figure). The new average is 4.5 minutes, and there are 40 replies a week, so the saving is 60 minutes a week. Priya's best run was 3 minutes per reply. Using that run would have suggested 120 minutes a week, twice the figure the average gives.
The Monday report took 120 minutes at baseline and now averages 45 minutes. It happens once a week, so it saves 75 minutes a week. Meeting notes took 25 minutes and now average 16 minutes. There is one meeting a week, so they save 9 minutes a week.
The monthly regional update went the other way. Its baseline was 60 minutes and its new average is 65 minutes. The assistant kept misreading the regional figures, so the output needed fixing every time. That is a loss of 5 minutes a month, a little over one minute a week.
The net weekly figure is the total of the savings minus the losses. For Priya that is 60 + 75 + 9 - about 1, which comes to roughly 143 minutes, or about two hours and twenty minutes a week.
Record one-off setup time separately from the weekly saving that repeats, then compare the two. Setup time includes the early learning-period runs. 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, Priya earned back the setup time within the first week.
Time is only part of the picture, so compare the quality notes in your baseline logs with those in your new logs. A quality gain counts even when the time saving is small. Quality gains 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. At baseline, though, the notes missed an action item in two of four meetings, and the checked summaries missed none in six. In the Monday report, Priya's check cell caught an error that the old method had been missing for weeks.
Every task you tested gets one of three labels: saving, no change or loss. A task with no saving or a loss is not a failure by you or by the course. It is a useful finding, and you should record it as carefully as a saving.
After a loss, you have three choices: stop, change the method, or drop AI for that task. If you drop it, write down why, so that you or a colleague don't try the same thing later and get the same result. Priya moved the regional update back to the old method and wrote down the reason. The figures came in a format the assistant always misread, and checking the output took longer than writing the update by hand. With that note on file, nobody will try it 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.
For each target task, take your baseline and your course logs and work out the net time saved. Mark each task as a saving, no change or a loss.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).