Custom CRM discussions often begin after an awkward experience with an existing service. Extra fields, unclear statuses and manual data transfers do not yet establish a need for a new system. The cause may be configuration, a broken connection between services or a genuinely unsupported business rule. Each calls for a different scope of work.
Base the decision on a complete workflow: a customer makes an enquiry, receives the service, payment is confirmed, and staff and the owner can see the outcome. If you are still deciding whether a system is needed, start with the signs that a business needs CRM or ERP instead of spreadsheets and chats. Here we address the next decision: how to implement it.
Describe one workflow from enquiry to delivered service
Consider a hypothetical service business with two rooms, several specialists and a deposit requirement. The customer chooses a time; a manager finds an available specialist and room; confirmed payment moves the booking to the agreed status. Rescheduling releases the old interval and reserves the new one. After delivery, the owner can see completion and the balance due.
A customer record covers only part of this workflow. You need to connect a person, service, time, two resources and payment. A calendar in a CRM feature list does not establish that a specialist or room is protected against double booking. Verify that rule separately.
Separate essentials from preferences. Preventing overlapping bookings and restricting payment access may be essential; card colors and button positions are preferences. Give each essential requirement an owner, starting data and a result for acceptance. Agree rescheduling and cancellation rules first: software should not choose them for the team.
Test ready-made CRM against your scenarios
Select suitable existing options and configure a small example with test data. Check the required plan, roles, modules and integration limits in current documentation. Run the whole journey with someone who will operate the system; a vendor presentation alone does not replace that demonstration.
A useful sequence is to test standard features and configuration, then document remaining gaps. The Microsoft implementation guide recommends that sequence for Dynamics 365. A small service business can apply the principle to its own acceptance table; a specific product still needs to be selected.
| Area | Essential requirement | Acceptance check | Record for the decision |
|---|---|---|---|
| Customer and enquiry | An enquiry has a customer, owner and next action | Accept a new enquiry and a returning customer's enquiry | Configuration works or manual merging remains |
| Specialist and room | Both resources are available for the full service interval | Have two staff members try to confirm overlapping bookings concurrently | A conflict is prevented or separate reservation logic is needed |
| Rescheduling and cancellation | The previous reservation is released and history remains | Reschedule, cancel and check both intervals | The rule is supported, configurable or needs a module |
| Deposit | Confirmation belongs to the correct booking and counts once | Check confirmation, a repeated notification and a refund | An existing connection works or an integration needs reconciliation rules |
| Staff access | Each role sees and changes only permitted data | Open a booking as manager, specialist and owner | Permissions work; exceptions and the required plan are listed |
| Owner report | Bookings, completion and payments remain distinct | Reconcile the report against known test records | A configured report works or a separate calculation is needed |
| Data migration | Required records can be retrieved with their relationships | Export sample customers, bookings and payments and verify their links | Format, limits and migration work are understood |
Add the observed result, a configuration or documentation reference, remaining manual steps and their frequency to every row. “Most requirements covered” is too weak: one unresolved double-booking rule may matter more than several ready reports. An infrequent task that staff can handle safely by hand does not necessarily need immediate automation.
Choose configuration, integration or a custom module
Ready-made CRM satisfies essential rules
Keep the existing product if the configured example passes, staff understand the workflow, and access, export and support conditions suit the business. Implementation includes configuration, data cleaning and migration, training and acceptance. This still takes work, but it does not create a separate software product for you to maintain.
Before paying, establish which features belong to the chosen plan and which cost extra. A small workflow change that preserves essential rules may be more reasonable than reproducing every old habit in new code.
An integration can close a specific gap
Suppose the CRM handles customers and manager tasks well, while a specialist booking service already reserves rooms and staff correctly. Evaluate exchanging the enquiry, booking status and confirmed payment between them. Customer history need not be replaced simply because scheduling lives elsewhere.
Define the authoritative source for each record: CRM for the customer, the booking service for reservations and the payment system for payment confirmation. Agree identifiers, update direction, cancellation handling and an error queue. “Has an API” does not establish access to the required fields, events, permissions or request volume.
The connection should withstand repeated messages and temporary failures. For example, Stripe documentation describes duplicate event delivery and the absence of an ordering guarantee. This illustrates exchange reliability requirements rather than recommending a payment provider. Check the chosen systems' own conditions and the case where a receiver processed an event but failed to return a response.
A custom module implements an essential missing rule
In our example, a module may be justified if evaluated options cannot reserve a specialist and room together, and manual reconciliation repeatedly disrupts work. The development scope is the specific scheduling rule, including roles, rescheduling and cancellation. Customer records and accounting can remain in existing products.
Discuss full replacement when the gap affects the core data model and most connected operations, and a limited extension creates more duplication and maintenance. Base this choice on test results and cost comparisons. If the difficulty is only an awkward screen, evaluate a different interface or product first.
Compare ownership costs over the same period
A CRM subscription and the price of a first custom version are not comparable without the same scope of work. Use one planning horizon, such as two years, and one assumed load: staff numbers, bookings and integrations. Request estimates for each viable option without assuming that custom software will be cheaper.
- Initial work: process discovery, configuration or development, data cleaning and migration, integration checks and training.
- Recurring costs: licenses and modules, servers, messages, maintenance, backups and monitoring of data exchange.
- Changes and exit: revised business rules, external API updates, another integration and migration to a different supplier.
- Remaining manual work: staff time spent reconciling records, correcting errors and handling tasks outside the automation scope.
Separate committed costs, estimates with assumptions and unresolved amounts. For example, estimate reconciliation effort as monthly operation count × average time per operation × an agreed hourly cost. This measures the burden; savings arise only if the selected solution actually reduces it.
Agree who maintains the integration, restores data and accepts changes after launch. For custom software, establish access to code, infrastructure and documentation; for an existing product, establish export and subscription termination conditions. The GDS technology purchasing guide considers costs across the product lifecycle. Here it informs cost comparison rather than prescribing terms for your contract.
Launch a first version with a verifiable outcome
For the hypothetical service, a first version could cover enquiry through confirmed booking and recorded deposit. Define roles, required fields, reservation rules, rescheduling, cancellation, reporting and selected integrations. Loyalty programs or complex network planning can be considered later if they are unnecessary for that journey.
Acceptance should cover a normal booking, conflicting bookings, rescheduling, cancellation, a repeated payment notification and an unavailable external service. Check each role's permissions, export a linked data sample and restore a test backup. For transition, name the person who reconciles migrated records and define how the team continues working if launch encounters a problem.
If a custom module is selected, the guide to a limited CRM and ERP first version helps define its boundaries. Evaluate AI features inside the system once data, permissions and statuses work: a customer summary cannot repair an incorrect room reservation.
The decision should produce confirmed requirements, remaining gaps, costs and named operational owners. Use ready-made CRM when it passes essential checks. Commission a specific connection or rule when that is what is missing, with clear acceptance conditions. The automation scope then follows the workflow the business needs to run.
Practical decision checklist
- Define one workflow and separate essential rules from preferences.
- Test configuration, conflicts, payments, roles and linked data export.
- Document each remaining gap and evaluate a limited integration or module.
- Compare the same cost horizon and agree acceptance, support and transition.
Sources and methodology
The following references support the facts and technical details in this article:
Define the first useful automation
We will map one workflow, its data, roles and integrations and define a first version around your team's work.
Review the workflow and choose the automation scope