A Customer 360 is the thing every business says it wants: one complete, trustworthy view of each customer, pulled together from every system that knows them. The hard part typically is that the different data sets that are used for these systems are rarely compatible with each other. In addition to being typically messy, they rarely have the things that you need like a common key to bring them together. Sales knows Edward Flores, customer since 2012, VIP; the storefront knows Ed Flores, six orders, ships to Summerlin. They are the same people but nothing in the data joins them. That's the gap entity resolution closes, and this recipe builds the whole thing on top of it.
There are two things worth calling out in this data. First, the two files don't share field names. The CRM has already split things out into first_name and last_name plus a zip, while the orders feed hands you a single customer_name to break apart, a set of ship_* address fields, and a contact_phone that's formatted completely differently. That mismatch is on purpose…mapping all of it over to the Senzing spec is part of the recipe, and the MCP's mapping_workflow handles that piece for you. And here's a fun wrinkle…the orders feed has no birthdate at all, because an online store wouldn't ever ask for one. So a shared email ends up being the thing that carries a customer across something like a move. Second, I served the whole thing through the Entity Browser we set up below, stretched into a full Customer 360 app that shows useful things like each customer's profile, activity, related-customer review, and an overview dashboard.
