ROI Case File No.580 'Flowing Everything at the Same Weight, We Hadn't Decided the Order of Arrival'
![]()
Flowing everything at the same weight, we hadn't decided the order of arrival
- Chapter 1: The information doesn't arrive—but the mechanism can't keep up
- Chapter 2: What RFM asks—decide priority by recency, frequency, and importance
- Chapter 3: An implementation plan that decides priority across three axes
- Chapter 4: The day, the order of arrival decided, accidents decreased
- Related Files
- Tools Used
Chapter 1: The information doesn't arrive—but the mechanism can't keep up
"We want to bring in an internal bulletin-board platform. I want to share accident information with everyone quickly."
Tsutae Hayami, HR director at TechCom, described the situation. "Employees surged from last period, and now we're at 120. As we've grown, on-the-job accidents have increased. Traffic accidents, accidents while carrying loads. Right now we share information by phone, but management can't keep up. We need a mechanism to deliver accident information to everyone at once."
"Where does the current sharing get stuck?" Claude asked.
"We pass it around on personal LINE, and it's person-dependent," Hayami answered. "It doesn't reach people on leave. Going through the division head, transmission omissions happen. Videos and photos are scattered on personal PCs and can't be rolled out company-wide. I'm trying to flow everything the same way, but I can't keep up."
"Have you decided the order of arrival by the recency, frequency, and importance of the information?" I confirmed.
"…I haven't," Hayami answered. "I've been flowing everything at the same weight. Which one, with how much urgency, to whom to deliver reliably. I've never set priority."
"Flow everything at the same weight, and the order of arrival won't be decided," I replied. "Let's break it down with RFM."
Chapter 2: What RFM asks—decide priority by recency, frequency, and importance
"This case calls for RFM."
Claude wrote on the whiteboard: "Recency, Frequency, Importance."
"RFM—the three axes of recency, frequency, and importance—is a framework that measures information's priority by three yardsticks," I explained. "The crux is not flowing everything at the same weight. With something like accident information, the way you deliver it changes by how new (recency), how repeated (frequency), and how heavy (importance) it is. Because you decide priority across three axes, it becomes a mechanism that arrives reliably. It's a tool for deciding the order of arrival."
"First, let's measure the current cost," Gemini said, opening ROI Polygraph. He entered the data Hayami had provided.
"The monthly cost is out," Gemini read off. "Labor for phone-based information sharing averages 170 hours a month; at ¥3,600 an hour, that's ¥612,000 a month. Delayed accident response from transmission omissions and person-dependent management averages ¥400,000 a month. Duplicate contact from information not reaching people on leave averages ¥340,000 a month. The inability to roll out company-wide from scattered accident information averages ¥360,000 a month. Loss and response-cost risk from rising accidents averages ¥380,000 a month. The total is ¥2,092,000 a month—about ¥25.1 million a year."
Hayami stared at the figures. "I'd been watching only the labor of sharing. Once you add the cost of delayed accident response because the order of arrival isn't decided, it comes to this much."
"Then let's design it with RFM," I continued.
[Recency—deliver accident information the fastest]
"First, recency," Claude said. "Accident information loses its prevention effect if sharing is delayed. Recency is life. So build a path where, the moment it occurs, it arrives at the top priority. Don't flow everything at the same speed; order by newness."
[Frequency—repeat the sharing to keep awareness up]
"Next, frequency," Gemini continued. "Raise the frequency of sharing and keep the employees' safety awareness high at all times. Not once and done—deliver repeatedly. With frequency, maintain the awareness of accident prevention."
[Importance—make everyone receive it reliably]
"After frequency, importance," I continued. "Accident-prevention information is heavy for everyone. So make it a mechanism where everyone receives it reliably—even on leave, even through a different path. With importance, decide the certainty of arrival."
[Implementation—land the three axes on a board and notifications]
"Last, implementation," Claude continued. "Land the three axes on the bulletin-board platform. Central management everyone can access, urgent notification of key information, sharing of videos and photos. Recency, frequency, and importance become a mechanism that arrives reliably."
[Estimating the payback]
"Let's run the numbers with the ROI Proposal Generator," Gemini proposed.
- Initial cost: RFM analysis, bulletin-board platform build, urgent-notification feature, video/photo sharing, and operational design—¥5.1 million total
- Monthly cost: platform operation plus ongoing maintenance—¥220,000
- Monthly savings: centralization of information sharing = ¥480,000 (assuming a 70% reduction); accident prevention through urgent notification = ¥360,000; resolution of transmission omissions = ¥280,000; company-wide rollout through video/photo sharing = ¥280,000; ¥1,400,000 a month total
- Net monthly savings: ¥1,400,000 − ¥220,000 = ¥1,180,000 a month
- Payback period: ¥5.1 million ÷ ¥1,180,000 = about 4.3 months
"A little over four months to recover," Gemini summarized. "What works is not flowing everything at the same weight but deciding priority across three axes. Flow it uniformly and even urgent accident information gets buried and doesn't reach those on leave. Order by recency, frequency, and importance and it arrives reliably. The investment doesn't swing at empty air."
Hayami said as he checked the numbers. "I thought flowing everything would settle it. Unless you decide the order of arrival, the important information gets buried."
"RFM is a tool for deciding priority by recency, frequency, and importance," I replied.
Chapter 3: An implementation plan that decides priority across three axes
"Let me lay out the approach," I said, standing before the whiteboard.
"Month one—classify information across the three axes and set the priority of accident information. Month two—requirements definition for the bulletin-board platform and design of urgent notification. Months three and four—build the platform and prepare company-wide access. Month five—the video/photo sharing feature and a design for reaching those on leave. Month six—trial run and effect verification. Month seven onward—embed operations and continuously optimize through feedback."
"If we broadcast to everyone at once, it'll arrive—right?" Hayami confirmed.
"Broadcasting alone isn't enough," Claude replied. "Broadcast everything at once at the same weight, and urgent accident information and everyday contact mix together and get buried. It doesn't reach those on leave. Order by recency, frequency, and importance with RFM, and the heavy information goes top priority and arrives reliably to everyone. Deciding the order of arrival comes before broadcasting."
Hayami said as he took notes. "Before flowing everything, decide the order of arrival. I can see the order now."
Chapter 4: The day, the order of arrival decided, accidents decreased
Ten months later, a report arrived from Hayami.
Information sharing changed greatly after the platform was introduced. "The sharing that phone-based methods couldn't keep up with became central management. Accident information began to arrive to everyone at once," Hayami wrote.
Transmission omissions vanished too. Urgent notification erased the drop-offs for those on leave and on different paths. "It reached people on leave directly, without going through the head. The person-dependent way of passing it around was gone," the report said.
The biggest change showed in how information was flowed. From flowing everything at the same weight, they shifted to deciding priority across three axes. "I'd thought just broadcasting was fine. Once I ordered by recency, frequency, and importance, the heavy information no longer got buried and arrived reliably," Hayami wrote.
Videos and photos came alive too. The sharing feature spread visual information company-wide. "Videos and photos that had been scattered on personal PCs could be shared company-wide. They helped with accident prevention," the report said.
As a side effect, the way information was viewed changed. Rather than uniform, the habit of flowing by priority took root. "I stopped flowing everything the same way. I began to think in terms of which one, with how much urgency, to whom reliably," Hayami wrote.
At the end of Hayami's report was written: "I thought the information-sharing trouble was the delivery mechanism. But the real problem was that, flowing everything at the same weight, I hadn't decided the order of arrival. The moment I set the three-axis priority with RFM, the form that arrives reliably came into view. Before flowing everything, deciding the order of arrival came first."
On the day a company that had flowed everything at the same weight and hadn't decided the order of arrival became a company that could decide priority across three axes, information sharing had changed from a uniform broadcast into a design that decides priority by recency, frequency, and importance.
"A consultation about information sharing usually arrives in the form of 'we want to deliver to everyone.' But before flowing it all at once, there's something to ask. Is the order of arrival decided? What RFM asks is the three axes of recency, frequency, and importance. Order by the three axes and the heavy information arrives reliably without getting buried. On the day a company that had flowed everything at the same weight could decide the order of arrival, what changed was not the speed of delivery but the very perspective of deciding priority by recency, frequency, and importance."
Related Files
Tools Used
- ROI Polygraph — visualizing phone-sharing labor, delayed response from transmission omissions, and information scatter
- ROI Proposal Generator — a payback simulation for the information-sharing platform, starting from a three-axis design of recency, frequency, and importance