Sixteen Name Fields and One Mailing Address

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

There are two ways I have watched a customer master record fail, and they point in opposite directions. In the first, the record keeps its own copy of the name from every system that feeds it and lays one more on top, so a steward opening it is handed a column of names and has to work out for himself which one to believe. In the second, somebody has ruled that a customer has exactly one address, and billing, legal and marketing each drift back to the system they trust, because the approved address is not the one they need. Both records were delivered. Neither is used for the thing it was bought to do.

What the two have in common is that neither failure lives in the software. Each is a decision about the business, made during configuration by whoever happened to be configuring, because nobody made it earlier. That is the claim I will defend here: aligning a Profisee implementation with a customer 360, and with the transformation program that usually pays for one, is mostly deciding and only partly building, and the deciding has to be done by people who will never log in to the platform. The claim is about the operational customer record — the one invoices, legal notices and billing run on — not a real-time marketing profile, which is a different product with a different argument.

A category its seller defines, and concedes is defined differently by whoever you ask

Start with the vendor's framing. Profisee's explainer defines customer 360 as "the concept of having all your customer data in one place," and concedes in the next breath that it "can have different (and oftentimes conflicting) definitions depending on who you ask" [1]. The same page gives, as one of the main reasons for failure, "a lack of measurable business goals and implementation roadmap," and describes the two ways that lack plays out: companies never start because they have no endgame, or the scope creeps across so many use cases that it "becomes far too impractical to ever achieve" [1].

I take that at face value, and I think it says more than the page means it to. A category whose seller concedes it means different things to different buyers, and whose failures the seller attributes to goals rather than to software, has told the buyer where the work is. Nothing in a license settles which customer the enterprise means. That question arrives on the first day of configuration, and by the end of that day it has been answered, well or badly, by someone.

The page adds a warning that pulls the other way: "nearly all real-world business challenges involve both customer data and other business information like the products they buy, locations they visit or campaigns they engage with" [1]. Read as a scoping instruction, that pushes toward a bigger first domain. Read as a sequencing instruction, it says the customer model has to be drawn so that a product or location domain can sit beside it later without the customer record being torn up to make room. I read it the second way.

The address was already several addresses

The consolidated failure is the easier one to test, because it can be checked against documents a business already produces.

A single electronic invoice under the Peppol billing specification must be able to carry "the official postal address of the Buyer, Seller and Tax representative of the Supplier and their place of business and registered office" (requirement R53), and at invoice level must be able to identify up to five parties — seller, buyer and, where they exist, a separate deliver-to party, payee and tax representative — "including their legal name and address" (R57) [2]. Before any master data platform touches it, then, the customer's address is several addresses, and each of them has a legal job. Profisee's own address verification page gives e-commerce checkout as its first use case, where the aim is that "the shipping and billing addresses a customer enters" match postal records [3]. That is two addresses for one customer, in the vendor's first example.

So a master record with one approved mailing address is not a simplification. It is a refusal of a distinction the business is obliged to keep, and the people who need the distinction will keep it somewhere else — which is the opposite of what the record was funded to achieve.

The federated failure is harder to test against a document, because it looks like diligence. The survivorship literature is where it shows. Profisee documents six survivorship techniques — source system priority, most recent update, most complete record, a data quality score, conditional rules and hybrid approaches — and lists among its best practices "Define rules at the attribute-level" and "Involve business stakeholders in rule definition" [4]. Put those two sentences together and the arithmetic is uncomfortable. A customer domain that masters a hundred attributes carries a hundred authority decisions, and each needs a person in the business who can say which source wins and be held to the answer. That person already has another job. A federated record is what a program builds when it cannot find those people: instead of deciding, it keeps every source's value and lays a field called master over the top.

The same page prices the rules that look free. A recency rule "requires reliable timestamp metadata across source systems," and it "can be thrown off by metadata updates completed in a nightly batch run" [4]; a batch job that merely touches a row can win the attribute and publish the wrong value. Completeness rules, it says, are "best used in combination with other techniques that favor recency" [4]. Each is the running cost of a rule, stated where the rule is stated, and each is a fact about how the business's own systems behave that no configuration screen knows.

Four implementation styles, and which one a customer 360 is

The vendor also publishes the vocabulary for the coarsest version of the same decision [5]. In the registry style, "Source systems remain the SOR" — the system of record — and "Source systems continue to manage their own data"; it is easy to implement and "doesn't allow for much control." In consolidation the platform is the hub, "Data is not synced back to source systems," and the style is "ideal for business intelligence (BI) and data warehouse use cases." Coexistence syncs the consolidated values back; the centralized style is "typically very difficult to implement" [5].

That taxonomy makes each of my two failures legible as a style chosen by accident. The sixteen-name record is a registry sold as a consolidation: every source keeps its own truth, and a field labelled master is published as though a choice had been made. The one-address record is a consolidation applied to work it does not fit: the vendor reserves that style for analysis, and an invoice, a legal notice and a mailer are three operational acts that go to three different places. What the taxonomy cannot do is say which system owns a customer's legal name. That is still unmade when the style has been picked.

