--- title: PSA, CRM or all-in-one: which does a services firm actually need? canonical: https://getcyril.com/blog/psa-crm-or-all-in-one/ published: 2026-10-12 author: Cyril team language: en --- # PSA, CRM or all-in-one: which does a services firm actually need? A services firm sells expertise and delivers it as time. That makes its software question different from a product company's. The money is made or lost in the gap between what was sold and what it took to deliver it, and that gap runs straight through the middle of two software categories. Three kinds of product get pitched to firms like this: a CRM, a professional services automation (PSA) tool, and an all-in-one business platform. Their feature lists overlap enough to be confusing. They answer different questions. ## Three categories, in a sentence each - **A CRM** manages the relationship and the sale: who the client is, what you have discussed, what is in the pipeline and what is likely to close. - **PSA** manages delivery as a business: who is working on what, how many hours it took, whether the engagement is on budget, what can be billed and what margin it made. - **An all-in-one business platform** runs sales, delivery, billing, and usually support and documents, on one data model instead of several products joined by connectors. The first two are specialists that meet at the signature. The third is an argument that the signature should not be a seam at all. ## What a CRM does: everything before the signature A CRM is built around the pipeline. It holds companies and contacts, every email and meeting with them, the opportunities you are working, the stage each one has reached and the value you expect it to bring. Its reports are forward-looking: what will close this quarter, which deals have stalled, where proposals go quiet. What a CRM is not built to know is what happens once the deal is won. It does not know who will deliver the work, how many hours the team has logged against it, whether the fixed fee is being eaten by overruns, or what has been invoiced. Most CRMs will let you add fields for some of this. Fields are not a model of delivery, and the person keeping them current is usually not the person doing the work. For a firm with a small team, one practice and simple engagements, a CRM plus a spreadsheet and an invoicing tool can work for a long time. The trouble starts when the spreadsheet becomes the system of record for anything that matters. ## What PSA does: everything after it Professional services automation exists because firms that sell hours need to manage hours the way a manufacturer manages stock. A PSA tool typically covers: - **Resourcing.** Who is available, with which skills, in which week, and who is overbooked. In larger firms this extends to bench forecasting: which people roll off engagements soon with nothing lined up. - **Time.** Timesheets against projects and tasks, with approval, so hours become billable or written-off deliberately rather than by default. - **Budgets.** Hours and fees planned against hours and fees spent, so an overrun is visible in week three rather than in the final invoice. - **Billing.** Time and materials, fixed fee, milestones and retainers, turned into invoices from the approved time. - **Margin and utilisation.** Bill rate against cost rate per person and per engagement, and how much of each consultant's available time was billable. What PSA is usually thinner on is everything before delivery starts. Many PSA tools assume the engagement already exists, so the pipeline either lives in a separate CRM or in a lighter module bolted onto the delivery tool. Either way, the record of what was promised sits apart from the record of what is being delivered. ## What an all-in-one business platform does An all-in-one platform treats the deal, the project, the invoice, the support ticket and the client's documents as records in one system with one data model. The closed deal can open the project, the project's time and budget sit next to the scope that was sold, and the invoice is drafted from what was agreed rather than re-typed from it. The trade is breadth against depth. A platform module will rarely match a specialist that has spent a decade on one function. The question is whether you need that depth, or whether you need the specialist's function done well enough and the seams gone. For a concrete picture of the two seams that matter most to a services firm, see [what a CRM with project management looks like on one graph](/product/crm-with-projects/) and [a CRM whose invoices read straight from the deal](/product/crm-with-invoicing/). ## The cost of the seams Every pairing of separate tools has a handover, and the handovers are where services firms lose money quietly. - **Deal to project.** The scope, rates, team and deadline are agreed in the CRM and re-entered in the delivery tool, often by someone who was not in the room. The kickoff meeting exists partly to re-read the deal aloud. - **Project to invoice.** Approved time and milestones move to finance through an export, a sync or a person. Each one is a place where a billable hour goes missing or a client is billed twice. - **The client, three times.** The CRM, the PSA tool and the finance system each hold their own version of the client, and the versions drift. None of this arrives as an invoice, which is why it is rarely priced. We built an open model of it in [the integration tax](/blog/the-integration-tax/): at its default assumptions, five separate tools cost a 40-person business about $110,000 a year, and the licences are under a third of that. The rest is connective software, the time spent maintaining the seams, reconciliation, and AI add-ons that can each see one silo. [The comparison of one platform against five tools](/compare/five-tools/) walks through what changes line by line, including where five tools are the better answer, and you can [run the same model on your own numbers](/tools/integration-tax/). A firm running a CRM plus a PSA tool has fewer seams than one running five tools. It still has the most expensive one: the handover between what was sold and what is delivered. ## Which fits at which size and complexity Headcount is a weak guide on its own. A 30-person firm running 60 concurrent engagements across three countries has a harder resourcing problem than a 120-person firm on four long retainers. Read the bands below as rough shapes, not thresholds. | Firm shape | What usually fits | Why | |---|---|---| | Up to about 15 people, one practice, simple engagements | An all-in-one platform, or a CRM plus invoicing | Resourcing fits in one person's head, so the main risk is building seams you do not need yet | | 15 to 75 people, several practices, deal-to-delivery handovers every week | An all-in-one platform, or a CRM plus PSA with a maintained integration | The handover is now the expensive seam, and someone has to own it either way | | 75 to 250 people with a large bookable pool and utilisation targets | A dedicated PSA, usually alongside a CRM | Scheduling and utilisation across the pool become a daily planning job | | Several hundred people, multiple entities, revenue recognition schedules | A dedicated PSA alongside an ERP | The depth needed in delivery and finance outweighs the cost of the seams | ## When a dedicated PSA is the better choice This deserves a straight answer, because the honest case for a specialist is strong in some firms. - **Utilisation is the business model.** If a large pool of consultants is billed by the hour and a few points of utilisation decide the year, you need tooling built around utilisation reporting and bench forecasting. - **Resource planning is a daily job.** Skills-based scheduling across many concurrent engagements, tentative bookings against pipeline, and levelling across a portfolio are core PSA strengths and are hard to approximate. - **Finance needs depth in delivery data.** Revenue recognition schedules, multi-entity consolidation and inter-company billing push toward a PSA paired with a proper ERP. Cyril is an all-in-one platform, so here is where it stands against that list. Projects carry time, budgets, Gantt and rate cards with bill and cost rates, so each project shows its margin, and invoices draft from the deal. But Cyril has no utilisation or bench planning across a large consultant pool: treat that as absent. Resource levelling and capacity planning across a portfolio are not something to plan around today, it is not a general ledger, and deferred revenue schedules are not covered. If any of those is your core need, keep or buy the specialist. [The management consulting page](/solutions/management-consulting/) says the same thing in its section on where the shape does not fit. ## A decision checklist Answer each question yes or no. 1. Does the same person both win work and deliver it? 2. Is the handover from deal to project a meeting rather than a link? 3. Do you re-key scope, rates or line items from one system into another? 4. Do you find out an engagement is over budget only when you invoice it? 5. Does anyone spend part of every week maintaining integrations between your tools? 6. Do you need to know which client accounts are at risk, using pipeline, delivery and billing together? 7. Are more than a few dozen consultants billed against utilisation targets? 8. Do you schedule people by skill across many concurrent engagements each week? 9. Do you need revenue recognition schedules or multi-entity consolidation? 10. Is a specialist tool already doing one of these jobs well, with stable integrations someone owns? Mostly yes to 1 to 6 and no to 7 to 10: the seams are your main cost, and an all-in-one platform is worth a serious look. Yes to 7, 8 or 9: a dedicated PSA belongs in your stack, whatever sits around it. Yes to 10: the integration cost is already paid, and changing now pays it again as a migration. ## Common questions ### What is the difference between PSA and CRM? A CRM manages clients and the sale: contacts, pipeline, proposals and forecasts of what will close. PSA manages delivery as a business: resourcing, time, budgets, billing, utilisation and margin. They meet at the signed engagement, which is why the handover between them matters so much. ### Can a CRM do the job of a PSA tool? Only partly. Custom fields can record some delivery data, but a CRM has no model of timesheets, resource availability, budget burn or bill and cost rates. Firms that stretch a CRM this way usually end up running delivery in spreadsheets beside it. ### Do we need PSA if we already have a project management tool? Not necessarily. A project tool tracks tasks and deadlines. PSA adds the commercial layer: hours against budget, billable against non-billable time, and margin. If you bill by the hour or need margin per engagement, that layer has to live somewhere. ### Is an all-in-one platform just a weaker version of each tool? In a specialist function, often yes, and it is fair to say so. What it gives in return is one record of the client and no seams between sale, delivery and billing. Whether that is the better trade depends on whether depth or the seams are costing you more. ### When should a firm outgrow a CRM plus spreadsheets? Usually when the spreadsheet becomes the place where budgets, time or billing are decided, and when two people keep separate versions of it. That is the point where the seams start costing more than the software you are avoiding. --- If you want to be among the first to use Cyril, [join the waitlist](/waitlist/).