ROI Case File No.350 | 'NexusTech's Cost of Ambiguity'

Chapter 1: The 30 Million Confusion—Double Difference for Same System

The day after resolving TechSavvy's educational AI implementation case, a consultation arrived regarding system development outsourcing. Volume 28 "The Pursuit of Reproducibility," Story 350 and the final story, is a tale of clarifying requirements.

"Detective, we want to outsource customer management system development. However, when we got quotes from three companies, they were 15 million yen, 28 million yen, and 45 million yen—completely scattered. We don't understand why such differences exist. Cannot judge which vendor to choose."

NexusTech's Information Systems Manager, Yuichi Tanaka from Shibuya, visited 221B Baker Street with a confused expression. In his hands were quotes from three companies and, in stark contrast, materials marked "Budget ceiling: 25 million yen."

"We provide marketing support services for B2B. Annual revenue 2.5 billion yen, 120 employees. However, our customer management system is old, centered on Excel management. Sales efficiency is poor, so we decided on system renewal."

NexusTech's Current Situation: - Established: 2010 (B2B marketing support) - Annual revenue: 2.5 billion yen - Employees: 120 (Sales 30, Consultants 50, Administration 40) - Customers: Approximately 800 companies - Problem: Customer management Excel-centered, sales don't share customer information, deal progress invisible

Tanaka's voice carried deep anxiety.

"Currently, each sales representative manages customers individually in Excel. No information sharing, frequent duplications where 'another sales rep had already approached this customer.' And deal progress is invisible.

We decided on system renewal and consulted three system development companies. However, the quotes are scattered."

Three Company Quotes:

Company A: 15 million yen - Development period: 4 months - Functions: Customer management, deal management, basic reports - Note: "Customize based on cloud CRM"

Company B: 28 million yen - Development period: 7 months - Functions: Customer management, deal management, sales activity recording, reports, mobile support - Note: "Scratch development, fully aligned with your business flow"

Company C: 45 million yen - Development period: 10 months - Functions: Customer management, deal management, sales activity recording, reports, mobile support, AI prediction, external system integration - Note: "Advanced system utilizing latest technology"

Tanaka sighed deeply.

"Company A is cheap but feels functionally insufficient. Company C is feature-rich but far exceeds our 25 million yen budget. Company B is middle ground, but cannot judge if this content is really appropriate.

Fundamentally, we haven't clarified 'what we need.' Sales department requests 'want to share customer information.' Consulting department requests 'want to visualize deal progress.' Administration requests 'want to automate sales forecasting.' Meeting all these exceeds budget."

Chapter 2: The Ambiguity of Requirements—What's Necessary and What's Not

"Mr. Tanaka, what information did you provide to each vendor?"

My question made Tanaka show an apologetic expression.

"Honestly, only provided vague information. Just 'want to create customer management system,' 'budget about 25 million yen,' 'as soon as possible.' Didn't communicate specific functional requirements."

Current State (Requirements Unclear Type): - Information provided to vendors: Vague - Functional requirements: Undefined - Result: Scattered quotes

I explained the importance of clarifying requirements and accurately communicating them to vendors.

"The problem is 'what's necessary' isn't clear. RFP—Request For Proposal. System development purpose, current challenges, needed functions, budget, schedule. Document these clearly and present to vendors. This method obtains appropriate quotes and enables optimal vendor selection."

⬜️ ChatGPT | Catalyst of Conception

"Don't throw to vendors ambiguously. Clarify requirements. Define everything with RFP"

🟧 Claude | Alchemist of Narrative

"Systems always value 'why build' more than 'what to build.' Clarify purpose"

🟦 Gemini | Compass of Reason

"RFP is requirements definition technology. Document purpose, current state, functions, budget, schedule"

The three members began analysis. Gemini deployed "RFP Framework" on the whiteboard.

RFP Components: 1. Project Overview: Purpose and Background 2. Current Challenges: What are the problems 3. Functional Requirements: Must-have and nice-to-have functions 4. Non-functional Requirements: Performance, security, operations 5. Budget and Schedule: Constraints 6. Evaluation Criteria: Vendor selection indicators

"Mr. Tanaka, let's create an RFP with these six elements."

Chapter 3: Clarification Through Definition—Documenting Requirements with Six Elements

Phase 1: RFP Creation (3 weeks)

1. Project Overview

Purpose: - Improve sales efficiency - Centralize customer information management - Visualize deal progress - Improve sales forecasting accuracy

Background: - Currently Excel-centered management with insufficient information sharing - Customer information duplicated among sales representatives - Deal progress invisible, management cannot grasp situation - Sales forecasting depends on sales representatives' intuition

Expected Effects: - Sales activity duplication reduction: Annual 200 hours reduction - Deal progress visualization improving conversion rate: 5% improvement - Sales forecast accuracy improvement: Error rate 30% → 15%

2. Current Challenges