Matching got cheaper. Authority did not.

The part of this work machines are getting better at is finding which attributes mean the same thing. A 2024 study by Parciak and colleagues describes why it is hard: "attribute names are often cryptic and involve domain-specific abbreviations not occurring in thesauri," and legal restrictions can keep a matcher away from real data values [6]. Their health-data benchmark had 1,839 candidate attribute pairs and 49 true matches, a problem the authors call "highly imbalanced." Given only names and descriptions, a large language model beat a string-similarity baseline on average under every prompting strategy but the narrowest, "with a maximal increase of 0.245 points," yet "often fails to express an opinion on all attribute pairs requested," and in practice "one needs to manually verify the match candidates" [6]. Profisee sells assistance at the same step, offering to "automatically generate and map new master data attributes using AI" [7].

Both aim at the hours between the metadata arriving and a proposed mapping existing, which is the cheapest step in the program. A matcher can establish that two systems both hold an email address. It cannot establish that one of them went stale years ago because nothing writes back to it; that is a fact about how two departments work, and no column description records it. I would put it more strongly than the study does: the step tooling has sped up was never the reason these programs fail, and a plan that books the saving as though it shortened the program has misread where the time goes. The study is one benchmark in one domain, and I have carried over its shape rather than its numbers.

The platform carries the decision; it is not a home for old logic

Profisee's integration documentation draws its own boundary, and I would rather quote it than paraphrase it. The capability is for moving trusted master data in and back out, and it "is not intended to replace commercial ETL tools for bulk transformations or migrations" [7]. The workaround is in the same answer — "Azure Data Factory ships with native pipeline templates to move data in and out of Profisee" — alongside documented connections to Salesforce, Dynamics 365, SAP, Snowflake, Google BigQuery and MuleSoft "through Profisee's REST API and SQL interfaces" [7]. That is a limitation and its workaround, stated by the vendor in one place.

The hardest opening a customer 360 can be handed is a request to absorb a previous build: a wide customer table assembled by an earlier warehouse team, with its business rules living in the load code. Martin Fowler's account of why wholesale replacement of a legacy system goes wrong is the best short statement I know of the trap in that request: "Replacements seem easy to specify, but often it's hard to figure out the details of existing behavior. What's worse, much of that behavior is stuff that isn't really wanted, so building it is a waste" [8]. His alternative moves behavior out of the old system in pieces and accepts, as its price, a transitional architecture that lets old and new run side by side and is thrown away afterwards [8].

Read beside the vendor's integration boundary, that supports one conclusion. If preserving a previous build's transformation logic is the ask, that logic needs a home that is not the master data platform. Saying so in the first week costs a meeting. Saying so in the fifth month costs the program.

The argument stops here; what follows is operating experience — mine, from the implementations I have run, offered as pattern rather than law, with the warrant changing accordingly.

Profisee, weighed — the limits first

The practice behind this publication is a Profisee partner, and it also holds a referral agreement with Profisee: clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on this category being bought at all. This article also argues for decision work before configuration, which a partner bills for, and against pre-built content that would shorten an engagement. Read the next few paragraphs as most suspect where they are kindest, and weigh the criticisms above the praise.

The limits, then, as I have met them on the engagements I have worked. These are my observations, not measurements, and each one is checkable by a buyer against its own estate.

The platform's centre of gravity is Microsoft. It is primarily a Windows and Microsoft product, it is tied closely enough to Azure that I would call it a hard fit on another cloud, an install through its on-premises installer needs a Windows Server underneath it, and the back end is Microsoft SQL Server rather than a database of your choosing. Microsoft's own documentation of the product confirms the heritage from the other side: "Profisee originated in Microsoft technologies," it "runs natively on Azure Kubernetes Service (AKS) and Azure SQL Database," and "for many years, Profisee MDM was built on Microsoft Master Data Services" [9]. The same page also says the product can be deployed "in your Azure tenant, in any other cloud tenant, or on-premises," or taken as a service Profisee hosts [9]. I do not think those contradict my point so much as sharpen the question a buyer on another cloud should ask: supported and natural are different words. The packaged Kubernetes service Microsoft describes, deployable in a cloud tenant or on-premises [9], is the product's other self-deployed model: a standard Kubernetes installation, deployed into a cluster rather than installed onto a Windows Server. The Windows Server the product is installed onto belongs to the installer path, which is still in use, and on Azure that server is almost always a virtual machine. Ask any proposal which deployment model it assumes, because one needs a server for the product to be installed onto and the other does not.

