Single Customer View: How Service Businesses Build One

A customer calls about last spring's gutter cleaning. The office manager opens Jobber to find the visit, Quo to see who spoke to them last, CompanyCam for the photos, and QuickBooks to check the invoice. Four tabs later, the caller is still on hold.

A single customer view fixes that call. A single customer view for a service business is one record per customer that links their CRM contact, field service client and properties, calls and texts, job photos and accounting balance. You build it by matching system IDs, phone numbers, emails and addresses across those tools, then applying a written rule for which system wins each field. Every app you run today stays in place. The combined record sits beside them.

Most guides on this topic come from retail and banking marketing teams and stop at "integrate your data." This guide is for operators who need to build it. We cover the match keys each system exposes, the order to try them in, the survivorship rules that settle conflicts, and what the finished screen should show.

What a single customer view means for a service business

The term comes from UK banking. Since December 2010, UK deposit takers have had to keep a single customer view file so the compensation scheme can pay depositors quickly. Wikipedia reports the submission window dropped from 72 hours to 24 hours in December 2025, when the Prudential Regulation Authority's updated depositor protection rules took effect (Wikipedia summary; PRA supervisory statement SS18/15). Retail marketers borrowed the idea to mean one profile per shopper.

A service business needs a different shape, because its "customer" is three linked things:

A homeowner is often all three at once. A property manager is one account with five contacts and thirty properties. If you build your single customer view around people alone, the property manager's calls and photos land on the wrong record. Our rule: match calls to contacts, match photos and jobs to properties, match invoices to accounts, and let the links between those three levels carry everything up to one screen.

Step 1: List what each system knows and the IDs it gives you

Before matching anything, write down what each tool stores and which identifiers it exposes. We open every customer data build with this inventory. Here it is for a common field service stack:

Two patterns show up in nearly every inventory. First, the field service app is the richest source of structure, because it already relates clients, properties, jobs and invoices (Jobber developer docs). Second, photos and calls have the weakest identifiers. Plan for those two to need address and phone matching, plus a review queue.

Step 2: Normalize, then match in a fixed order of trust

Matching fails most often on formatting. (555) 201 0144, 555.201.0144 and +15552010144 are the same phone to a person and three different strings to a database. So clean every key before you compare it:

• Phones: convert to E.164, the ITU format that starts with a plus sign and country code and runs at most 15 digits (Twilio E.164 glossary). Quo already asks for this format on contact writes.
• Emails: trim spaces and lowercase the whole address. Flag shared inboxes like office@ or billing@ so they stay out of person matching.
• Addresses: standardize street suffixes to the USPS list (Avenue to AVE, Street to ST) per USPS Publication 28, split out unit numbers, and store latitude and longitude when a source has them.
• Names: keep the original, and store a match copy with punctuation, "LLC", "Inc" and trailing periods stripped. That last step undoes the QuickBooks display name workaround.

Then run the keys as a ladder. Each rung only sees the records the rungs above it left unmatched:

IBM describes the goal of this work as selecting the right attribute values from disparate records to build one trusted "golden record" (IBM Community on survivorship). The ladder gets you the records to choose from. Two rules keep it safe. A phone number shared by several accounts (a property management office line, a family landline) drops out of rung 3 and goes to review. And every rung 5 match waits for a person, because a wrong merge puts one customer's invoice in front of another customer's caller.

Step 3: Write survivorship rules field by field

Once records are linked, they will disagree. The CRM has a mobile number from the first web form. Jobber has a newer one the tech typed in on site. QuickBooks has the billing contact's office line. Survivorship rules decide which value the combined record shows. IBM's matching tools name three common tiebreakers: most recent, most frequent, and preferred source (IBM Community). For a service business, preferred source does most of the work, with recency as the fallback:

Three habits make these rules hold up. Keep every losing value in history so a reviewer can see what changed. Store the source system and source ID beside every winning value. And write the table down where the office can read it, because "which phone do we text?" is an operating decision as much as a data one.

Step 4: Decide what the combined record shows

The matching and the rules exist to fill one screen. When someone searches a name, phone or address, the single customer view should answer five questions in under a minute: who is this, where do we work for them, what did we last say, what did we last do, and what do they owe.

Each source attaches at the level where its identifier is strongest, and the links carry it up to the account. In practice the screen holds these blocks:

• Header: billing name, account owner, lead source, open balance with its sync time.
• Properties: each service address with its next visit, last visit and open quotes.
• Contacts: each person with role, starred phone, and whether texts are allowed.
• Timeline: calls, texts, visits, invoices and payments in one date order, each tagged with its source system.
• Photos: the latest set per property, linked to the visit that produced it.
• Exceptions: unmatched calls, unpaid completed work, and records waiting in review.

