Why your CRM and your BI should share the job's data core

Ask a contractor’s leadership team three questions: how much work are we chasing, how much of it do we usually win, and how much margin did the work we won actually make? You’ll usually get three answers from three systems. The pipeline lives in a CRM or a spreadsheet owned by business development. The jobs live in project management and accounting. The answers to “how are we doing” live in a BI tool that someone refreshes from exports.

Each answer is defensible on its own. Put them side by side and they rarely tie out. The pursuit was $48.2M in the CRM, the contract is a different number in accounting, and the dashboard shows whatever was exported last Thursday.

Three systems, three versions of the customer

The CRM knows the owner’s rep, the architect, the referral and the probability someone typed in at the site visit. The project system knows the contract, the change orders and the people who actually showed up to the OAC meetings. The BI model knows whatever columns survived the export.

None of them is wrong. They just aren’t the same record, so every question that crosses them needs a person to stitch them together:

• Did repeat customers really win at a higher rate? Only if someone matched CRM accounts to accounting customers by hand.
• Which lead sources turn into profitable work? Only if the opportunity, the job and the final margin can be lined up row by row.
• Is the pipeline big enough to replace the backlog we’re burning? Only if the backlog and the pipeline were refreshed on the same day.

The stitching is where time goes and where trust leaks. When two reports disagree, the meeting becomes about whose spreadsheet is right.

One record from first call to last pay app

The alternative is boring on purpose: keep the pursuit, the project and the report on one data model. The opportunity record that business development creates is the record that moves onto the job when it’s won. Analytics doesn’t import it. It reads it.

Sample data · CRM to project to analytics

1. CRMRiverside Medical Center pursuit$48.2M opportunity, owner and architect linked, marked Won
2. ProjectJob #24-118Same contacts, same opportunity IDs. Nothing re-keyed.
3. AnalyticsWin rate, pipeline, marginRead from the same rows, filtered to what each person may see

In os.construction that’s how CRM and Analytics are built today, both in preview:

• CRM is its own module in the app, with apps for the pipeline, contacts, follow-ups, website inquiries, organizations and people, import and export. A won pursuit is reviewed into a new project, or attached to an existing one, keeping its IDs and history. Nothing is re-keyed.
• Analytics reads the same rows. A CRM & Pipeline pack shows pipeline value, weighted pipeline, win rate, average deal size, sales cycle and lead conversion, next to more than 230 metrics for projects, financials, field, safety and preconstruction.
• Definitions live once. Win rate is won ÷ (won + lost) everywhere it appears, not one formula in the CRM and another in a workbook. Sales cycle counts only wins whose stage change was actually recorded, rather than guessing at old ones.

Permissions don’t survive an export

There’s a second reason to keep BI on the data core, and it matters more than speed: access.

Once pipeline and job data are exported into a BI model, the permissions that protected them are gone. Either a few people get the dashboard and everyone else asks them for numbers, or the dashboard quietly shows more than it should. Pipeline values, proposal prices and bid results are exactly the numbers you don’t want leaking across the company, or to a subcontractor’s staff.

When the dashboard runs as the viewer, that problem disappears. In os.construction every Analytics tile runs with the viewer’s own permissions: company intake pursuits need a CRM grant, project CRM follows each project’s permissions, private records stay private row by row, and a number you can’t read is blank rather than zero. Because granting Analytics never exposes extra rows, it can be turned on for everyone. Every user now has it, read-only by default.

What changes on Monday morning

• Business development and operations look at the same pipeline. The PM who’ll run the job sees the pursuit the estimator priced, not a summary in an email.
• Leadership asks better questions. “Win rate by source” and “weighted pipeline by stage” are one click on the CRM & Pipeline pack, split by owner or month, with every number drilling to the opportunities behind it.
• Nobody refreshes the dashboard. Move a pursuit to Won and the win rate moves with it.

There’s more to do. Setting each pursuit’s win beside the margin the job actually earned is the obvious next question, and it isn’t in the product yet. But that question is only answerable at all when the pursuit and the job were never two records to begin with.

Read the CRM guide and the Analytics BI guide, or see Construction CRM and Insights.