A managing partner asks a question that sounds simple. Which of our clients are growing, and which practice is winning that growth. Two weeks later four analysts have produced three answers, because the billing system counts a client one way, the CRM counts it another, and the practice that thinks it owns the relationship is not the practice the invoice went out under. The firm has all the data. What it does not have is a place where the data agrees with itself. That is the whole problem, and it is an engineering problem with a known shape.
This is written for the operating executive at a firm that sells professional judgment: law, accounting, consulting, engineering, architecture, agency work. Your economics run on people, hours, rates and realization, and your assets are the relationships and the accumulated work product. Almost none of that is queryable today, which means the decisions that move margin are made from anecdote and a monthly export.
Why the data resists you
Professional services firms are not short of systems. Practice management or ERP holds time and billing. A CRM holds pipeline, sometimes accurately. A document management system holds the work product. HR holds the people. There is a resourcing tool, or a spreadsheet doing that job. There is an intake and conflicts system. Each was bought by a different function in a different decade, and each is internally consistent and externally incompatible.
The incompatibility is not cosmetic. It runs on the three things you most need to join.
The client is not one thing. Billing knows a billing entity, which is whoever pays. The CRM knows a company, which is whoever the relationship partner met. The parent group, the subsidiary that signed, and the department that actually asked for the work are three different records with three different names, and the same global client appears eleven times under spellings that differ by a comma. Any question about client concentration, cross-selling or growth requires resolving those into one entity with a hierarchy, and no system you own does that.
The engagement is not one thing either. A matter number, a job code, a project, an opportunity and a contract are five identifiers for overlapping but not identical objects. Work is often billed under a code opened for something else. A phase gets its own code and now looks like a separate engagement. Revenue lands against the code, effort lands against the person, and the relationship between them is a convention that lives in the memory of the billing team.
Time is recorded for billing, not for measurement. Timekeepers write narratives to survive client scrutiny, not to be analyzed. Entries are batched at the end of a week or a month, so the date on the entry is not the date of the work. Non-billable time is recorded inconsistently or not at all, which means your view of how people actually spend the week has a hole in it precisely where the cost is.
What blocks a firm from answering its own questions
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the data almost always exists and cannot be joined.
The model that makes the questions answerable
The platform is a governed warehouse plus a data model that reflects how a services firm actually works. The warehouse part is ordinary engineering. The model is where the value is, and it is worth being specific.
A client entity with a hierarchy. One record per real organization, with parent and subsidiary relationships, and a mapping table that ties every billing entity, CRM account and matter-level client name to it. Resolution is part automated, on normalized names, registration identifiers and domains, and part human, because the last few percent are judgment calls only a partner can make. Build the review queue into the platform on day one; a matching process without a place to record the human decision will re-litigate the same ambiguity every month.
An engagement entity that spans the systems. One record per unit of work sold, carrying the client, the responsible partner, the practice, the fee arrangement, the dates, and a link to every code any system opened for it. This is where the mapping conventions living in someone's head get written down as data.
An effort fact table at the entry grain. One row per time entry, with the person, the engagement, the recorded date, the entered date, the hours, the billing status, the standard rate and the realized rate. Keeping both dates is what makes lag visible. Keeping the entry grain rather than a monthly summary is what lets you answer a question nobody has asked yet.
A revenue fact table that reconciles to the general ledger. Billed, written off, collected, aged, mapped back to engagement and client. Non-negotiable rule: totals tie to the accounts. A platform whose revenue number differs from finance's by any amount is dead, because the first time the CFO spots the gap nobody will use it again.
A people dimension with history. Level, practice, office, cost, start and end dates, and every change kept as a version. Without history, last year's utilization gets recomputed with this year's org structure and the numbers move on their own.
What you can measure once the model exists
The point of the model is that the questions stop being projects. A few that change decisions:
- Profit by engagement, not just revenue. Realized fees minus the cost of the hours actually worked, at the person's cost rather than a blended average. This is where firms find that the largest client is not the most profitable one, and that a practice's flagship engagement type loses money at the current staffing mix.
- Realization decomposed. The gap between standard value and collected cash has four causes: discount agreed at the outset, hours written down before billing, invoice reductions after the client complains, and amounts never collected. They have different owners and different fixes, and a single realization percentage hides all four.
- The staffing mix against outcomes. The ratio of senior to junior hours by engagement type, joined to profitability and to whether the work was delivered on schedule. Firms carry beliefs about the right mix that were true when they were formed and nobody has tested since.
- Client concentration and its trend. Once the hierarchy exists, the real answer to how much of the firm depends on the top ten relationships, including the subsidiaries nobody was counting under the parent.
- Pipeline conversion by origin. Which sources of work convert, at what size, in what time, and which partners' pipeline is a forecast versus a wish list.
- Capacity ahead of demand. Committed work plus weighted pipeline against available hours by skill and level, twelve weeks forward. This is the one that changes hiring decisions.
The work product is the second asset
Everything above uses structured data. The larger and less-touched asset is the work itself: contracts, memoranda, filings, workpapers, models, reports, correspondence. It holds what the firm knows, and it is stored in a system that can find a document by name and nothing else.
Document intelligence over that corpus is now practical, and it starts with unglamorous work. Inventory what exists and where, including the shared drives and the mailboxes, because the document system is never the whole story. Classify by type, because a contract and a workpaper need different handling. Extract structure appropriate to each type: for agreements, the parties, dates, governing terms and the clauses your risk function cares about; for workpapers, the entity, period and conclusion. Store the extractions as data alongside the document, with a link to the exact page and passage each came from.
Two engineering points decide whether this is usable. First, measure the extraction rather than trusting it. Build a labelled evaluation set from documents your professionals have reviewed, and report precision and recall per field. A field that extracts correctly nine times in ten is useful with review and dangerous without, and only the measurement tells you which fields are which. Second, every retrieval answer cites its source passage, and the interface shows the passage next to the answer. A professional will not rely on a system that asserts without showing, and they are right not to.
The confidentiality architecture has to be settled before any of this is built, because it is what your risk committee will ask about. Access follows the same rules as the source system, enforced at query time rather than at ingestion, so a person retrieving from the corpus sees only what they could open directly. Ethical walls are honored as filters that cannot be bypassed by a search path. Client data that carries an outside obligation stays inside your boundary, which in practice means model inference runs in your own cloud account or under a contract with no retention and no training on your inputs. Every one of those is an architecture decision, not a policy sentence, and the difference is whether it holds when someone is in a hurry.
Phasing, so each step pays for itself
The failure pattern is a two-year platform program that delivers nothing until it delivers everything, loses its sponsor in month fourteen, and is quietly wound down. The alternative is a sequence where each phase is independently useful.
| Phase | What gets built | What the firm can do that it could not before |
|---|---|---|
| One | Warehouse, ingestion from billing and finance, client entity resolution with a review queue | One client list with a hierarchy; revenue and concentration that tie to the ledger |
| Two | Engagement model, effort facts at entry grain, people dimension with history | Profitability per engagement at true cost; realization decomposed into its four causes |
| Three | CRM ingestion, pipeline model, forward capacity view | Conversion by source and partner; twelve-week capacity against demand by skill |
| Four | Document inventory, classification, measured extraction with citations | Search across the work product; structured terms out of agreements and workpapers |
| Five | Retrieval and drafting assistance over the governed corpus, with review workflow | Precedent found in minutes; first drafts assembled from the firm's own prior work |
Order matters. Phase four is the one every executive wants to start with, and starting there is how firms end up with an assistant that answers confidently from an ungoverned pile. The document work is far better once the client and engagement entities exist, because then a retrieved document can be filtered by matter, client, practice and date, and those filters are most of what makes retrieval accurate on a real corpus.
What actually goes wrong
Some failure modes are common enough to name.
Building reports before fixing entities. A dashboard on unresolved clients produces numbers that partners can disprove from memory, and one disproof ends adoption. Fix the entities first even though it is the least visible work.
Letting the platform disagree with finance. Reconciliation to the ledger is a build requirement with a test, not a later cleanup.
Treating entity resolution as a one-time job. New clients arrive weekly and the review queue is permanent staffing, usually a fraction of one person, and it has to be assigned to a named role or the model decays within two quarters.
Measuring people before the data is trusted. Publishing individual utilization from a platform whose numbers are still moving turns the population against it. Start with client and engagement views, and reach person-level reporting after the numbers have survived a quarter.
Deploying an assistant without a review step. In a firm that sells judgment, an output nobody signed is a liability. The workflow keeps a named professional accountable, and the system's job is to get them to a reviewed answer faster, not to remove them.
Governance, or the platform stops being believed
A firm's data platform survives on trust, and trust is built by a small number of unglamorous mechanisms. They are worth naming because they are usually the first things cut when a schedule tightens, and cutting them is what turns a working platform into a shelf ornament within a year.
Every metric has one definition, written down, owned by a named person, and implemented once in the transformation layer rather than repeated in each report. Utilization is the example that proves the point: a firm will have four definitions in circulation, differing on whether the denominator is standard hours, available hours net of holiday and leave, or hours the person was actually expected to sell. All four are defensible. Having all four live at once is not, because two reports will disagree and both will be abandoned.
Every transformation is tested. Row counts against the source, revenue totals against the ledger, referential checks that every effort row points to an engagement that exists, and freshness checks that fail loudly when a nightly load did not run. These tests run on every load and their results are visible, so the answer to "is this number current" is a status rather than a guess.
Changes are versioned and announced. When a definition changes, prior periods are restated or explicitly not, and either way it is documented in a place partners can find. Numbers that move without explanation are the fastest way to lose a management committee.
And access is designed rather than inherited. Partner-level views, practice-level views and firm-level views have different audiences and different sensitivities, and reporting on individuals carries employment and, in some jurisdictions, works council implications your own counsel should look at early rather than late.
Where the return shows up first, by phase
Editorial weighting, illustrative rather than measured. The last row is deliberately low: reporting on unresolved entities produces numbers partners can disprove.
A worked example of the arithmetic
To make the profitability point concrete, take an illustrative engagement rather than a real one. A firm bills a fixed fee for a piece of work and records four hundred hours against it. At standard rates those hours would have been worth substantially more than the fee, so the engagement shows a realization shortfall and the practice treats it as a discount problem.
The platform shows something different. Of the four hundred hours, a large share were worked by people two levels more senior than the work required, because the juniors who would normally staff it were committed elsewhere when the engagement started. Priced at those people's actual cost, the engagement is close to breaking even. The problem is not the fee. It is the staffing decision made in a resourcing meeting where nobody could see the profitability consequence, because the tool used in that meeting shows availability and not cost.
That is the recurring shape. Firms mostly do not have a pricing problem in the abstract; they have decisions made without the number attached, in meetings where the number could have been shown. Putting cost-aware profitability into the resourcing view is a small build once the model exists, and it changes behavior in a way no report emailed after month end ever does.
How we work inside your firm
Precision Federal builds and deploys these platforms. We are engineers. We write the pipelines, the model, the resolution logic, the applications and the document systems, and we run them in your environment until your own people are running them.
The first engagement is deliberately narrow. In the first two weeks we inventory the source systems and pull real extracts, and we build the client entity resolution against your actual data rather than against a description of it, because that is where the surprises are. By week four you have a warehouse, a resolved client list with a hierarchy, and a revenue view that ties to your accounts. That is a phase-one outcome and it is useful whether or not you continue. Each subsequent increment carries a written acceptance test agreed before the work starts.
You keep everything. The code is yours, in your repositories, under a written assignment. The warehouse is in your cloud account under your identity provider. Client documents never leave your boundary. There is no platform license from us and nothing that stops working if the engagement ends. Documentation is written for the engineers who will inherit it, and we work alongside them during handover rather than sending a manual.
Pricing is fixed-price milestones where scope is clear, each tied to an acceptance test approved in advance, so you know the cost before work begins and pay for a result. Where the work is genuinely exploratory we use a committed team at a fixed monthly rate. Firms typically start with the first and switch only if they decide they want sustained engineering capacity.
We also build and deploy inside U.S. federal agencies, where systems have to pass authorization to operate, handle controlled unclassified information, meet accessibility conformance, and survive review by people whose job is to find problems. That discipline is why we treat reconciliation, access control and evidence as build requirements rather than later cleanup. For a firm carrying client confidentiality obligations, it is the same posture.
The first step is one email with a one-page brief: your source systems, the question you cannot currently answer, and the deadline that matters. We return a scoped, priced statement of work.
Bottom line
A professional services firm already owns the data to run itself well. What it lacks is a client entity with a hierarchy, an engagement record that spans the systems, effort at the entry grain, revenue that ties to the ledger, and a people dimension with history. Build those five and the questions that used to take four analysts two weeks become queries. Build them before the document work and the document work gets better, because retrieval on a corpus you can filter by client, matter and date is accurate in a way that retrieval on an undifferentiated pile never is. Phase it so each step stands on its own, and the program survives long enough to finish.
Frequently asked questions
A governed warehouse plus a data model that reflects how the firm actually works: one client entity with a parent and subsidiary hierarchy, an engagement record that spans billing, CRM and delivery identifiers, time at the individual entry grain with both the recorded and entered dates, revenue that reconciles to the general ledger, and a people dimension that keeps history. On that foundation sit profitability, realization, utilization, pipeline and capacity views, and later document intelligence over the work product.
Because the questions cross systems. Billing knows a billing entity, the CRM knows a company, and delivery knows a matter or job code, and none of them agree on what a client or an engagement is. The same global client can appear a dozen times under different spellings and through different subsidiaries. Practice management reports accurately on what practice management holds, which is why every cross-system question turns into a manual reconciliation done by analysts each time it is asked.
Partly automatically, on normalized names, registration identifiers, domains and address signals, which handles the large majority. The remainder are judgment calls about corporate structure and relationship ownership that only a partner can make, so the platform includes a review queue where those decisions are recorded and reused. Treat it as continuing work rather than a one-time cleanup, because new clients arrive constantly and an unattended matching model decays within a couple of quarters.
After, in almost every case. Retrieval over a firm's work product is far more accurate when results can be filtered by client, matter, practice, date and responsible partner, and those filters come from the entity and engagement model. Starting with document AI on an ungoverned corpus produces a system that answers confidently from the wrong precedent. The exception is a narrow, well-bounded document task with its own metadata, which can run in parallel.
By making it architecture rather than policy. Enforce access at query time against the same permissions as the source system, so a person retrieves only what they could already open. Honor ethical walls as filters no search path can bypass. Keep client content inside your own boundary, which means inference in your own cloud account or under a contract with no retention and no training on your inputs. Log every retrieval, and cite the source passage in every answer so a professional can verify before relying on it.