Phase 2: Attributes Structure
Why Companies That Skip This Phase End Up Rebuilding Everything Twice
Most companies jump straight to “connecting systems” without defining what data should actually flow. Six months later, they discover customer IDs don’t match, deals are orphaned, and teams still hunt for data. The integration worked. The architecture didn’t.
We've Seen This Movie Before. It Always Ends the Same Way.
You mapped your systems in Phase 1. You saw where data breaks. Now comes the harder question: what data should actually flow between those systems?
Most companies skip this. They hire an integrator, connect HubSpot to NetSuite, and celebrate when data starts syncing. Then reality hits:
Month 1
Company hires integrator to "connect HubSpot to NetSuite." Everything feels possible.
Month 3
Integration is live. Data is syncing. Teams celebrate. The tools are connected.
Month 6
Teams realize customer records don't match. Same company exists 3 times with 3 different IDs. Deals close in CRM but Operations never sees them. Finance invoices the wrong account because the ID structure is broken.
Month 9
Company realizes they need to rebuild the integration with proper ID structure, system ownership, and attribute mapping. But now they have 9 months of dirty data.
Month 12
Back to square one. $150K wasted. Team trust destroyed. Everyone asks: "Why didn't we define the architecture first?"
The integration worked. The architecture didn’t. And now fixing it costs 10x more than defining it correctly would have.
Phase 2 defines the architecture—before you touch any code. You can’t centralize data (Phase 3) or build workflows (Phase 4) on a broken foundation. This phase answers the questions that prevent the $150K rebuild.
This Phase Answers 5 Questions Your Integrator Won't Ask
Your integrator will map what you tell them to map. If you don’t define the architecture, they’ll guess. And when they guess wrong, you pay to rebuild it.
1
Which System Owns What?
CRM owns leads and deals. ERP owns orders and inventory. Finance owns invoices and payments. Support owns tickets and customer health.
Why this matters: If two systems think they own customer data, you’ll have conflicts forever. Deals close but never become orders. Invoices bill the wrong company.
2
What Attributes Do We Need?
Company name, deal value, order status, invoice number. Custom fields specific to your business. Cross-system relationships—which fields connect systems.
Why this matters: You can’t sync data you haven’t defined. Missing attributes mean broken workflows. Teams hunt for data that exists somewhere but nobody knows where.
3
How Do They Relate?
Company → Contact → Deal → Order → Invoice → Payment. Parent-child structures that connect across systems. Hierarchies that span platforms.
Why this matters: If you don’t map relationships correctly, data orphans. Deals exist without companies. Orders without customers. Invoices that can’t find their source.
4
What's the Master ID?
The universal identifier that connects all systems. Customer ID that spans CRM + ERP + Finance + Support. Deal ID that tracks from quote to cash.
Why this matters: Without a master ID, you can’t connect the same customer across 5 systems. You’ll have duplicates forever. Same company exists 3 times with 3 different IDs.
5
Where Does Data Leak?
Handoffs that fail (Sales → Ops → Finance). Missing fields that break the chain. Orphaned records that never sync. Revenue that falls through cracks.
Why this matters: If you don’t identify leaks now, you’ll build workflows around broken handoffs. Automation that works 80% of the time isn’t automation—it’s a time bomb.
You Can't Skip Steps. Each Phase Builds on the Last.
The Let Data Flow Framework has a sequence for a reason. Skip a phase, and everything built on top of it breaks.
The Sequence That Prevents the Rebuild
Phase 1
SAE Map
Shows you the WHOLE SYSTEM → Every platform, every handoff, every gap
Phase 2
Attributes Structure
Defines the ARCHITECTURE → What data flows, who owns it, how it connects
Phase 3
CDHS
Builds the FOUNDATION → The central truth layer everything pulls from
Phase 4
QDFs
Executes the WORKFLOWS → Real-time automation that never stops
You can’t define attributes without seeing the whole system first.
You can’t centralize data without knowing what attributes you need.
You can’t build reliable workflows without a central truth to pull from.
We Evaluate Your Tech Stack—And Find What's Missing
Here’s the part most companies miss: Your current systems might not be able to execute the architecture you need.
Phase 2 isn’t just mapping what you have. It’s identifying what you need—and whether your current platforms can deliver it.
The Tech Stack Assessment
Once we define the data architecture (system ownership, attributes, master IDs, relationships), we ask the next critical question:
“Can your current systems actually support this architecture? Or do you need different modules—or different platforms?”
We don’t force you to switch systems. QDF and CDHS are agnostic. But we do tell you the truth about what your tech stack can and can’t do.
Three Scenarios We See
✓
Scenario 1: Your Systems Can Handle It
Your current CRM, ERP, Finance platform, and support tools already have the modules, fields, and API capabilities to support the architecture.
What we do: Move forward with your existing stack. Implement CDHS and QDFs using what you already have. No platform changes needed.
⚠
Scenario 2: You Need Additional Modules
Your platforms are solid, but you’re missing key modules—like inventory management in your ERP, or customer success tracking in your CRM.
What we do: Identify which modules you need. Present 2-3 options (from your existing vendor or third-party add-ons). Evaluate based on budget, integration complexity, and timeline. You decide what to add.
✕
Scenario 3: Your Systems Can't Support the Architecture
Your current platform lacks the API depth, custom field flexibility, or relationship structure required. The data model you need doesn’t fit what your tools can do.
What we do: Present alternative platforms that can support the architecture. Show 2-4 options with different price points. Compare migration cost vs. staying on a broken foundation. You decide whether to migrate or adjust the architecture to fit your constraints.
We're Not Platform Salespeople
We don’t get kickbacks from vendors. We don’t force platform changes. QDF and CDHS work with almost any tech stack—HubSpot, Salesforce, NetSuite, Zoho, Monday.com, Airtable, you name it.
But we do tell you the truth: if your CRM can’t handle the master ID structure you need, or your ERP lacks the custom fields to support the attribute dictionary, you’ll know before you waste 6 months building on quicksand.
Phase 2 defines the architecture AND evaluates whether your tech stack can execute it. If not, we identify alternatives—with options at different budget levels—so you can make an informed decision.
We Don't Just Tell You What's Wrong. We Define What Right Looks Like.
Phase 2 delivers five architectural blueprints that prevent the rebuild.
1
System Ownership Map
Clear document showing which system is source of truth for each data type. No more debates. No more conflicts.
Example: Leads in CRM, Orders in ERP, Invoices in Finance, Tickets in Support
2
Attribute Dictionary
Complete list of required fields, custom properties, and cross-system relationships. Everything defined before anyone writes code.
Example: Company Name, Deal Value, Order Status, Invoice Number, Customer Lifetime Value
3
Master ID Architecture
The universal identifier structure that connects all systems. Same customer, same ID, everywhere.
Example: Customer ID that exists in CRM, ERP, Finance, Support—same ID everywhere
4
Relationship Model
Visual map of parent-child structures showing how data connects. The blueprint your integrator will thank you for.
Example: Company → Contact → Deal → Order → Invoice → Payment
5
Revenue Leakage Analysis
Exact identification of where deals, data, or decisions fall through cracks. The handoffs that will break if you don't fix them now.
Example: Deals that close but never convert to orders, invoices that never get paid
Common Objections (And Why They're Wrong)
"Can't we just connect the systems and figure it out later?"
No. That’s how you end up with duplicate customer records that can’t be merged, orders orphaned from deals, invoices that can’t find their source orders, and 12 months of dirty data that’s expensive to clean. Getting the architecture wrong costs 10x more to fix later.
"Our integrator said they'll handle the data mapping"
They’ll map what you TELL them to map. If you don’t define which system owns customer data, what the master ID structure is, and how relationships connect—your integrator will guess. And when they guess wrong, you pay to rebuild it. We’ve seen this pattern dozens of times.
"We already know what data we need"
Do you know: Which system is source of truth for customer phone numbers? (CRM? ERP? Support?) What happens when a contact exists in CRM but not in ERP? How you’ll connect a closed deal in HubSpot to an order in NetSuite? What ID structure prevents the same company from existing 3 times with 3 different IDs? If you can’t answer these instantly, you don’t have an architecture. You have assumptions.
Every Company That Skips This Phase Says the Same Thing 12 Months Later:
“We should have spent the 3 weeks defining the architecture. We just wasted 12 months and $150K building on a broken foundation.”
Don’t be that company.
