B2B SaaS company serving professional firms
We are building account tiers in Salesforce, scored from the company's own history
A B2B SaaS company serving professional firms wanted one scored database of every customer and target prospect. We built it in the company's own Azure: clean master records first, a language model only filling and checking attributes, scores from its own history.
B2B SoftwareScored customer and prospect databaseModernized a live product
- Who uses it
- Sales and marketing, inside Salesforce
- Sources
- CRM, billing, product usage, calls, firmographics
- Scores go to
- Salesforce, where sellers already work
- Runs in
- The company's own Azure SQL and Microsoft Fabric
The challenge
The same account sits in the CRM, billing, product usage, call and firmographic systems with conflicting values, so sales and marketing cannot see which accounts look like the best customers.
What we did
Survivorship rules first, master layers in Azure SQL, Fabric once matching held, then LLM enrichment and tiered scores on the company's own history, written back to Salesforce.
The outcome
The scored database is being built in the company's environment: one master record per account, enriched attributes and tiers in Salesforce, and every layer documented for the internal team.
The starting point
The client sells software to professional firms, and its sales and marketing teams work from Salesforce. Customer and prospect data also sits in billing, product usage, call recording and third party firmographic sources.
What had to change
The client wants one scored database of every current customer and target prospect, so sales and marketing can see which accounts look like its best customers. Today the same account appears in several systems with conflicting values.
What could not break
- Everything is built in the company's own Azure and Fabric environment; it owns the platform
- Every layer is documented so the internal team can run and extend it
- The language model fills and checks attributes; it never decides which accounts are best
- Scores rest on the client's own retention, expansion and deal velocity signals
- Sellers keep working in Salesforce, so scores and tiers have to arrive there
The calls we made
We framed enrichment and scoring as only as good as the merged master record underneath them, so the order of work is clean data first, AI second.
- 01
Survivorship rules before anything else
When two systems disagree, someone has to decide which one wins, and every later layer inherits that decision. Our first questions were which sources feed the database first and whether such rules already exist.
Ruled outEnriching or scoring records before they are merged.
- 02
Azure SQL first, Fabric once matching is solid
The master account, contact and activity layers were designed in Azure SQL, and Microsoft Fabric came in after entity resolution held, so the lakehouse and semantic models start from resolved records.
- 03
The LLM fills and checks, the history decides
A language model fills and validates firm size, practice areas, geography and tech stack, but scores rest on the client's own retention, expansion and deal velocity signals.
Ruled outA generic fit score.
- 04
Reports on the governed model
Power BI reporting sits on the governed semantic model, so every report reads the same merged accounts and the same scores.
Ruled outSide exports that each describe the accounts differently.
- 05
Scores where sellers already work
Scores, tiers and enriched attributes flow back into Salesforce, so prioritizing accounts is part of daily selling without a new tool.
How the system fits together
What we built
Master data layers
Master account, contact and activity layers in Azure SQL, fed by ingestion pipelines from the CRM, billing, product usage, call and firmographic sources.
Entity resolution
Match, merge and survivorship rules to decide which source wins when two systems disagree, so each account becomes one master record.
LLM assisted enrichment
A Python pipeline that calls a language model to fill, standardize and validate firm size, practice areas, geography and tech stack on the merged records.
Scoring, tiers and write back
A scoring model with Ideal, Emerging, Acceptable and Avoid tiers, set with go to market stakeholders, whose scores and enriched attributes go back into Salesforce.
How it works
Ingest
Data arrives from the CRM, billing, product usage, call and firmographic sources.
Resolve
Matching and survivorship rules merge each account into one master record.
Enrich
The language model fills and checks missing firmographic attributes.
Score
Accounts are scored and tiered on the client's own customer history.
Activate
Scores, tiers and attributes flow back into Salesforce and governed Power BI reports.
A closer look
What changed
The build is under way in the company's environment, layer by layer. Each account resolves to one master record, a language model fills and checks its attributes, and Ideal, Emerging, Acceptable and Avoid tiers based on the company's own history are being written back to Salesforce, where sellers already work.
Under the hood
- Datics role
- Engineering delivered by Datics
- Data boundary
- Everything runs in the company's own Azure SQL and Microsoft Fabric environment; the company owns the platform.
- Integrations
- Salesforce read and write back, billing, product usage, call data and firmographic sources, with Fivetran ingestion and Power BI reporting.
- AI boundary
- The language model fills, standardizes and validates attributes; scores rest on the company's own historical performance signals.
- Platform
- Azure SQL for the master layers, then Microsoft Fabric with Data Factory, a lakehouse and semantic models, and a Claude or Azure OpenAI API for enrichment.
Data and retrieval
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Sources and survivorship
First we agreed which sources feed the database first, how clean they are, and which source wins when two disagree.
Master layers and resolution
We built the account, contact and activity layers in Azure SQL, with ingestion pipelines and match and merge rules.
Fabric, enrichment and scoring
Microsoft Fabric came in once resolution held, then the enrichment pipeline and the tiered scoring model.
Activation and handoff
Scores and attributes went into Salesforce, reporting moved onto the governed model, and every documented layer was handed to the internal team.
In the company's own environment
We built in the company's Azure and Fabric environment, in step with its business systems and data team, so nothing runs on a platform it does not own.
Built to be handed over
Every layer was documented so the internal team can run and extend it.
What this unlocked
With scores in Salesforce and reporting on the governed model, the internal team owns a documented foundation it can extend.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.