Challenge 1: Customer Information Scattered - 30 sales representatives manage individually in Excel - 800 company customer information not centralized - Information lost when sales representatives leave

Challenge 2: Deal Progress Opaque - Cannot tell which stage deals are in - Win probability depends on sales representatives' subjectivity - Management cannot grasp overall picture

Challenge 3: Sales Activity Duplication - Multiple sales approach same customer - Approximately 50 annual duplications - Leads to customer complaints

Challenge 4: Sales Forecast Inaccuracy - Depends on sales representatives' intuition - Error rate: Average 30% - Low management decision accuracy

3. Functional Requirements

Must Have: 1. Customer Management - Customer information registration/editing/deletion - Assign representative per customer - Customer search/filtering 2. Deal Management - Deal registration/progress management - Stage management (prospect→proposal→negotiation→won/lost) - Win probability setting 3. Sales Activity Recording - Visit records, call records, email records - Activity history chronological display 4. Basic Reports - Sales activity summary - Deal progress report - Monthly sales report 5. Permission Management - User permission settings (sales, management, administrator) - Data access control

Nice to Have: 1. Mobile Support - Smartphone/tablet usage 2. Sales Forecast Function - Sales forecasting based on past data 3. External System Integration - Email integration (Gmail, Outlook) - Calendar integration

Not Needed: - AI prediction function (consider in future) - Advanced analytics (handle with BI tools)

4. Non-functional Requirements

Performance: - Concurrent access: Maximum 50 people - Response time: Within 3 seconds - Data capacity: 800 customers × 10 years data

Security: - SSL/TLS communication - User authentication (password + two-factor authentication) - Data backup (daily)

Operations: - Cloud-based (no on-premise) - Monthly operation cost: Within 100,000 yen - Maintenance support: Weekdays 9:00-18:00

Usability: - Intuitive UI - Training period: Within 2 days - Manual provision

5. Budget and Schedule

Budget: - Development cost ceiling: 25 million yen - Monthly operation cost ceiling: 100,000 yen

Schedule: - Requirements definition: 1 month - Design/development: 5 months - Testing: 1 month - Production launch: Month 7 - Total: Within 7 months

6. Evaluation Criteria

Proposal Content (40 points): - Functional requirements satisfaction (20 points) - Non-functional requirements satisfaction (10 points) - Proposal specificity (10 points)

Track Record (20 points): - Similar scale system development track record (10 points) - Post-implementation support structure (10 points)

Cost (20 points): - Development cost validity (10 points) - Operation cost validity (10 points)

Schedule (20 points): - Delivery date validity (10 points) - Development structure reliability (10 points)

Total: 100 points

Phase 2: RFP Distribution and Proposal Solicitation (3 weeks)

Distributed RFP to 5 vendors. Requested proposal submissions.

Submitted Proposals: - Company A: Re-proposal 22 million yen - Company B: Re-proposal 24 million yen - Company C: Declined (budget mismatch) - Company D: New 21 million yen - Company E: New 26 million yen

Chapter 4: Selection Through Judgment—Discerning Optimal Vendor with Evaluation Criteria

Phase 3: Proposal Evaluation (2 weeks)

Scored each company based on evaluation criteria.

Company A (Cloud CRM-based): - Proposal content: 32 points (meets must-haves but lacks nice-to-haves) - Track record: 15 points (abundant CRM implementation track record) - Cost: 18 points (22 million yen, operation 80,000 yen) - Schedule: 16 points (completes in 6 months) - Total: 81 points

Company B (Scratch development): - Proposal content: 38 points (meets all functions, optimized for business flow) - Track record: 18 points (similar scale system development track record exists) - Cost: 16 points (24 million yen, operation 90,000 yen) - Schedule: 18 points (completes in 7 months, robust structure) - Total: 90 points

Company D (Package customization): - Proposal content: 30 points (meets must-haves but limited customization scope) - Track record: 12 points (limited track record) - Cost: 20 points (21 million yen, operation 70,000 yen, lowest price) - Schedule: 14 points (completes in 5 months but structure unclear) - Total: 76 points

Company E (High-functionality type): - Proposal content: 40 points (meets all functions, additional proposals substantial) - Track record: 20 points (many implementations for major companies) - Cost: 10 points (26 million yen, over budget, operation 120,000 yen) - Schedule: 16 points (completes in 8 months) - Total: 86 points

Selection Result: Selected Company B

Phase 4: System Development and Release (7 months)

Month 1: Requirements Definition - Established detailed functional specifications with Company B - Screen design, database design

Month 2-6: Design/Development - Developed customer management, deal management, sales activity recording functions - Mobile support (smartphone/tablet) - Sales forecast function (past data analysis)

Month 7: Testing - Pilot operation with 10 sales department members - Bug fixes, UI improvements

Month 8: Production Launch - Deployed to all 30 sales representatives - Training: 2 days

