PrerequisiteCompleted Module 1 (From Use Case to Project Charter)
0 / 2 completed
Learning objectives
Draw a current-state process map marking the queueing, processing, review, and rework stages.
Build a baseline log recording the current process’s real elapsed time and case volume.
Distinguish an estimate from an evidence-backed measured figure and label numbers accordingly.
Current Process and Baseline
30 min
Map the Current Process
Before proposing any AI solution, you have to see clearly how the work actually happens today. Most teams overestimate how well they understand their own process: the real workflow usually hides more queueing, cross-team review, and rework than people remember.
Demo Service Company A: current customer-support Q&A process
Customer submits a question (email/form)
Enters the support queue, waits to be assigned (queue)
Agent searches the internal knowledge base (process)
When unsure, escalates to a supervisor or senior agent for confirmation (review)
Drafts a reply
Some cases are sent back to redo because they cited a wrong or expired document (rework)
Reply sent to the customer and the case is logged as closed
Info
This process maps to the shared synthetic case SYN-CS-001 (Demo Service Company A’s customer-support knowledge assistant). IL 101-302 all reuse the same synthetic data set so you can trace the same case across courses. The full package can be downloaded from this module’s Resources section.
Queue: the task has arrived but no one has started on it yet
Process: the time actually spent executing the task
Review: time spent waiting for another person to confirm or approve
Rework: time spent redoing work because of an error or an incomplete result
1Step 1 Pick one concrete task from your own project (not an entire department: a process that fits on one page).
2Step 2 Interview the people who actually do it and map where the queue, process, review, and rework stages each occur.
3Step 3 Mark any step that relies on memory or a verbal confirmation rather than a recorded document; these are usually the risk points that IL 202’s data-readiness work will need to address.
Key takeaway: A process you never mapped cannot be measured for improvement; only once you see the hidden queueing, review, and rework can you tell which stage AI should actually help with.
30 min
Build a Baseline Log
A baseline log is the starting point for every value calculation in Module 3 and for IL 201’s evaluation design. Without a baseline, any claim that "AI improved efficiency by 30%" cannot be checked.
Minimum baseline-log columns (see SYN-CS-001’s baseline_log.csv for a working example)
Column
Description
log_id
Unique identifier
case_category
Case type (e.g. normal, missing context, conflicting sources, outdated source, no answer, restricted access)
search / verify / draft / rework minutes
Actual minutes spent on each stage
total_minutes
Total elapsed time
agent_code / log_date
Recorder code and date (no real names)
Synthetic example (excerpted from SYN-CS-001’s baseline_log.csv)
Common mistake: recording only the "process" time and ignoring queueing and review, which understates the baseline and makes it easy to overstate AI’s improvement later. Another common mistake: treating a handful of estimated numbers as "validated" without recording the sample size or observation period.
Check yourself
A support agent has to rewrite a reply because the knowledge-base document they cited had expired, and a supervisor sent it back. Which process stage does this rewrite time belong to?
Key takeaway: Log at least 10-15 real or high-fidelity observed samples, and clearly label the sample size and observation period, before using it as the basis for any later value calculation.
