A prospect fills out your website contact form. Your sales team creates a record in Salesforce, logs the source as 'web inquiry', and sets a follow-up. Three weeks later, the same person emails support with a question. Your support team—who doesn't have access to sales Salesforce, or who does but doesn't check it—creates a second contact record in Zendesk. Six months pass. The customer buys. Your finance team receives an invoice requirement and creates a third contact in Xero with a slightly different spelling of the company name and a different phone number. Now you have three contact records for one customer, scattered across three systems. Your CEO asks for a customer list. Sales reports one number. Support reports a different one. Finance reports yet another. Nobody is wrong; they're just looking at different databases. This is not a data quality problem. It's a system architecture problem. And it costs you money every time a handoff happens. Why each department builds its own contact silo This pattern is not an accident or a sign of incompetence. It's what happens when tools are designed in isolation from each other. Sales teams own the pipeline. A contact in Salesforce is a prospect: they have a deal amount, a stage, a close date. A contact might be marked 'not a fit' or 'in negotiation'. Sales needs to control who gets called, when, and by whom. If support or finance can edit that contact and accidentally delete the deal stage, the sales forecast breaks. Support teams own the ticket history. A contact in Zendesk is a support requester: they have tickets, response times, issue categories. If sales accidentally merges two contacts because they look similar (same first name, different last name), you lose the ticket thread. A customer's previous issue becomes invisible when you try to help with a new one. Finance teams own the invoice record. A contact in Xero is a bill-to entity: they have a tax ID, an invoice address, payment terms, and a history of transactions. If sales changes the contact name mid-contract (a customer rebrand, for example), finance has no way to know which old invoices belong to the new record. Tax audits break. Reconciliation becomes manual. Each team is protecting legitimate business logic. They're not being siloed by choice; they're being siloed by design—the design of software built for a single use case, not for a whole business. The cost of fragmented contacts in real workflows Data silos don't stay quiet. They surface as friction points that slow the team and cost money. Duplicate contact resolution costs hours. A support agent handles a ticket from someone@bigcorp.com. They search the contact database. They find three matches: Big Corp Inc, BigCorp, and Big Corporation Ltd. They guess. They pick the wrong one. The ticket gets attached to a contact with no purchase history, so the customer gets generic support instead of VIP treatment. The sale that hinged on great support dies. Re-qualification happens instead of follow-up. Sales finds a stale contact in the CRM with no recent activity. They don't realize support has been helping this customer for eight months—that history lives in a separate system. Sales sends a cold email: 'Are you still interested in our product?' The customer feels forgotten or ignored, even though your company has been supporting them the whole time. Invoicing delays because billing can't find the contact. A customer signs a contract. Finance creates an invoice. But the contact record in the accounting system has a different email than the one in the CRM, so the invoice gets sent to the wrong address or bounces. The customer doesn't see it. Cash flow tracking breaks. Compliance risk when audit trails fragment. An auditor asks: 'Show me all communication with this customer.' Sales shows emails. Support shows tickets. Finance shows invoices and payment records. They don't connect. The story of the customer relationship becomes three disconnected threads instead of one coherent narrative. A contact is not a sales record, or a support record, or an invoice record. It's a customer. And a customer has a single history that spans every department. The architecture that fixes it: single source of truth The solution is not to force all three departments into one tool (that's what failed with early all-in-one platforms). The solution is to give them one authoritative contact record that each department can view and use according to their own role. The pattern is called a single source of truth (SSOT) , and it works like this: One contact database, not three. A customer record lives in one place. It has a unique ID that never changes. All three departments reference that ID. Role-based access layers. Sales can see the customer's name, company, phone, email, and deal history—but not the invoice address or payment terms unless they need to. Support can see the customer's name, email, company, and ticket history—but not the deal stage or close date. Finance can see