Keep two dates apart on that screen: last attempt and last conversation. The Quo event that reports an answered call also fires when an outgoing call reaches voicemail, so a raw call log can mark a customer as "contacted" when nobody spoke. Show both, and let only a conversation reset follow up timers.

If you want a number to take to your partner or office manager, plug your own week into our customer lookup calculator below.

Step 5: Build it in this order and keep it current

We run a single customer view project as a sequence where each step produces something the office can check:

1. Pull a sample. Export 200 to 500 recent customers from each system, including the messy ones: property managers, renamed accounts, customers with two phones.
2. Normalize and run the ladder. Count how many records land on each rung. This tells you how much review work to expect before you build anything permanent.
3. Review the middle rungs with the office. The people who answer the phone resolve rung 5 matches in seconds. Their decisions become test cases.
4. Write the survivorship table and get the owner and bookkeeper to sign off on the money fields.
5. Build the pipeline. Store raw copies of each source, the cross reference table of matched IDs, and the combined record as three separate layers, so a bad match can be undone without reloading everything.
6. Ship one screen to the people who answer the phone, then add the owner's reporting views on the same tables.
7. Run the review queue every week. New customers, new phones and new properties keep arriving, so matching is a standing process.

For refresh timing, most service businesses do fine with two speeds. Calls, texts and job status changes update within minutes through webhooks where the tool offers them. Accounting and the CRM refresh on a schedule, hourly or nightly, with the sync time printed on the screen so nobody mistakes a stale balance for a current one.

The pipeline side of this is familiar ground for us. On the New York Lottery data pipeline in 2025, we built AWS ingestion and batch processing, secure movement of encrypted files, and deployment automation for a system reaching over 6 million users. During our Shopify engineering and integration work from December 2022 to September 2023, we kept Salesforce and event integrations running in production. We bring the same habit to a customer view build: every scheduled job and event feed gets a visible timestamp and an alert, because both kinds of load can fail quietly.

FAQ

What is a single customer view?

A single customer view is one combined record per customer built from every system that holds data about them. For a service business that means the CRM, field service app, phone system, photo app and accounting, linked by matched IDs, phones, emails and addresses.

Is a single customer view the same as customer 360?

Yes, in practice. Vendors use "customer 360," "360 degree view," "unified customer view" and "golden record" for the same goal: one trusted record per customer assembled from many sources.

Do I need to replace my CRM or field service software?

You keep them. The combined record sits beside your current tools and reads from them. Your crews keep using the field service app, your office keeps using the phone system, and your bookkeeper stays in accounting.

What should I match customers on first?

Start with system IDs that one tool already stores in another, such as an accounting customer ID saved by an existing sync. Then use exact email, then exact phone in E.164 format, then standardized address. Send name matches to a person for review.

How do I handle one customer with many properties?

Model three levels: the account that pays, the contacts who call, and the properties where crews work. Attach calls to contacts, photos and jobs to properties, and invoices to the account. The links between levels roll everything up to one screen.

How long does it take to build?

It depends on how many systems you connect and how messy the records are. Run the match ladder on a sample from each system first. The share of records that land in review drives most of the timeline.

Where to start

A single customer view pays off the first time someone answers a call and sees the property, the last conversation, the photos and the balance on one screen. You get there with four decisions you can make this month: which three levels your customers have, which match keys to trust in which order, which system wins each field, and what the screen must show.

For the deeper question of what to do when records disagree after they are linked, read our guide on customer data integration conflicts. When you want help with the build, Cass & York connects field service, phone, photo, CRM and accounting data into one customer record and the reports on top of it. Start with a free workflow review: pick one process, and we review a sample of your records and show you a working example built on them. You can also see our integration and data services.

Sources

• Single customer view, Wikipedia
• SS18/15 Depositor protection, Bank of England Prudential Regulation Authority, updated November 18, 2025
• Client information in the Jobber app, Jobber Help Center
• Jobber Developer Center, Jobber
• QuickBooks integration FAQs, Jobber Help Center
• Contacts guide, Quo developer docs
• API changelog, Quo developer docs, entry dated May 26, 2026
• Create project, CompanyCam API reference
• QBO guidance: two customers with the same name, QuickBooks Community
• What is E.164?, Twilio
• Publication 28, section 234 Suffixes, United States Postal Service
• More flexible data survivorship, IBM Community, March 28, 2023