It keeps its own copy of everything it masters. It does not read a data lake in place, so it takes no part in de-duplication done lake-side, and the copy costs extra compute and storage, both in SQL Server and on the infrastructure underneath. For a customer 360 in an estate that has already built a lakehouse, that means the customer lives in two places by design, and somebody has to own the reconciliation between them.

And the pair that costs a practice like ours most: versioning and source control are poor, and the platform does not sit comfortably in a continuous integration and delivery pipeline. That pair bites this article's argument directly. The decisions I am arguing for should be made before configuration — which attributes are mastered, which source wins each, the sentence that divides the platform's job from the source systems' — and they are exactly the material that ought to be versioned, reviewed and deployed like code. The platform is weakest at the point where the decisions most need a history. The workaround I would draw from that is to keep the decision record in source control outside the platform and treat the configuration as its implementation, reviewed against it; that is my proposal, not something the product supplies.

Now the other column. Where I think the platform genuinely leads rather than keeps up is web integration, its UI screens, and the low-code screen building it calls FastApps. It is directly integrated with Microsoft Fabric and Purview, which makes it a natural addition to a Microsoft and Azure estate; Microsoft's page describes the model being published into Purview, "where it can participate in governance" [9]. Its integration tool, Connect, is one of the stronger low-code pipelines for a buyer who prefers buying connectors to writing them, and it is extensible, so an integrator can add their own. And AIsey, its in-product assistant — Profisee's counterpart to Microsoft's Copilot — helps build Connect connectors, pulls structured values out of free-text fields, reports on the data and answers questions about it inside the product.

Notice that the two columns overlap rather than sitting side by side. The deep Microsoft integration is the second strength, and the four Microsoft-shaped limits at the top of the list — Windows, the Azure fit, the installer's Windows Server and SQL Server — are the same fact read from the other end. It is what makes the platform fit one estate and misfit another, and a buyer who reads the lists as unrelated has missed the finding.

The honest version of the praise carries its own deflation. The vendor has done a good job of automating and standardizing ingestion and mastering, and the install and the infrastructure have been reduced to the easy part. The first pass is quick, a proof of concept is quick, and standing the platform up from nothing on clean ground is quick. None of those things is what the business needs. The detail is in the configuration and the testing, and taking the install off the table mostly means there is more time left for the hard part.

For the question this article asks, the strongest single piece of the product is the steward's screen. Records matched by "an ML-powered matching engine" are "displayed side-by-side in a match group for data stewards to review," the steward chooses "winners" to "survive the merge and be stored in the golden record," and "Full audit trails are available" [10]. That screen has a precondition the page does not state: a steward can apply policy there only if a written rule got there first. Without one, the steward is inventing policy, one record at a time, and the audit trail faithfully records the invention.

Where I start, and the worst place to start

Asked where I would begin a customer 360 if I could choose, and where I would least want to, I answered both halves:

Ideally, I'd like to start by reviewing, classifying and compartmentalizing the customer-related information from the various systems we're planning to integrate. Extracting the schema metadata and lining it up next to one another gives a good picture of where there are redundancies and where there are single sources of truth.

The worst place to start is with a single 'unified' table fed by all the sources and handed over by the previous "MDM" (read: ETL/DW) team without documentation beyond 'the code.' Now there's an 'operational' system that needs to be monitored, maintained and bug-fixed alongside the new build and the first ask is going to be a straight-line lift and shift from the current implementation to the new one while preserving the current undocumented logic. Good luck!

The first paragraph is the whole of my preferred opening and it is deliberately modest. Nothing is modeled and nothing is loaded. The metadata comes out of the systems themselves — names, types, lengths, keys, whatever description text each carries — not out of a hand-kept data dictionary, because a dictionary describes the schema as it was signed off and the schema is what is actually there. Laid next to one another, the attributes sort into three piles. Some are carried by several systems, and every survivorship rule the program ever writes will live in that pile. Some are carried by exactly one, and those need no argument. The third pile is where the expensive mistakes are: attributes that look identical and are not. A customer number that names a legal entity in one system and a shipping account in another; a status flag with the same name on both sides and a different list of permitted values behind it. Those pairs match on name, pass every check that reads names, and produce a merged record that stays wrong until a report disagrees with a ledger.

The second paragraph is the one I would ask a sponsor to read twice, and the scare quotes in it are the argument. A wide table fed from every source, with its rules in the load code, is an extract, transform and load build with a data warehouse at the end of it, carrying a master data label. The difference is not cosmetic. In a master data program somebody can say why a value is what it is without reading a pipeline; in the inherited build nobody can.

Three costs are folded into that paragraph. Logic that exists only as code has to be recovered branch by branch, into a document nobody budgeted. The old system keeps running in production for the whole of the new build, and a plan that does not name the work of watching and fixing it has handed that work to the people doing the build. And a straight move that preserves behavior is a promise about behavior nobody in the room can state — Fowler's point, from the other side of the table [8]. My "Good luck!" is not a joke about difficulty; the new team is being asked to guarantee something it has not been allowed to read.

