Can't we get the same result by adding custom fields to a packaged CRM?

You cannot, once the field has to fire a rule. A custom field carries information; it does not draw down a credit, move a calendar or send a file with a device. Pilatesco holds the rule for which cancellation returns a credit, so the balance changes by rule and not by a field somebody fills in. When you add a field in the demo, watch whether anything else moves; if nothing does, the field stores a fact and your staff still does the work.

If we move from a packaged CRM to a custom one, what happens to the data we already hold?

It moves, column by column. Fields somebody typed, such as names and phone numbers, cross over as they are. Anything the packaged product never held is not filled in for the past; that field starts on cutover day, and earlier rows stay flagged as pre-cutover. The dental clinic CRM had no earlier plan step for past appointments to attach to, because the old booking tool never held one. Export your packaged product's data before the demo and write beside each column what it carries.

Does a custom CRM mean a large system?

It does not; what gets specific is which information the system keeps separately, not the infrastructure under it. The dental clinic CRM stands on two components, an application that runs the workflow and a database holding patients, plans and invoices. What was written for the clinic was not a new stack but an appointment attached to a step of a plan. Read the CRM service page for the items saying what each piece of information hangs off.

What goes into the first release of a custom CRM, and what can wait?

The information you do not keep yet goes in, together with its link; screens can wait. For the clinic that meant the plan step and the appointment attached to it. Invoices and reports are not built as separate features, because they are read off information already held. The dental clinic CRM was built around tying a procedure to a tooth and a session. Sort your list into lines that need new information and lines that read what you already keep.

Why would a company that writes custom CRMs tell me a packaged one is enough?

We would, because we are also the team building a configurable booking product. AlgoRandevu is not live yet, and it keeps slot length and the way bookings stack as product settings instead of code, so we are drawing a packaged product's boundary with our own hands. Telling you that a contact card and a calendar carry your work costs that team nothing. Put what the demo showed you next to the items on the CRM service page.

Packaged CRM or custom CRM: what to look at in the demo

Packaged CRM or custom CRM comes down to one thing you can see in a demo: does what you track appear as a record of its own, or only as a notes field? Where a contact list and a calendar carry your work, the packaged product is the right answer. The dental clinic CRM books an appointment against a step of the patient's plan, and a reordered plan pulls the calendar with it.

A packaged CRM demo is convincing. The screens are familiar, setup takes an afternoon, and a contact card opens in the first minute. This page is not here to talk you out of it; we are building a configurable booking product ourselves, and that work is where we learned how far a packaged product goes. What to watch for is one detail of the demo: the thing your business tracks either appears on screen as a record of its own, or it appears as a notes field or an extra field on a contact. A record means the packaged product carries your work. A notes field means somebody on your staff carries it.

What a settings screen cannot do

A settings screen lets you add a field, rename a label and switch a workflow on or off. It leaves untouched what the product keeps as a unit of its own: whatever it counted before the demo, it still counts afterwards. Which of the two a business needs is decided right there, and our article on packaged versus custom software makes that case at length.

At the clinic the mismatch showed up in the calendar. The booking tool held the hour but not where the patient stood in the treatment plan, so the plan was reconstructed from the calendar by hand and whatever fell between went into somebody’s notebook. What you look for in the demo is therefore not a feature list but an example from your own business.

The business for which a packaged CRM is the right answer

A contact card, a phone number, the note from the last call and a calendar: if that is what your work runs on, a packaged CRM is the right answer and this page is not sending you anywhere else. If your appointment hangs off an hour and a person, you sell by the session, and history sits under the person, then the record you saw in the demo is your record. Writing a custom one there buys you nothing except a second system to maintain.

We hold ourselves to the same test. AlgoRandevu is under construction here, and the length of a slot, what a booking is held against and how bookings follow one another stay as settings inside the product rather than being fixed to one trade, so that a clinic, a salon and a workshop can each set it up under their own rule. That work also teaches where a setting stops. A setting absorbs the differences between rules that resemble each other; it cannot hold two things that differ at the root under one template, which is the limit set out in keeping appointments and service requests apart. If what your appointments are booked against differs that much, say a room for one request and an installed unit for the next, what you need is a separate intake flow.

Three places to look in the demo

Ask for the demo to be run on an example from your own business, then look at these three places.

What the appointment is attached to. If your work has a stepped plan, a treatment plan, a maintenance plan, a course schedule, look at whether the appointment in the demo attaches to that plan. In the dental clinic CRM the plan is drawn per tooth and broken into sessions, and an appointment opens against one of those steps; reorder the steps and the calendar shifts with them. If the demo attaches the appointment to an hour and puts the step in a notes field, the person correcting the calendar after every plan change will be you.

