You are paying per seat for a CRM that models somebody else's sales process. Half of it does not apply, the half you need does not quite fit, and the delivery data that would tell you what a customer is genuinely worth lives in a different system entirely.
Replace our CRM with something that fits how we actually sell.
Mainstream CRM is genuinely good software for the sales motion it was designed around: a repeatable, transactional pipeline with defined stages and comparable deals. If that is how you sell, use it — a bespoke CRM would be a poor use of money.
The friction appears when your sale is not that. Long consultative cycles, bids and frameworks, multi-party deals, tenders with their own gates, or anything where the qualification questions are specific to your industry, all end up expressed as custom fields bolted onto a model that assumes something different. Adoption suffers, because the system is asking questions that do not match the conversation the salesperson just had.
The deeper problem is the boundary. A CRM stops at the closed deal, so everything about how the work actually went — delivery, support, renewals, the cost of serving a customer — sits in another system. That means the most valuable question you could ask, which customers are actually worth having, is one nobody can answer without a data project.
Contacts, organisations, opportunities and activities as linked datastores using your stages, your qualification fields and your rules. If your pipeline has a bid/no-bid gate, a framework qualification and a clarification round, that is what the system has, rather than a stage called "Proposal" that everyone silently reinterprets.
Inbound e-mail is fetched and filed against the right record automatically, so the activity timeline reflects what happened rather than what someone logged. Workflows handle the process around the sale — approvals on discounts, handover to delivery, renewal chasing — and scheduled tasks chase what has gone quiet.
The part that off-the-shelf cannot do is the one that pays for it: because delivery, support and invoicing can live in the same application, a customer record shows the whole relationship. Sales, delivery and revenue on one record means margin per customer is a report rather than a project.
Your stages, your gates and your qualification fields, agreed with the people who sell rather than inherited from a template. This is a conversation about how you sell, and it is worth having properly — most CRM adoption failures are really this conversation never happening.
Inbound e-mail fetched automatically and filed against the matching contact or opportunity, including attachments. A timeline built from what happened beats one built from what people remembered to log.
Discount approval as an authorisation step, handover to delivery as a workflow stage rather than a conversation, and renewal dates watched by scheduled tasks instead of by memory.
Because the delivery, support or project side can be the same application, the customer record carries the whole relationship — including the parts that determine whether the customer was profitable.
Pipeline by stage, conversion by source, ageing, forecast and margin per customer, built in the report builder and put on dashboards. The spreadsheet export stops being the reporting layer.
Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.
| Feature | What it does | Why it matters here |
|---|---|---|
| Datastores & 40+ field types | Your own entities and fields — linked dropdowns, AJAX search, conditional fields, dates, currency. | Your qualification questions, in your language. This is most of why adoption succeeds or fails. |
| Inbox processing | Inbound e-mail fetched automatically and passed, with attachments, to extraction or a custom function. | The activity history stops depending on salespeople logging things after the fact. |
| Workflows & electronic authorisation | Multi-stage processes with e-mailed approve/decline links. | Discount approval and handover become steps in the system rather than favours asked over Teams. |
| Reports & dashboards | A builder that joins related tables automatically, with graphs and dashboard elements. | Pipeline reporting without the export-to-spreadsheet step that every CRM conversation eventually reaches. |
| No per-seat licensing | Users are an operational decision, not a purchasing one. | Everyone who should see the customer can, including delivery and support — which is exactly the visibility per-seat pricing discourages. |
| API engine | Permission-aware endpoints with token-based clients and call logging. | Marketing automation, your website and your finance system all need to reach this. An API that respects the same permissions is the safe way to let them. |
The pipeline model and one team using it against live opportunities. Sales teams tell you very quickly and very clearly when a field is wrong.
E-mail capture, approvals, reporting, and the join to whatever happens after the deal closes.
Stages, fields and reports are configuration. Sales processes change more often than most software allows for, which is much of the argument for building it this way.
Often not, and we will say so. If your pipeline is transactional and repeatable, mainstream CRM fits it well and is excellent value. The case for building is when your sale genuinely does not fit that shape, or when the answer you need spans sales and delivery.
Yes. The Data Import System handles files with field mapping and translation, and the Update Existing method means a load can be re-run after corrections without creating duplicates.
Yes. Inbound mail is fetched over IMAP, Microsoft Graph or SES and filed against the matching record, attachments included, so the timeline reflects what actually happened.
There is no per-seat licence. That changes behaviour more than it sounds: delivery, support and finance can all see the customer, because letting them is no longer a purchasing decision.
Yes, through the API engine, linked external databases and datastore sync — with the same permission rules as the interface rather than a back door around them.
Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.