The limitation that goes with this start has a workaround I use often, and it belongs here because it is where inherited logic can safely go. Demos run the happy path on tidy, structured data, and real data is never that tidy; Connect's transformations and filters are not robust enough to make ingestion as easy as a demonstration suggests. So I frequently do the pre-processing outside the platform: external tables in SQL Server as the base for transformation views, with the shaped result handed to Connect for Profisee to ingest. That is where a previous build's rules can live while they are read, tested and either kept or retired — beside the platform, visible, and versioned with everything else, rather than smuggled into the master data layer where nobody will look for them.

Profisee decides what; the source decides how

The rule I would put on the wall of any customer 360 is one I have already stated, about where the platform's job stops and the source systems' job starts:

As a rule: Profisee decides what, other systems decide how. Profisee, or MDM, decides what wins while other systems decide how they pick what to present. SalesForce decides how to classify a Customer—Top 50, Premiere, Custom, Bulk, Grey, Peer, whatever—Profisee decides what to include in the 'Customer' record—SF.Classification -> SalesForce_Classification, or IF(SAP.Classification is not null, SAP.Classification, SF.Classification) -> Customer_Classification. The logic of how to populate a field belongs in the providing system, the logic of how to populate a Master field belongs in the MDM system. MDM systems should take what other systems give them unchallenged, the expectation is the upstream system has performed appropriate transformations and logic to the data such that what they provide is, as far as that system is concerned, correct. Once MDM has those values, it applies its own rules to decide which source 'wins' a spot in the Master record and where. MDM: what are we showing to the consumer. Source: how did we populate that field with that value.

The two mappings in the middle are illustrative pseudo-code, not the platform's expression syntax, and they are two different answers. The first carries a source's classification straight through, under a name that says where it came from. The second prefers one source and falls back to another, and produces an attribute that belongs to the master record rather than to either system. They correspond to two of the vendor's documented rule types, source system priority and conditional rules [4] — which is some evidence that the rule describes the grain the product was built at rather than fighting it.

The rule's practical value is that a room can apply it in seconds. Hold any proposed piece of logic up against it and the question people actually have — does this belong in the new tool at all? — resolves. It has one condition: the sentence is agreed before configuration starts, not reconstructed afterwards from whatever got built.

The contestable sentence is the one about taking upstream values unchallenged, and the platform's own documentation is where to test it: if the product is built to change a value a source supplied, the rule as I stated it is wrong about the product it is about. It is built to. Address verification checks a customer-entered address against postal records and can run "continuously based on configurable triggers" [3], and the vendor's data quality page describes a Purview integration that works by "enforcing governance standards and remediating deficient data," with outside services used "for data enrichment and validation" [11]. So the rule does not survive in the form I gave it.

Where a standardized address actually ends up is the whole question, and my account of it is this:

Profisee can store the 'standardized' address information anywhere. It can create new columns as part of the initial configuration, use existing columns already set aside for the purpose or overwrite the existing columns passed into the built-in address standardization engine. Profisee also supports third party address standardization and geocoding subscriber services through Melissa as part of the out-of-the-box functionality in Connect. Further, AIsey can create custom JSON service connections for Connect that can utilize any documented third party address standardization and geocoding interface like Google.

That answer moves the rule rather than rescuing it. Placement is a configuration decision somebody makes, and one of the three options writes over the value the source landed. The vendor's own configuration guidance, as the practice recorded it from the gated support documentation, is on the same side: keep the source and the output in separate attributes, because using the same one will overwrite the existing values and is not recommended for legacy tracking [12]. Recommended is not enforced, and I would not want any reader to come away thinking the product prevents the overwrite. It does not.

The rule I keep, then: the platform may act on a value — verify it, standardize it, enrich it — but not on the logic that produced it, and the acted-on value is written beside the landed one, never over it. That smaller rule still rules out two things anyone can walk into a running implementation and check: logic inside the master data platform that decides how a classification is computed rather than which computed classification wins, and a verification setup that writes over what a source supplied. Those are the two mistakes this article is about, so the rule is still worth putting on the wall.

Sixteen names, one address

The two failures I opened on come from one answer of mine about the shape of a customer record:

Over or under generalization. 'Federated' MDM systems have a full suite of 'duplicate' fields for each system they 'master.' So they wind up with sixteen different name fields because they 'master' data from fifteen different systems and slap a 'master' name on top of it—SF_Name, SAP_Name, C365_Name, D365_Name, Mktg_Name, eMail_Name, MailGun_Name, etc. Alternatively, even though there are precise, specific, business critical reasons for having 'duplicate' fields, the system over-consolidates. A customer can only ever have one 'mailing address,' even though there are separate addresses necessary for billing, legal and marketing purposes, the 'master' record only contains the 'approved' mailing address. This tends to lead to more siloing instead of less as the 'master' data is either too busy to be able to be used or simply not fit for purpose.

