The tool was built for a different company
CRM software assumes a sales organization: people whose whole job is selling, who are measured on activity, and for whom keeping the system current is the work, not an interruption to it.
Architecture and engineering firms don’t work that way. Principals sell between projects. Their time is billable, or it’s spent with a client. For them, updating a record has no immediate return. It helps somebody’s report next quarter, and that isn’t reason enough on a day with a deadline in it.
The adoption spiral
The system launches with training and real intent. Entry is patchy from the start, because it’s nobody’s priority in their busiest week. Within a quarter, the pipeline report holds records that are stale, duplicated or missing outcomes. Leadership notices the report doesn’t match reality and stops relying on it.
That’s the turning point. Once leadership stops using the report, the last outside reason to keep the data current disappears, and entry drops further. A year or two later, the verdict is that the CRM was the wrong choice. A replacement is picked, and the cycle starts again with different software and the same conditions.
What it looks like from the inside
Here’s what stale looks like in practice. At an MEP engineering firm in Southern California, proposals lived in the CRM, and follow-up depended on someone remembering to do it, then remembering to log it.
The firm had a CRM. What it lacked was a reason for busy people to keep it current.
What actually went wrong
It asked for input and gave nothing back. The people entering the data weren’t the people getting value from it. Any system shaped like that decays.
It stored history instead of producing instructions. A record that a proposal went out in March is a fact. It isn’t a prompt. Nothing told a principal what to do on Tuesday morning, so the system wasn’t part of anyone’s Tuesday morning.
Nobody owned the data as a job. Upkeep was spread across people who all had something more urgent to do, which means it belonged to no one.
Completeness was mistaken for usefulness. Required fields get added to improve data quality, which makes entry slower, which means less entry. The fields were designed for the report, not for the person filling them in.
What changes the outcome
Reverse the exchange. Before the system asks a principal for anything, it should give them something: a short, ranked list of what needs attention this week, with the context already assembled. Value first, entry second.
Make updates a by-product of the work. If sending the follow-up produces the record, entry stops being a chore. If entry is its own chore, it will lose to billable work every time.
Make the report worth trusting. Leadership using the report is the only lasting reason the rest of the firm keeps it current. That means closing pursuits that are unresolved, instead of leaving them open to flatter the number.
In the pilot, that meant a Monday priority list, follow-ups prepared for the owner to send, and a Friday report checked against the CRM. In week one, follow-up dates were recorded on 6 proposals, and 4 of 8 priority contacts showed a CRM update. By Oct 16, $71,000 had been recovered across 8 won proposals, and the $416,500 still open across 25 proposals was visible on one page. None of it required a new CRM.
Before you replace it
The useful question isn’t which CRM is best for engineering firms. It’s what a principal would get from the system in the first thirty seconds of opening it that would make opening it worth doing again tomorrow.
If there’s no answer to that, new software will reproduce the same result, at the cost of another migration. If there is an answer, the system you already have is probably enough.
Riftmark works with the CRM or spreadsheet you already use. See how the weekly rhythm runs.