RMP.Application:5.2 - Obtain records that preserve the needed distinction
The CRM contains one date labelled “status updated”. It may be the time an administrator changed a field after the quotation was sent. Before analyzing it as customer waiting, compare a small set of retained messages and approval records with their CRM entries. This checks what the recording operation means; it does not estimate the effect of another approver.
For one constructed request, the retained records show:
| Event | Recorded time | Working time since the preceding event |
|---|---|---|
| Customer request received | Monday 09:00 | — |
| Sufficient customer input received | Tuesday 10:00 | 9 hours |
| Calculation completed and submitted for approval | Tuesday 14:00 | 4 hours |
| Approval completed | Wednesday 16:00 | 10 hours |
| Quotation actually sent | Thursday 10:00 | 2 hours |
This office counts working time from 09:00 to 17:00 on weekdays. The total is 25 working hours, or 3.125 eight-hour working days. Approval accounts for ten hours in this case; input waiting accounts for nine. The delay between approval and sending also remains visible. An updated CRM status at Thursday 11:00 would measure a different event.
The registration trial should expose missing events, inconsistent clocks, retrospective guesses, duplicate requests and the effort required to keep the record. If the old messages do not survive, mark the missing history. Begin suitable prospective recording when worthwhile; do not invent past timestamps. If two durations of seven and eight hours are both stored as “one day”, repeating that rounded record need not recover their difference.
RMP.3 connects these choices to the question; RMP.4 preserves what actually happened and what can still be examined. Retain both the intended record and consequential departures from it. Stage durations are useful for understanding mechanisms, while the intervention’s total effect still concerns the whole time to sending.