The federated end is the easier one to argue against. Nobody chose it: it is what happens when each integration is scoped on its own and every disagreement is settled with another column, and it leaves the steward doing the job the platform was bought to do — a registry wearing a consolidation's badge [5].

The consolidated end is where the real damage is, because it looks like discipline, and it fails more quietly. A cluttered record annoys its users; an over-tidy one simply stops being consulted, and nothing in the program's reporting has to notice. The record is still there, the status can stay green, and the reports downstream keep producing numbers whose provenance nobody checks. That is what my last sentence in the quotation means by more siloing rather than less, and it inverts the premise the program was funded on.

The test I would apply to both ends is one question per proposed field: does the distinction this field carries change what somebody does? If it does not, it is not a field. Fifteen source-qualified name fields fail it, because a name held in the marketing platform and a name held in the mailing service are not two kinds of name. Billing, legal and delivery addresses pass it, because sending an invoice somewhere is a different act from serving legal notice somewhere, and the two can go to different buildings.

I should be honest that the test and the quotation do not quite agree. The quotation treats the federated shape as pure failure; the test would admit a source-qualified field beside the master value wherever the distinction changes what somebody does, and keeping lineage for a reconciliation is the obvious case. My own classification mapping in the what-against-how rule does exactly that — it carries a source's classification through under the source's name. So the more defensible form of the claim is that source-qualified fields are a decision to be justified one at a time, not a default to be applied to every system that feeds the record. Sixteen of them justified one at a time would be a strange result. Sixteen of them by default is the failure.

What an overmatch costs, and when the bill arrives

The one-address record is over-consolidation at the level of the model. The same fault at the level of individual records is the overmatch, and it is the one that sends people home late. Asked what fast time-to-value costs later, I named it:

Intelligent error handling and depth of process. Like many things in the world, it's the details that matter and being 80% right out of the gate still means you're 20% wrong. Trying to force that remaining 20% into the 80% box causes late-night and weekend work for data stewards trying to unpick and un-match records that should never have been matched in the first place. All while marketing and production are operating on bad aggregates.

That bill arrives at the first quarterly reconciliation where someone needs to justify the overmatches and corresponding over allocations.

Two things in that answer are worth separating. The first is direction. The damage I am describing is not the duplicate the platform failed to catch; it is the pair it should never have merged. A missed match leaves two records that somebody can still join later. A false one has already published a merged record that other systems consumed.

The second is the date. The cost does not arrive when the rule is configured or when the load runs. It arrives at the first quarterly reconciliation, when somebody has to justify allocations booked to a customer the platform created by merging two. That is why the shortcut survives the build: the people who could have objected to it are not in the room when it is taken.

The shortcut has two forms, and I have named both before. It is possible to make a platform look fully automated by forcing everything into one shape, or by setting the auto-approve threshold for matches low enough that almost nothing waits for a person. The second of those guarantees more work for the data stewards, not less — work that arrives after decisions have been taken, and reports issued, on the strength of the false merges.

When one of those merges is found, the unwinding has a shape I have lived through on a customer's estate, and it runs in widening units: minutes to restore the master record; hours to reload the data warehouse downstream of it; more hours to regenerate the reports; and further hours again to revisit the decisions and presentations that were built on them. What makes that ladder worth printing is not its length. It is that the clock only starts once somebody has noticed, and nothing on the ladder measures the time before that.

Beside the transformation, not in front of it

The other half of the brief — aligning the implementation with the digital transformation that pays for it — is where the funding language and the operating reality part company most. My own position on what master data is, inside a transformation, is blunt:

There's nothing 'transformative' about MDM. Properly understood, MDM is an enabler, not a transformer. If it does what it says on the tin, MDM will provide clean, uniform, de-duplicated data that can be trusted to downstream systems. It won't, by itself, do anything with that data, though.

So I would strongly advise against 'leading' a transformation with MDM. It should be stood up beside other initiatives and used as a deliverable multiplier.

That is an alignment instruction, and it is narrower than the language most of these programs are funded under. The master data work does not lead. It stands next to the initiative that will use the data — the new commerce platform, the finance consolidation, the service desk — and its value shows up in that initiative's deliverables. It also answers the vendor's scoping failure [1]: a program funded against a phrase has no basis for refusing a request, and one standing beside a named initiative has one. The attributes that belong in the first master record are the ones that initiative will act on, plus the ones needed to match records reliably. The rest wait for a later domain, and the model is drawn so they can arrive without the customer record being rebuilt; that is the sequencing reading of the vendor's warning about product and location data.

There is a cost to standing beside a larger program, and I would not want that advice read without it. I have named that cost myself:

