ROI Case File No.407: The Map Tracing Customer Journeys
The Map Tracing Customer Journeys
Chapter 1: A Sea of Scattered Information
"We've lost sight of customer information."
The sales director of HorizonTech confessed this. On his desk lay scattered customer ledgers covered with sticky notes, handwritten memos, printed emails, and old Excel files.
"Do you know how much time our sales staff spend searching for customer information? Systems, emails, paper documents—information is dispersed across three locations, and you can't see the whole picture without checking each one."
Exhaustion permeated his voice.
"What's even more serious is task management. Instructions from supervisors are scattered across verbal communication and emails. Who's doing what, what's the progress—from a management perspective, we have absolutely no grasp of it."
The sales director produced materials listing demands from management.
"As business reviews progress, unified customer management has become urgent. We're also required to visualize development and evaluation of young employees. Improving interdepartmental communication is another challenge."
"We've been instructed to release a system by the end of January 2026. However—"
He paused. "What should be unified and how. What we should demand from the system. That's not clearly visible."
The deadline was approaching, but requirements remained undefined. That was HorizonTech's current state.
Chapter 2: Seeing the Journey's Beginning
"For this case, the JOURNEY Model approach is optimal."
Claude drew a horizontal line on the whiteboard, extending from left to right.
"The JOURNEY Model—the Customer Journey Map," I began explaining, "is a method that visualizes the series of experiences from when customers or users encounter a service, use it, and eventually leave, in chronological order."
"However, this time the 'customers' aren't only external clients," Gemini supplemented. "HorizonTech's sales staff themselves are 'users' of this system. We'll capture their workflow as a journey and clarify where problems exist."
The sales director tilted his head. "View sales staff's work as a journey?"
"Yes," I answered. "For example, consider the moment a deal with a new customer is closed. After that, what kind of 'journey' does the sales staff member take?"
[Step 1: Visualize the Current Journey]
"First, break down the current workflow step by step," Claude proposed.
The sales director answered while thinking. "When I obtain new customer information, I first check the existing customer ledger for duplicates. Next, I input business card information into Excel and note the initial contact schedule on my calendar."
"Then I send a meeting request by email and wait for a reply. Once the meeting is set, I search emails and the system for similar past cases to prepare proposal materials."
"After the meeting, I record the content in my sales daily report and verbally report to my supervisor. Once the next action is decided, I enter the schedule in my calendar again..."
As he explained, he showed a surprised expression. "When I organize it like this, I'm inputting the same information multiple times in different places."
"Exactly right," I nodded. "The first step of the JOURNEY Model is visualizing the current state chronologically. Doing so reveals certain things."
Gemini diagrammed the workflow the sales director had explained on the whiteboard. From obtaining customer information to closing cases, twelve steps were lined up.
"Among these twelve steps," Gemini pointed out, "the act of 'searching for information' appears five times. Customer ledgers, emails, systems, paper documents—searching different locations each time."
"And," Claude added, "the act of 'inputting the same information' also appears four times. Input into Excel, input into calendar, input into daily reports, input into emails."
The sales director's expression clouded. "It's full of waste."
[Step 2: Draw the Ideal Journey]
"Now, let's consider the ideal journey," I prompted.
"If information were unified, how would this process change?"
The sales director closed his eyes and imagined. "If I obtain new customer information, just inputting it once into the system would automatically register it in the customer ledger, set calendar schedules, and add it to task lists."
"Similar past cases would also be listed in the system by searching customer names or industries. Recording meeting content in the same system would let supervisors grasp progress in real-time."
"When the next action is decided and registered as a task, related parties would be automatically notified—"
He opened his eyes. "Time spent searching for information and redundantly inputting it could be drastically reduced."
"That's the ideal journey," Claude smiled. "The current twelve steps could probably be compressed to about seven."
Gemini organized. "The JOURNEY Model's second step is drawing 'what should be.' The gap from the current state becomes system requirements."
[Step 3: Identify Touchpoints]
"Next, we identify 'touchpoints' with customers," I explained.
"When do sales staff interact with customers?"
The sales director answered. "Initial contact, meetings, proposals, quotation presentation, contract signing, delivery, after-sales follow-up—mainly these seven."
"What should sales staff record at each touchpoint?" Claude asked.
"At initial contact, customer challenges and requests. At meetings, detailed needs and budget sense. At proposals, proposal content and customer reactions—"
As the sales director continued explaining, he noticed something. "This information is currently recorded separately, making it difficult to review later."
"There it is," I pointed out. "The JOURNEY Model's third step is defining information to be recorded at each customer touchpoint."
"And," Gemini supplemented, "we design so that information can be referenced at the next touchpoint. For example, a mechanism where challenges heard at initial contact can be automatically quoted when creating proposals."
[Step 4: Capture Emotional Fluctuations]
"The JOURNEY Model has one more important element," Claude said. "That's 'emotion.'"
The sales director looked puzzled. "Emotion?"
"Yes. In the current workflow, when do sales staff feel the most stress?"
The sales director answered immediately. "When searching for information. Before customer meetings, trying to recall past exchanges, going back through dozens of emails. Logging into the system, pulling out paper documents—still can't find it, end up asking colleagues."
"What emotions arise in that moment?"
"Frustration and helplessness. 'Why must I waste time on such pointless things?'"
"That's crucial information," I emphasized. "In system design, preferentially improving 'high-stress touchpoints' greatly increases user satisfaction."
Gemini added to the diagram. "We overlay a graph showing 'emotional fluctuations' on each step of this JOURNEY map. High-stress parts become valleys, smooth parts become peaks."
"And," Claude continued, "we preferentially improve parts where valleys are deep."
Chapter 3: From Map to Design
The sales director gazed at the JOURNEY map drawn on the whiteboard.
"This map becomes the system requirements specification."
"Exactly," I answered. "Compare the current journey with the ideal journey, identify functions to fill that gap. Define information to be recorded at each touchpoint, design database structure. Identify high-stress parts, determine UI priorities."
"However," Gemini cautioned, "no need to implement all functions initially. Rather, focus only on the highest-stress parts."
The sales director asked, "Which part would that be?"
"The act of 'searching for information,'" I answered immediately. "Make it possible with one search instead of the current five occurrences. This alone would greatly improve work efficiency."
Claude proposed, "First, build basic functionality to centrally manage customer information and past interaction history. Calendar integration and task management come in the next step."
"And what's important," I added, "is limiting trial introduction to the first five sales staff members and having them use it in actual work. Observe and record how their 'journey' changes."
"Based on that learning, add functions and expand to other sales staff," Gemini organized.
The sales director's expression brightened. "The January 2026 release deadline is quite achievable if focused on basic functions."
Chapter 4: The Journey Continues
"Finally, there's one thing I'd like to convey," I said.
"JOURNEY maps aren't finished once created. Even after introducing the system, please update them regularly."
"Why is that?" the sales director asked.
"Because how we engage with customers changes," Claude answered. "When new services are added, new touchpoints are born. When sales methods change, workflows also change."
"By continuously updating the JOURNEY map," Gemini continued, "the system also evolves to always stay close to the field."
The sales director nodded deeply. "Understood. First, I'll interview all sales staff to record the current journey."
After he left, Claude said quietly, "The JOURNEY Model is a method that stays close to people's experiences."
"Yes," I answered. "Much system design begins from 'what can be done'—functionality. However, the JOURNEY Model begins from 'how users feel'—experience."
"And," Gemini added, "by visualizing that experience chronologically, truly necessary functions become visible."
Outside the window, winter sunlight illuminated the office.
Two months later, a report arrived from HorizonTech.
Trial introduction results from five sales staff showed time spent searching for customer information reduced by an average of 65%. Based on their feedback, detailed specifications for task management functionality had solidified, and preparations for company-wide deployment were complete.
The map drawing the journey was definitely changing the field.
"To design systems, first draw users' journeys. Visualize current experience, imagine the ideal state, fill that gap. And improve small, starting from the highest-stress parts. The JOURNEY Model teaches the path of design that stays close to people's experiences."
