Concord CRM is good at the thing it set out to do. Deals move through a pipeline, contacts and companies stay tidy, activities get logged, and the whole thing runs on your own server with no per-seat bill. Then a deal closes, and you leave the CRM to do everything that follows.
That gap is the subject of this post. Full disclosure before we go further: we build and sell the modules described here, so treat this as an inventory of what is possible rather than a neutral market survey. The useful part is not the product list - it is the pattern of which gaps are worth closing inside the CRM and which are not.
The shape of the gap
A sales CRM ends at "won". A business does not. The work that follows a closed deal splits into four fairly predictable areas:
| Area | The question it answers |
|---|---|
| Billing | How do we get paid for what we just sold? |
| Books | What did that revenue actually cost us? |
| People | Who did the work, and what are we paying them? |
| Stock | Do we have the thing we sold, and where is it? |
Every one of these has an excellent standalone SaaS answer. The reason to do them inside the CRM instead is not features - a dedicated accounting package will always have more. It is that the alternative means a synchronisation problem forever: two systems with two copies of every client, drifting apart in ways nobody notices until an invoice goes to a customer's old address.
Billing: closing the loop on a won deal
The first thing most Concord installs need is invoicing, because the gap is so visible. A deal reaches "won" and the CRM's involvement ends, while somebody opens a separate tool, retypes the client, and raises the invoice by hand.
The invoicing module puts that inside the deal workflow: raise an invoice from the deal, collect payment online, and let the deal advance on its own when the payment lands. The detail that matters is the last one. An invoice that updates the pipeline means the pipeline stays true without anybody maintaining it, and "paid" stops being something a person has to remember to record.
Books: the layer under the invoices
Invoicing tells you what you billed. It does not tell you what you earned. The accounting and bookkeeping module adds the layer underneath: chart of accounts, journal entries, expenses, vendor bills, payments, bank accounts, bank transaction import and reconciliation, budgets, multi-currency, and financial reports.
This is the module to think hardest about before installing, because it has the strongest external competition. The honest test is whether your accountant needs to be in the system. If they do, a dedicated package they already know may win on their comfort alone. If bookkeeping is something you do so that you know where you stand, and your accountant only ever sees exports, then keeping the ledger next to the revenue that generated it is a real simplification.
People: the workforce behind the deals
The HR module covers the workforce lifecycle - onboarding, departments, leave tracking, attendance, timesheet approvals, and payroll with payslip generation.
The argument for putting HR in the CRM is weaker than the argument for billing, and it is worth being clear about why: HR data has almost no overlap with sales data. What it does share is people. If your staff already sign in to Concord every day, adding leave requests and timesheets there means one system, one login, one set of permissions - and for a team under about thirty people that convenience usually beats the feature depth of a separate HR platform.
Stock and procurement: for anyone selling a physical thing
If what you sell has to exist somewhere before you can ship it, two more modules apply. Inventory management handles warehouses, stock levels and work in progress; purchase management handles procurement and supplier billing on the way in.
These are the most conditional items on the list. A services business should skip them entirely. A business selling goods will find the CRM is otherwise lying to it, because a pipeline that does not know what is in stock will happily let somebody sell something that is not there.
The different one: selling Concord itself
The SaaS module is not an extension of your operations - it changes what your business is. It turns a single Concord installation into a multi-tenant platform with automated tenant provisioning, subscription management and usage quotas, so you sell workspaces rather than use one.
That is a different company with different problems: support, uptime, billing disputes and churn all become yours. It is a real path and people do it successfully, but it deserves its own decision rather than a place on a shopping list.
How to decide
The trap is treating this as a menu. Every module you install is code you carry through every Concord upgrade, so the question is never "would this be useful" - almost anything would be. The question is whether the alternative is worse.
Three questions settle most cases:
- Is the data already in the CRM? Invoicing wins easily, because the client, the deal and the amount are all there already. HR wins by less, because it shares only the people.
- Would the alternative mean syncing? Two systems holding the same customer records will drift. If the answer is yes, the integrated option is usually right even when it is the weaker product.
- Who else has to use it? A tool your accountant or your warehouse staff live in every day should be chosen for them, not for you.
Start with the module that closes the loop on work you already do daily. For most Concord installations that is invoicing, and it is worth seeing whether a self-maintaining pipeline changes anything before adding a second.
Top comments (0)