Interdependence. Cross-domain or responsibility dependency can cause all kinds of issues. Spill-over of poor performance, inability to meet deadlines or lack of solid deliverables can all serve to paint the MDM program with tar they didn't earn themselves. Whenever MDM, or any other program, is part of a large, combined initiative, the entire initiative is treated as one, cohesive unit. Therefore, it either all succeeds or all fails. It's a risk either way, but it is also sometimes the only way to get MDM funded as part of a larger 'modernization' or migration initiative.

The last sentence is the one that keeps the advice honest. "Stand beside it" is not always a free choice; sometimes it is the only way the work gets funded at all, and the price is shared fate. So I would turn my own recommendation into something a program can actually do: stand beside the initiative, and make the master data deliverables separable enough that they can be seen to land on their own. If the larger program slips, the customer record that shipped should still be demonstrably shipped, with its own consumers and its own evidence of use, rather than a line inside somebody else's status report.

That leads to the question every sponsor asks, which is when they will see value. My answer to that refuses the premise more often than it answers it. I do not think sponsors are won in flight; a program starts with one or goes without until it is in production and bidding for its second phase. Early value, properly scoped, is a production deployment, and it is a risky thing to attempt early. Cutting quality assurance and user acceptance testing does compress the timeline, but only by moving the testing into production, where the happy path is fast right up until the day someone leaves it.

The same answer has a second half that is less contrarian and more useful. Master data programs are the textbook Pareto case: most of the visible value arrives early, and then there is a long tail. The larger the enterprise, the messier the data and the longer the program, the longer that tail gets, and the harder it is to justify the effort in the middle and at the end. So rather than front-load the proof, I try to leave something visible and useful for the business — small wins outside the core ask — spread across the whole of the implementation, so that there is always a recent reason to keep going.

Two promises make that tail longer than it needs to be: comprehensiveness out of the box, and full automation. Nothing is comprehensive until "comprehensive" has been defined — here, by the attribute list from the metadata pass, agreed by the people who own the systems — and nothing is fully automated while every mastered attribute needs a named owner and some share of the matches needs a person.

The template on offer, and the date on the slide

Somewhere in the first month a program is offered a shortcut: a pre-built customer model, a consolidator, an accelerator. Asked what I make of those, I said:

'Out-of-the-box' templates, consolidators or accelerators. Unless they were built specifically for companies that use SalesForce, SAP and Oracle Financials, in exactly the same way your company does, you're going to spend as much time refactoring as you would 'save' by using it. From a pure implementation perspective, plan on doing your own custom build-out because your company is functionally different from the 'standard' for which the accelerators were designed.

Read the condition rather than the verdict. The claim is not that pre-built content never pays. It is that it pays only where the source systems are the ones it was built for and are used the way it assumes, and the second clause is the one that fails: two companies running the same three products still classify customers differently and still disagree about who owns an address. The vendor says something close to half of this itself — pre-built applications "must be modified to fit the specifications of the business, legacy data sources and use case in question" — and, on the same page, counts "starter solution templates" as an advantage of the platform approach [1]. Both sentences can be true. A template moves the starting line. It does not move the finish.

The vendor's own implementation paths are priced on exactly that logic. Its fastest path runs approximately four to six weeks on fixed-scope, domain-specific templates for single-domain analytical solutions; the middle path runs about twelve weeks for up to two domains; the tailored multi-domain path runs three to six months depending on complexity [13]. The fast path is fast about the part that is the same everywhere, and it is scoped to analysis — the consolidation style again [5]. An operational customer 360 that will send invoices and legal notices is not that shape.

A custom build-out is less heroic than the phrase sounds, and it need not mean writing software. It means a model drawn against the company's own attributes, survivorship authored per attribute with a named person behind each rule, and integration written against the systems actually in use. The platform still carries the matching, the merging, the steward's screen and the audit trail. What a team builds itself is the set of decisions underneath those, and they were never in the package. Configuration gets complicated — as software tends to — at exactly the points where a company's requirements do not mesh with the defaults, and a customer 360 is mostly such points.

Which brings me to the date. When someone wants an honest one, my first instinct is to say I will supply it the day after it arrives, and still be wrong. Every early figure is a guess, and happy-path numbers are marketing figures: they look fine in a presentation and terrible in accounting. What I actually do, now that most programs run in Agile increments, is estimate a minimum of two sprints — one to implement, one to test and deploy — and treat a full program increment of six sprints as the more practical shape: two to build and test, two to expand and integrate, two to publish and train. That swells and shrinks with the volume of work, but as a starting point for a scientific wild-ass guess or a rough order of magnitude it holds. Tooling keeps shortening pieces of it, Connect among them for basic integration, and something still comes up in every implementation, which is why I carry a twenty percent contingency on time. None of that is a measurement; it is the frame that shows a sponsor how much of the number is guess.

Still in use a year later

The question under all of this is practical: will the master record still be used a year after go-live? The decisions make it possible. They do not make it happen, and the part that makes it happen is the least technical thing in the program.