Whether a field you add fires a rule. Adding a custom field to a packaged CRM is easy; the question is whether the field changes anything. At Pilatesco a member buys a package rather than a single class: a booking takes a credit off the balance, a cancellation and a no-show post to it in different ways, and which of them returns the credit is written in the rule. You can add a field called “credits left” in the demo. If a booking does not reduce it by itself and a cancellation does not restore it, the arithmetic is still being done by a person.

What the history sits under. If one customer has several devices, several files or several members, look at whether history sits on the contact card or under the device. In AlgoKlima the warranty, the service visits and the fault reports live in the device’s own file; three units at one address are three files, and a unit sold on takes its file to the new owner. If the demo shows the device as an extra field on the contact, three devices will share one history, and when one is sold the history stays with the previous owner.

Custom CRM has a limit too

Custom does not mean large. The dental clinic CRM stands on two components: an application that runs the workflow and a database holding the patient, the plan, the appointment and the invoice. What became specific for the clinic was which information the system keeps separately; the infrastructure under it is shared with most of our other work.

The other end of the limit is the first release. You do not have to put every screen in on day one, and which features belong in the first release draws the line between the information itself and the output read off it. A report screen can wait, because a report is read off information already held rather than built beside it. If you are leaving a packaged product, what you hold does not vanish either: moving a spreadsheet-run process into software walks column by column through what crosses over as it is and what starts fresh on cutover day.

The table below sorts the criteria into the two things a demo can show you: if what you track appears on screen as a record of its own, the packaged product carries your work; if it appears only as a note or an extra field, somebody is keeping that information by hand on your behalf. Keep the table open during the demo, then run the same rows against us: the CRM page lists what each piece of information hangs off and the projects each item rests on.

Side by side

Criterion	What the demo shows as a record of its own	What the demo shows only as a note or an extra field
What an appointment is attached to	The appointment hangs off an hour and a person; your work has nothing called a plan, and the packaged product carries that.	The appointment has to hang off a step of a plan; the demo puts the step in a notes field, so a changed plan leaves the calendar where it was.
The credit drawn from a package	You sell by the session; nobody holds a balance and nothing has to be drawn down.	A booking has to take a credit off a package balance, and a cancellation and a no-show have to post differently; the demo keeps the balance as a number someone edits.
What the history sits under	History sits under the person and that is enough; one file per customer describes your work.	History has to sit under the device, and a device that changes hands has to take its file along; the demo adds the device as an extra field on the contact.
The capacity rule	One hour takes one person; a calendar alone can hold that rule.	How many people an hour takes is set by the instructor, the equipment and the slot together; the demo reduces it to a fixed number field.
Where the invoice and the report come from	Invoices are raised in another program and the CRM holds only the contact and the call notes; that split costs you nothing.	The invoice has to come off the patient or customer record, and the month-end report has to be that record read from another angle; the demo stores an invoice number in a notes field.
What your custom field actually does	The field carries a piece of information and changes nothing else: a tag, a phone number, a lead source.	The field has to fire a rule: take the credit, move the calendar, send the file with the device. A settings screen adds the field, not the rule.

Questions this decision raises

Can't we get the same result by adding custom fields to a packaged CRM?

You cannot, once the field has to fire a rule. A custom field carries information; it does not draw down a credit, move a calendar or send a file with a device. Pilatesco holds the rule for which cancellation returns a credit, so the balance changes by rule and not by a field somebody fills in. When you add a field in the demo, watch whether anything else moves; if nothing does, the field stores a fact and your staff still does the work.
If we move from a packaged CRM to a custom one, what happens to the data we already hold?

It moves, column by column. Fields somebody typed, such as names and phone numbers, cross over as they are. Anything the packaged product never held is not filled in for the past; that field starts on cutover day, and earlier rows stay flagged as pre-cutover. The dental clinic CRM had no earlier plan step for past appointments to attach to, because the old booking tool never held one. Export your packaged product's data before the demo and write beside each column what it carries.
Does a custom CRM mean a large system?

It does not; what gets specific is which information the system keeps separately, not the infrastructure under it. The dental clinic CRM stands on two components, an application that runs the workflow and a database holding patients, plans and invoices. What was written for the clinic was not a new stack but an appointment attached to a step of a plan. Read the CRM service page for the items saying what each piece of information hangs off.
What goes into the first release of a custom CRM, and what can wait?

The information you do not keep yet goes in, together with its link; screens can wait. For the clinic that meant the plan step and the appointment attached to it. Invoices and reports are not built as separate features, because they are read off information already held. The dental clinic CRM was built around tying a procedure to a tooth and a session. Sort your list into lines that need new information and lines that read what you already keep.
Why would a company that writes custom CRMs tell me a packaged one is enough?

We would, because we are also the team building a configurable booking product. AlgoRandevu is not live yet, and it keeps slot length and the way bookings stack as product settings instead of code, so we are drawing a packaged product's boundary with our own hands. Telling you that a contact card and a calendar carry your work costs that team nothing. Put what the demo showed you next to the items on the CRM service page.