CRM for engineering and architecture firms
A design firm does not close deals, it wins pursuits: proposals against a submission deadline, often with teaming partners, judged partly on which projects and people the firm can cite. The relationships that generate those pursuits run through individuals — a project manager at a developer, a director at a municipality — who change employers and take the relationship with them. A sales CRM models neither the pursuit nor the person-centred relationship, which is why most firms' CRM is a graveyard of stale opportunities beside a proposal folder that holds the truth.
Where the generic CRM breaks:
An opportunity is not a pursuit. A pursuit has a submission deadline, a go/no-go decision, teaming partners and a proposal to assemble. A CRM opportunity has an amount and a close date. The firm ends up running real pursuits in email and folders while the CRM records fiction.
Relationships follow people, not companies. The client is nominally the developer or the municipality; the relationship is with a person who moves jobs every few years. A company-centred CRM loses the thread at every move, which is exactly when the relationship is most valuable to have tracked.
Experience is not queryable. Every proposal needs relevant projects and available people with the right credentials. When project experience lives in old proposals, each pursuit rebuilds the same qualifications from scratch, and the answer to 'have we done a building like this' depends on who is in the office.
No go/no-go discipline. Firms lose more margin to pursuing the wrong work than to losing the right work. A CRM with no structured go/no-go step records the decision nowhere, so the firm cannot see its own hit rate by client type or project size — the numbers that should drive the decision.
The data model that actually fits:
Pursuit. The proposal effort as its own object: submission deadline, go/no-go record, teaming partners, assigned effort and outcome. This is the object the marketing coordinator actually manages and the one the CRM lacks.
Person-centred relationship. Contacts tracked as individuals with employment history, so when the project manager moves from one developer to another the relationship — and its project history — moves with them.
Project experience record. Completed projects tagged by type, size, role and the staff involved, so qualification pages are assembled by query instead of by archaeology through old proposals.
Teaming history. Which firms you pursued with, in what role, and what happened — because half the pipeline arrives through partners and nobody can currently say which partnerships actually win.
Hit-rate ledger. Outcomes by client, project type and size, feeding the go/no-go decision with the firm's own history instead of optimism.
Our verdict: Configure before building. A generic CRM plus discipline covers person-centred contacts and basic pursuit tracking better than most firms give it credit for, and the professional-services CRMs built for the AEC market are worth evaluating first. The piece that usually justifies custom work is the project experience record wired to pursuits — assembling qualifications from a queryable base — because it touches the firm's own project data and no off-the-shelf tool knows it. Build that only after the pursuit discipline exists, or it will be a well-modelled empty database.
Why do CRM rollouts fail so consistently in design firms?
Because principals win the work and principals do not do data entry. Any system that depends on a principal logging calls is dead in a quarter. The workable design captures pursuits and outcomes — which a coordinator maintains anyway — and treats the principal's relationship knowledge as something to be interviewed out, not typed in.
Is the pipeline metaphor useful at all here?
As a forecast of fee revenue, loosely. As a management tool, less than the deadline list: pursuits due this month, in order, with owners. Firms run on submission dates the way contractors run on pour dates, and the calendar beats the funnel.
Should the CRM connect to project delivery systems?
Lightly, and in one direction. When a pursuit is won, it should become a project record without re-keying; when a project completes, its facts should flow back as experience data. Beyond that, keep delivery in the delivery tools — the CRM is for winning work, not managing it.
What is the first thing to fix if the current CRM is a graveyard?
Shrink it to what will actually be maintained: live pursuits with deadlines and outcomes. A small, true dataset beats a large stale one, and every useful layer — hit rates, experience, teaming history — can only be built on top of records somebody keeps current.
Last reviewed 27 August 2026