Stewards open a tool when it is part of how their day is judged. The only reliable lever I know is to move their performance and reporting measures onto the tool, so that the stewardship work is visible where their manager already looks; when that happens, use jumps. The second lever is design. In many of the businesses I have worked with, the people doing stewardship have other jobs, and they need to get into a decision and back out of it quickly. This is where the platform's email-driven workflows and its FastApps screens earn their place: a business or data owner receives a message, makes one inline call — approve, reject, pick — and returns to whatever they were doing. A steward's screen that requires a half-hour session will be visited when there is a half-hour, which is to say rarely.

The attribute owners from the survivorship decisions are the same people. A customer 360 that asks a hundred owners for a hundred decisions, and then asks them to log in to a separate application to keep them current, has designed its own attrition.

And the decisions have to outlive the people who made them, including the implementers. I do not run an implementation differently when I know I am leaving it than when I expect to stay; done properly, the policies, procedures and documents come out of the work as it goes, so it is ready to hand to the client or to another team at any point. The point is that what the program knows sits somewhere in the organization rather than only in the heads of its engineers, architects and stewards. Given the platform's weakness on versioning, that "somewhere" is a decision record kept in source control, and it is the one artifact of a customer 360 I would insist on even if everything else were cut.

What the record does not change is the order. The decisions are made before configuration, or they are made during it by whoever is configuring — and where a partner is configuring, that is the partner, this practice among them. We are the wrong party to decide whether finance or sales owns a customer's legal name. The most useful thing an implementer can do on the first day of a customer 360 is refuse to.

An earlier version of this piece — written before this publication rebuilt how its voices are generated — is published unedited at Profisee Decides What. Other Systems Decide How. (original), so the two can be read side by side. The account of why is at The Voice Problem.

References

[1] Profisee, "Customer 360 — What, Why & How?", by Benjamin Bourgeois, published October 5, 2021, updated August 2, 2024 — vendor explainer for the category. Cited for the vendor's own definition, "Customer 360 is the concept of having all your customer data in one place," and its concession that it "can have different (and oftentimes conflicting) definitions depending on who you ask"; that one of the main reasons for failure is "a lack of measurable business goals and implementation roadmap," leading to projects that never start or scope that "becomes far too impractical to ever achieve"; that "nearly all real-world business challenges involve both customer data and other business information like the products they buy, locations they visit or campaigns they engage with"; that "pre-built applications must be modified to fit the specifications of the business, legacy data sources and use case in question"; and that the same page counts "starter solution templates" as an advantage. The page's benefit and comparison claims are not cited. Read September 6, 2026; the five passages re-verified September 26, 2026. profisee.com/customer-360-what-why-and-how

[2] OpenPeppol, "Peppol BIS Billing 3.0" — the public specification implementing the European standard on electronic invoicing. Cited for business requirements R53 ("the official postal address of the Buyer, Seller and Tax representative of the Supplier and their place of business and registered office") and R57 (identification of up to five parties at invoice level "including their legal name and address"), and only for the fact that one commercial document already requires several distinct addressed parties. Read September 6, 2026; re-verified September 26, 2026. docs.peppol.eu/poacc/billing/3.0/bis

[3] Profisee, "Address Matching and Verification Software" — vendor product documentation. The page's opening line describes the capability as "powered by Melissa Personator," and a later section says Profisee Connect "supports a native service provider integration with Melissa Personator." Cited for the first use case in its FAQ on use cases, e-commerce checkout ("Ensure the shipping and billing addresses a customer enters at checkout match what the postal service has on record"), and for verification running "continuously based on configurable triggers" or only when records are created or updated. Read September 6, 2026; re-verified September 26, 2026. profisee.com/platform/address-matching-verification

[4] Profisee, "MDM Survivorship: How to Choose the Right Record," by Benjamin Bourgeois, October 23, 2025 — vendor documentation of the survivorship techniques the product supports. Cited for the six techniques (source system priority, most recent update, most complete record, data quality score, conditional rules, hybrid approaches); for the recency caution ("requires reliable timestamp metadata across source systems"; "can be thrown off by metadata updates completed in a nightly batch run"); for completeness rules being "best used in combination with other techniques that favor recency"; and for the best practices "Define rules at the attribute-level" and "Involve business stakeholders in rule definition." Read September 6, 2026; re-verified September 26, 2026. profisee.com/blog/mdm-survivorship

[5] Profisee, "Master Data Management (MDM) Implementation Styles, Explained," by Benjamin Bourgeois, February 12, 2024, page states updated August 22, 2026 — vendor explainer. Cited for its definitions of the registry ("Source systems remain the SOR"; "Source systems continue to manage their own data"; "doesn't allow for much control"), consolidation ("Data is not synced back to source systems"; "ideal for business intelligence (BI) and data warehouse use cases"), coexistence and centralized ("typically very difficult to implement") styles. Read September 26, 2026. profisee.com/blog/master-data-management-implementation-styles

