A services firm, whether it sells consulting, engineering, design, legal work or implementation, produces three documents for every engagement. A proposal, which prices the work. A project, which records the work. An invoice, which bills the work. They are written by three different people in three different systems, and the unit in all three is time.
Nothing carries the time from one document to the next. The proposal estimated hours; the project consumed hours; the invoice billed a milestone or a month. Whether the engagement made money is the difference between the three, and in most firms of twenty to two hundred people that difference is computed once a year, by the accountant, for the firm as a whole, and never for a project.
This is the mechanism behind the category the software industry calls professional services automation. The category is real. The products are fine. But what a firm actually needs is three joins, and this post is about what breaks without them and what they look like when they exist.
It lives in the CRM, or a proposal tool, or a document. It has a scope, a set of deliverables or phases, an estimate of hours by role, a rate by role and a price, which is either the hours times the rates or a fixed number derived from them with a margin on top. The estimate is the most important number the firm produces, because every later number is measured against it, and in most firms it is never stored as data. It is a table in a document.
It lives in the project tool: Zoho Projects, Jira, Asana, a spreadsheet. It has tasks, assignments, dates and, if the firm is disciplined, timesheets. The hours recorded here are the actual cost of the engagement, at whatever loaded rate each person carries. The project tool does not know the estimate, because the estimate was a table in a document, so it cannot say whether the project is over or under until someone builds a spreadsheet.
It lives in the accounting system. For fixed-price work it bills milestones; for time and materials it bills hours, which someone exports from the project tool and retypes; for retainers it bills a month. The invoice does not know the estimate either, and it knows the actual hours only as an export. So the accounts receivable person is reconciling a document against a spreadsheet against a memory of what was agreed.
Projects that lose money invisibly. A fixed-price project runs twenty percent over the estimated hours. Nobody sees it, because the estimate is in a document and the hours are in the project tool. The invoice goes out for the agreed price and the loss is absorbed into the firm's margin, where it is indistinguishable from every other loss.
Write-downs at invoicing. A time and materials engagement accumulates hours the client did not expect. At invoicing, the partner looks at the number, anticipates the argument and writes the hours down. The firm did the work and chose not to bill it, and the decision left no trace.
Scope creep that is never priced. The client asks for one more thing. The team does it, because the project tool has a place for tasks and no place for the question of whether the task was in the proposal. Three small things later, the project is a different project at the original price.
Utilisation nobody trusts. The project tool reports hours by person. The accounting system reports revenue. Dividing one by the other requires the join that does not exist, so utilisation is computed quarterly in a spreadsheet, and argued about.
Estimates that never improve. The one thing that would make the next proposal better is a comparison between the last estimate and the last actual, by phase and by role. Since neither is data in the same place, the comparison never happens, and the firm estimates the same way it did five years ago.
We saw all five in an IT services firm we worked with, and the first thing that changed when the joins existed was not the software. It was that a partner could see, in the second week, that a project was going to lose money, while there was still time to do something about it.
When the proposal is won, the estimate, by phase and by role, is written into the project as its budget, as data, not as an attachment. This is one join and it is the one that changes everything after it, because from that moment the project tool can compare consumed hours against estimated hours for every phase, every week, and show the partner the projects that are drifting. If your proposal tool cannot hold the estimate as structured data, that is the first thing to fix, and it is usually a small change to the CRM; we have written about what the CRM has to hold for a services firm for exactly this reason.
Approved timesheets and completed milestones flow to the accounting system as draft invoice lines, at the rates on the proposal, without an export. For time and materials, the invoice is the hours; for fixed price, the invoice is the milestone and the hours are the cost behind it; for retainers, the invoice is the month and the hours are the utilisation. Either way, the write-down, when the partner chooses to make one, is a recorded decision on a recorded number rather than a quiet edit to an export.
When the project closes, the actual hours by phase and role, the invoiced amount and the write-downs go back against the original estimate, so that the firm has, for every finished engagement, the estimate, the actual and the gap. That is the data the next proposal should be built from. It is the join firms build last and the one that pays for the longest, because it is how the estimates get better.
Professional services automation products bundle the three documents into one system so that the joins are built in. That is a fair answer for a firm that is willing to move its CRM, its project tool and its billing into one product. Most firms are not, because the CRM is where the sales team lives, the project tool is where the delivery team lives, and the accounting system is where the accountant lives, and each has reasons to keep the tool it knows.
For those firms, the joins can be built between the tools they have. On Zoho, that is the CRM holding the estimate, Projects holding the budget and the timesheets, and Books holding the invoices, with the three joins between them; we have written about how the CRM and Books connect as one of them. On other stacks, the same three joins through different products. The category is the three joins. The product is optional.
A no-risk discovery: a few days to take the last quarter's closed projects, put the estimate, the hours and the invoice side by side for each, and show the partners the margin by project that the firm has never seen. That number decides the conversation. Then a written plan and a guaranteed estimate for the joins in the order above, on the tools you have. We run our own firm on these joins, and every retainer client of ours has a project plan for the same reason: the estimate is the budget, and the budget is visible every week.
A services firm's proposal, project and invoice are three documents about the same hours, and nothing carries the hours between them. The result is projects that lose money invisibly, write-downs that leave no trace and estimates that never improve. Build the three joins: estimate to budget, hours to invoice, actuals back to estimate. The category name does not matter. The joins do.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Behavioral Health CRM: What Breaks Between Intake, Clinical and Billing. (article)
Staff Augmentation vs. Project Outsourcing: Which Model Fits Your Build? (article)
It bundles the three documents a services firm produces for every engagement, the proposal that prices the work, the project that records it and the invoice that bills it, into one system so that hours flow between them. The estimate becomes the project budget, approved timesheets become invoice lines, and actuals close the loop against the estimate. The category is real; the question is whether a firm needs one product or three joins between the tools it already uses.
They need the three joins, not necessarily the product. A PSA suite is a fair answer for a firm willing to move its CRM, project tool and billing into one system. Most firms are not, because the sales team lives in the CRM, delivery lives in the project tool and the accountant lives in the accounting system. For those firms the joins can be built between the tools they have, with the CRM holding the estimate, the project tool the budget and timesheets, and accounting the invoices.
Store the estimate as data, by phase and by role, and write it into the project as its budget when the proposal is won. Record hours against the project at loaded rates. Then compare consumed hours against estimated hours for every phase, every week. That single join lets a partner see in the second week that a project is drifting, while there is still time to act, instead of discovering the loss in the firm's annual margin.
Because the estimate and the actual are never in the same place. The estimate is a table in a proposal document, the hours are in a project tool and the invoice is in accounting, so the comparison by phase and role that would improve the next proposal never happens. The join that closes the loop, writing actual hours, invoiced amount and write-downs back against the original estimate, is the one firms build last and the one that pays for longest.
A decision not to bill hours that were worked, usually made at invoicing when a partner looks at an unexpectedly large time and materials total, anticipates the client's reaction and reduces it. The firm did the work and chose not to charge for it. When the invoice is built from an export, the decision leaves no trace. When invoice lines flow from approved timesheets, a write-down becomes a recorded decision on a recorded number that can be reviewed later.
Only if the project knows what was in the proposal. When the project tool has a place for tasks but no link to the estimate, each extra request is added as a task and done, and three small additions later the project is a different project at the original price. With the estimate written into the project as a budget, a task outside it is visible as unbudgeted work, and the conversation about pricing it happens before the hours are spent rather than after.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