Phase 5: Results 6 Months After Launch

Result 1: Sales Activity Duplication Reduction - Before: 50 annual duplications - After: 5 annual duplications - Reduction: 90% - Time reduction: 50 cases × 4 hours/case = 200 hours/year - Reduction amount: 200 hours × 4,000 yen = 800,000 yen/year

Result 2: Deal Progress Visualization Improving Conversion Rate - Before: Conversion rate 28% - After: Conversion rate 32% - Improvement: +4 points - Annual negotiations: 1,200 cases - Additional wins: 1,200 cases × 4% = 48 cases - Average deal size: 5 million yen - Sales increase: 48 cases × 5 million yen = 240 million yen/year

Result 3: Sales Forecast Accuracy Improvement - Before: Error rate 30% - After: Error rate 16% - Improvement: 14 points - Effect: Improved management decision accuracy, reduced inventory excess/shortage

Result 4: Sales Activity Efficiency - Customer information search time: Before 10 min/search → After 1 min/search - Sales report creation time: Before 30 min/report → After 5 min/report - Annual time reduction: Approximately 600 hours - Reduction amount: 600 hours × 4,000 yen = 2.4 million yen/year

ROI Calculation:

Investment: - Development cost: 24 million yen - Monthly operation cost: 90,000 yen × 12 months = 1.08 million yen (first year) - Total: 25.08 million yen

Effects (Annual): - Sales activity duplication reduction: 800,000 yen - Sales activity efficiency: 2.4 million yen - Total (quantitative effects): 3.2 million yen - Sales increase: 240 million yen (but considering gross margin, actual effect approximately 24 million yen)

ROI (conservatively calculating quantitative effects only): - (3.2 million yen - 25.08 million yen) / 25.08 million yen × 100 = -87.2%

However, considering sales increase: - Gross margin: 10%, 240 million yen × 10% = 24 million yen - Total effect: 3.2 million yen + 24 million yen = 27.2 million yen - ROI: (27.2 million yen - 25.08 million yen) / 25.08 million yen × 100 = 8.5%

Year 2 Onward: - Investment: 1.08 million yen/year (operation cost only) - Effect: 27.2 million yen/year - ROI: (27.2 million yen - 1.08 million yen) / 1.08 million yen × 100 = 2,419%

Organizational Changes:

Sales Representative A's Voice: "Previously, confirming 'who is approaching this customer' took time. But now it's clear at a glance in the system. Duplications disappeared, customer trust increased. And can check information from smartphones even when out."

Manager B's Voice: "Deal progress became visible in real-time. Can accurately grasp 'what are this month's expected wins.' Sales forecast accuracy improved, making management decisions easier."

Tanaka's Reflection:

"Initially, we only had vague desire 'just want to create a system.' However, creating RFP clarified 'what's necessary and what's not.'

Must-have functions, nice-to-have functions, unnecessary functions. Classifying into these three enabled developing optimal system within budget. And setting evaluation criteria enabled selecting optimal vendor from five companies.

Conversion rate improved 4 points, achieving annual 240 million yen sales increase. Year 2 onward ROI is 2,419%. Without RFP, this result wouldn't have been achieved."

Chapter 5: Detective's Diagnosis—Ambiguity Creates Failure, Clarity Creates Success

That evening, I contemplated the essence of RFP.

NexusTech only had vague desire "want to create customer management system." Result: vendor quotes scattered from 15 million to 45 million yen.

Clearly documenting purpose, current challenges, functional requirements, non-functional requirements, budget, schedule, and evaluation criteria in RFP obtained appropriate proposals. Selected optimal vendor, achieved 4-point conversion rate improvement, annual 240 million yen sales increase.

"Don't throw to vendors ambiguously. Clarify requirements. Document purpose, challenges, functions, budget, schedule with RFP. The path to successful system development exists there."

This concludes all 10 stories of Volume 28 "The Pursuit of Reproducibility." Applying frameworks, analyzing challenges, verifying effects, proving reproducibility. This detective agency's story will continue.

"RFP = Request For Proposal. Document purpose, challenges, functions, budget, schedule, evaluation criteria. Clear requirements become the starting point for successful system development"—From the Detective's Notes

[Volume 28 "The Pursuit of Reproducibility" Complete]

This volume depicted methods to multi-dimensionally analyze business challenges, verify effects, and prove reproducibility through 10 frameworks.

• 5F: Discover competitive advantage through industry structure analysis
• PPM: Optimize product portfolio
• RFM: Precision customer segmentation
• VRIO: Identify sources of competitive advantage
• 3C: Overview customer, competitor, company
• VALUE CHAIN: Discover value loss points
• MANDALA: Multi-dimensionally break down challenges
• BSC: Build strategy from four perspectives
• ROI: Quantify return on investment
• RFP: Clarify requirements

In the next volume, we will continue solving business mysteries with new frameworks.

Related Files