[6] Marcel Parciak, Brecht Vandevoort, Frank Neven, Liesbet M. Peeters and Stijn Vansummeren, "Schema Matching with Large Language Models: an Experimental Study," 2nd International Workshop on Tabular Data Analysis (TaDA24), collocated with VLDB 2024; arXiv:2407.11852, July 16, 2024, CC BY 4.0. Cited for the difficulty of the setting ("attribute names are often cryptic and involve domain-specific abbreviations not occurring in thesauri"); the benchmark's shape (nine relation pairs, 1,839 candidate attribute pairs, 49 true matches, "highly imbalanced"); the result that all task scopes except 1-to-1 beat the string-similarity baseline on average "with a maximal increase of 0.245 points" while "no single task scope consistently dominates across all datasets"; the observation that the model "often fails to express an opinion on all attribute pairs requested"; and the authors' statement that in practice "one needs to manually verify the match candidates." Incompletely read, disclosed as such: both HTML renderings retrieved on September 6, 2026 were truncated before the paper's closing Section 4 (Conclusion), which was not read; everything cited comes from the abstract, Sections 1–2 and the per-subsection conclusions of Section 3, read in full. The paper could not be re-retrieved from this workspace on September 26, 2026. It is one benchmark in one domain (MIMIC-IV against OMOP), on two model versions; this article carries over the shape of its result, not its numbers. arxiv.org/abs/2407.11852

[7] Profisee, "Integration | Profisee Platform" — vendor product documentation. Cited for its scope limit ("it is not intended to replace commercial ETL tools for bulk transformations or migrations"); the paired workaround ("Azure Data Factory ships with native pipeline templates to move data in and out of Profisee"); the documented connectivity to Salesforce, Dynamics 365, SAP, Snowflake, Google BigQuery and MuleSoft "through Profisee's REST API and SQL interfaces"; and the offer to "automatically generate and map new master data attributes using AI." Read September 6, 2026; re-verified September 26, 2026. profisee.com/platform/integration

[8] Martin Fowler, "Strangler Fig," martinfowler.com, August 22, 2024. Cited for "Replacements seem easy to specify, but often it's hard to figure out the details of existing behavior. What's worse, much of that behavior is stuff that isn't really wanted, so building it is a waste," and for the transitional architecture the gradual alternative requires and later discards. Read in full September 6, 2026; the quoted sentences re-verified September 26, 2026. martinfowler.com/bliki/StranglerFigApplication.html

[9] Microsoft Learn, "Microsoft Purview and Profisee Master Data Management (MDM)," page states last updated April 3, 2025 — Microsoft's documentation of the partner integration. Cited for "Profisee originated in Microsoft technologies"; "for many years, Profisee MDM was built on Microsoft Master Data Services"; "Profisee MDM is a packaged Kubernetes service"; "Profisee runs natively on Azure Kubernetes Service (AKS) and Azure SQL Database"; the statement that it can be deployed "in your Azure tenant, in any other cloud tenant, or on-premises," or as a service Profisee hosts; and the model being published to Purview "where it can participate in governance." Read September 26, 2026. learn.microsoft.com/en-us/purview/data-governance-master-data-management-profisee

[10] Profisee, "Golden Record Management" — vendor product documentation. Cited for "an ML-powered matching engine"; matching records "displayed side-by-side in a match group for data stewards to review"; stewards choosing "winners" to "survive the merge and be stored in the golden record"; and "Full audit trails are available." Read September 6, 2026; re-verified September 26, 2026. profisee.com/platform/golden-record-management

[11] Profisee, "Sustainable Data Quality Platform | Profisee MDM" — vendor product documentation. Cited only as the observation that contests the source-values-unchallenged rule: a Purview integration "enforcing governance standards and remediating deficient data," and integrations with outside services "for data enrichment and validation." Read September 6, 2026; re-verified September 26, 2026. profisee.com/platform/data-quality

[12] Profisee, support documentation for Address Verification, "Mailing" tab configuration guidance, support.profisee.com — login-gated vendor documentation, not publicly readable and not re-read for this article. Cited from the practice's own record of an authenticated reading on August 22, 2026, which records the guidance as: "Make sure that the source and output for each field item use separate attributes. If you use the same attribute for the source and output data, then Address Verification will overwrite the existing values. For legacy tracking purposes, this is not recommended." A reader without a Profisee account cannot check this entry; the article paraphrases it and rests only its corroborating sentence on it.

[13] Profisee, "Professional Services" — vendor documentation for the FastStart implementation service. Cited for the three published paths: Express, approximately four to six weeks, fixed-scope domain-specific templates, single-domain analytical solutions; Accelerate, approximately twelve weeks, up to two domains; Turn-key, approximately three to six months based on complexity, tailored multi-domain. Cited for what the paths are, never as evidence of speed against any other product. Re-verified September 26, 2026. profisee.com/solutions/professional-services