Most ERP software was designed around a manufacturing or distribution mental model: purchase raw materials, produce or stock goods, sell them, ship them. Systems integrators and managed service providers don't run that business — they sell, install and support infrastructure they often don't own, spread across many customer sites, billed partly on project delivery and partly on recurring support contracts. Applying a generic ERP to that shape of business leaves real gaps. Here's what actually needs to be different.
The core mismatch: "inventory" isn't the end of the story
In a generic ERP, a sold item leaves inventory and the transaction is essentially closed — revenue recognized, stock decremented, done. For a systems integrator, selling and installing a router, an access point, or a server is the start of an ongoing relationship: that asset needs a warranty record, a service history, and a link to whichever support contract covers it, potentially for years. If your ERP's data model ends at "sold," you lose the ability to answer "what's installed at this customer's site, and what's covered" — which is the first question every support call needs answered.
What actually needs to be different
1. Assets need a life after the sale. A serialised item shouldn't stop being tracked once it's invoiced — it needs to continue as a customer-installed asset with warranty, install date and ongoing service history, tied to the account and to whichever support contract covers it.
2. Support and delivery need to run as one operation, not three. New deployments (sales), support tickets against existing infrastructure, and field service (installs, maintenance) are often treated as separate systems in a generic ERP-plus-helpdesk-plus-field-service-app stack. For an MSP, these need to share the same account and asset data, because a ticket about a specific site's infrastructure is meaningless without knowing what's actually installed there.
3. Multi-site accounts need to be first-class, not fragmented. An enterprise customer with infrastructure across twelve locations shouldn't be twelve separate account records — but it also can't be flattened into one record that loses per-site SLA and asset detail. This is a specific data modeling problem generic ERPs, built around single-location customers, often don't solve well.
4. Contract coverage needs to be queryable at the point of a support call. When a ticket opens against a specific site, the system should already know which support contract and SLA apply — not require someone to check a spreadsheet before responding. Contract-to-asset-to-site linkage has to be structural, not a manual lookup step.
5. Billing needs to handle both project and recurring revenue models cleanly. MSPs typically run project-based billing (a new deployment) and recurring contract billing (ongoing support) side by side for the same customer. A generic ERP built primarily around one-off sales invoicing often handles the recurring side as an awkward workaround rather than a native model.
6. Break-fix and scheduled maintenance need to share infrastructure, not duplicate it. Reactive support (a ticket) and proactive maintenance (a scheduled AMC visit) are different triggers for the same underlying dispatch, mobile execution and reporting workflow — building them as two separate systems duplicates effort and fragments the data.
What the data-model gap looks like in practice
Illustrative scenario, not a real customer.
Copperline Systems (fictional systems integrator, 14 enterprise accounts, ~2,100 installed assets across client sites) ran a generic ERP for three years before the multi-site/asset gap became too expensive to work around:
| Question a support call needs answered | Generic ERP (sold items, no post-sale asset life) | Purpose-built data model |
|---|---|---|
| "What's installed at Site B of this 12-location account, and is it under warranty?" | Manual lookup across install notes/email threads — ~15 min per call | Instant — asset record carries site, warranty, contract |
| "Which SLA applies to this specific ticket?" | Guessed from account tier, sometimes wrong | Queried directly from contract-to-asset link |
| Split between project billing and recurring support billing | Recurring handled as a manual monthly workaround | Native — same account, two billing models |
| Engineer time lost per week reconstructing "what's at this site" | Estimated 4–6 hours across the team | Close to zero |
At 14 accounts this was annoying but survivable. Copperline's own estimate once they mapped it: the lookup time alone was costing roughly one full engineer-day a week across the team — before counting the SLA misses that came from guessing instead of knowing.
Why this matters more as you scale
At a handful of customers, these gaps are annoying but survivable with manual workarounds and institutional memory. Past a certain size — dozens of multi-site accounts, hundreds of installed assets, several engineers in the field — the manual workarounds stop scaling, and the cost shows up as slower support response, missed AMC renewals, and under-billed field work.
What this looks like in DexVee
DexVee's asset tracking, contract-linked support and field service tooling were built by reflecting how eNeoteric Consultancy Services — the systems integrator behind DexVee — actually runs its own multi-site, contract-driven operation, not from a theoretical spec. If your business looks more like ticket-driven IT support than infrastructure installation specifically, see our breakdown for IT Services & Support Companies, which covers the same underlying idea from a helpdesk/AMC-support angle.
If you're running a systems integration or MSP business on a generic ERP today, the friction you're feeling in support handoffs and AMC tracking usually isn't a training problem — it's a data-model mismatch that a purpose-built platform actually solves.