Vertical Platform or Generic CRM?

Start with the lifecycle of a job, order, asset, or case. If most complexity lies in scheduling, fulfillment, inspections, inventory, or recurring work, a generic CRM may be a useful front door but an incomplete operating system.

Draw the lifecycle

List every state from inquiry through closeout and the records that change at each step. Mark actions that currently happen outside the CRM.

Test the exception path

Ask how the system handles rescheduling, partial delivery, damaged assets, multiple sites, or a disputed completion. A product demo built only on the happy path is not enough.

Keep customer context connected

The operator should see the relevant customer and site history without creating a second uncontrolled copy of the same account data.

Demonstrate the work after the sale

Ask each vendor to process a real sequence from inquiry through scheduling, field work, exception, billing, and closeout. Require a change midstream: a customer moves the appointment, a needed asset is unavailable, or the work is only partly complete. Watch where staff leave the product, copy data, or invent a status to fit the screen. A CRM may be excellent for relationships and pipeline yet weak at work orders; a vertical product may run operations while offering limited account history. The demonstration should show the boundary and handoff, not hide it.

Prepare a scripted demonstration from one real customer lifecycle. Give vendors the same starting records and ask them to process a new opportunity, a scheduled job, a changed site contact, a partial completion, and a reopened issue. Record every place where the user copies an identifier or leaves the system. Ask for the exported records after the demo so data ownership is visible. A vendor that can explain how those changes propagate between CRM and operations is giving more useful evidence than one that shows a long list of configurable fields. Keep the script for later acceptance testing.

Make the record ownership explicit

Decide which system creates the customer, site, job, equipment, and invoice identifiers. Map the fields that travel between systems and the event that causes each update. Test a corrected address, merged customer, reopened job, and failed sync because these cases expose duplicate ownership. Ask for export examples and API limits before signing a long contract. A clear integration model lets staff trust a single answer for each task while preserving the customer context needed across the lifecycle. It also gives the team a way to detect when the two systems disagree.

Decision checklist

• Choose one real workflow to demonstrate end to end.
• Identify records the CRM should own.
• Measure manual handoffs and duplicate entry.
• Check whether the vertical system can export its data.

A small test before committing

Run a complete real job through the current CRM and one proposed operating model: inquiry, scheduling, changed scope, completion evidence, billing handoff, and customer history. Count each spreadsheet, message, and rekeyed field. If the CRM can represent the exception with controlled configuration and clear ownership, it may remain central. If operations continue outside it, define the system that owns job state and how customer context will stay connected.

Worked scenario

A hypothetical maintenance company may use CRM for opportunities while work orders, equipment history, technician assignments, and completion records belong in an operational platform. The handoff between them becomes a design task, not an afterthought.

For a scoped application of this decision, see Industry Platforms.