CRM is short for customer relationship management, and in software it names the system holding the record of a relationship with a customer. What that record must hold is set by which side of the sale carries the relationship’s weight, not by the industry. Diotek starts recording a relationship before any unit is chosen, while at the dental clinic the substance of the relationship comes after treatment begins.
What CRM stands for
A note before anything else. The same abbreviation also names a crew communication course in aviation, which is why pages from an unrelated field turn up next to this one in search results. What follows is about software.
The expansion points at something narrower than it first sounds. What gets managed is not the customer. It is the relationship you have with that customer. A contact list holds a phone number; it does not hold what you discussed with the person behind that number last month. That is the line between an address book and a CRM: the address book tells you who to call, while a CRM also tells you what was done with that customer and what is still outstanding.
Saying “customer information” is not enough to describe a piece of software, because it never says which information. A CRM holds the answers to a short set of questions as they accumulate: who spoke to whom, what was asked for, what was delivered, and what happens next. Until the subject of the record is named, the definition stays half finished.
That accumulation faces backwards and forwards at the same time. The backward face is easy to grasp, because keeping records already sounds like writing down what happened. The forward face is the one that gets dropped. If the work still waiting does not sit on the record, the record turns into an archive, and nobody opens an archive in the middle of a working day. You can tell whether a CRM is genuinely in use by when people touch it: at the start of the day, or at the end of it as a chore.
The word doing quiet work in that expansion is management. What gets managed is not the relationship itself but the order the relationship needs to keep going: who is waiting, who is owed a reply, what stands in front of which job. Where that order is written down nowhere, the loudest customer gets served fastest.
It is worth naming what a CRM does not hold. It is not a ledger, not a stock count, not a production schedule. Pulling in information that has nothing to do with the relationship makes the record unreadable. The scoping question is therefore never “what else can we add” but “which information is attached to the relationship”.
What a CRM does on an ordinary working day
The practical effect of a CRM during a working day is that it changes who gets asked. When a customer rings, does the person answering turn to the room and ask what happened last time, or do they open the record and read it? That is where the software either earns its keep or does not.
Someone who opens a customer sees the history and the outstanding work on the same screen. What was requested, what was carried out and what comes next sit beside each other. The information no longer lives in the head of whoever remembers it. The bill for that difference comes due when somebody takes leave, when a week gets crowded, or when staff change: if the person who remembers is away from their desk, so is the knowledge.
There is a quieter effect underneath. When several people deal with the same customer, whoever picks the conversation up next does not have to ask what happened last, because the record sits under the customer rather than under the colleague who handled it. If the person who sold the work is not the person who delivers it, that alone changes the day.
Information reaches a CRM from notes your team types in, and from records the work itself produces: appointments, requests, invoices. The difference between those sources matters. A typed note can simply be forgotten, while a record the workflow produces comes into being as the work is done and does not depend on anybody’s discipline. How trustworthy a CRM turns out to be mostly tracks how much of its content the workflow produced on its own.
The real question starts here. Which records a workflow produces varies from business to business. A clinic that books appointments and a ventilation firm that surveys sites cannot run on the same screens, because their work does not generate the same records. Past this point the answer to what a CRM is stops being a description of a product.
The question that settles it: does the relationship live before the sale or after it
The habit when shopping for software is to type an industry into the search box: clinic CRM, field service CRM, estate agency CRM. An industry name is a hint rather than a decision, because the weight of the work can sit in different places inside the same industry. The question that carries the decision is this: does the weight of the relationship you have with a customer live before the sale or after it?
Diotek sits on the earlier side. In air conditioning, what equipment will do the job depends on the space, so somebody has to see the place before anybody quotes. There is therefore a record to be kept while no product has been sold at all, and the thing keeping it is a CRM.
The dental clinic sits on the later side. Dental treatment does not end when the first appointment does. The plan is drawn tooth by tooth, sessions spread across weeks, and the whole thing gets revised along the way. Here the heart of the relationship begins once the work does, and what the CRM is asked for is not a date but a position: how far along the job has got.
So the same abbreviation means unlike systems in these businesses. In the earlier case the record’s main job is to describe work that has not happened yet. In the later case it is to hold where work already under way has reached. The feature lists may look alike; the subject of the record is not the same.
This neighbours the question of separating request types without being the same question. Which flow a request belongs to, and where that separation actually lives, is the subject of a separate piece on survey bookings and service requests. The question here sits further upstream: relative to the sale, where is the record born?
There is a quick way to test it in your own business. Is your longest conversation with a customer the one before money changes hands, or the one after? If the answer is “before”, what your record has to hold is a request. If it is “after”, it has to hold a history. If the answer does not point cleanly in a single direction, you are asking a sequencing question, which the closing section comes back to.
Before the sale, the record holds something that does not exist yet
The defining property of a pre-sale record is that the thing it attaches to does not exist yet. There is no part number, no serial number, no installed machine. A record still has to be opened, because the relationship has already begun.
At Diotek someone asks for a date against an address before anything has been chosen. The survey record hangs on a place to be visited and a requested time rather than on a product, because the visit is what settles which equipment will do. The survey cannot move onto the website, and it never could: capacity is only settled by standing in the room. What travels through the site is the request alone. Where the line between self-service and in-person work falls is measured in a separate piece on pre-sale steps.
What gets lost on this side is not the customer. It is the record. At Diotek intake does not hang on the phone line, so a visitor who reaches the site while the line is busy still leaves something in writing. When intake depends on a single channel, a request is lost before anyone sees it. On the pre-sale side a CRM’s first job is therefore not to maintain a customer card. It is to get the request into writing.
Even a business that sells once and never again has a record worth keeping. That record is not a customer’s history; it is a request not yet answered. Without a queue of requests, priority gets set by how loudly each caller asks.
Calculator Resterm shows the same side from another angle. What goes in is not a catalogue code but the heating requirement of the job itself; the engineering sizing happens inside the application, which answers with the electric heater that fits. The product name is the output of the record rather than its input. Which means the relationship is written down before any product has been settled.
The consequence on the CRM side is plain. Because every Resterm project is held against the customer it was drawn up for, a customer record exists before any quote has been written. A customer record is born out of a request, not out of a sale. How a selection binds to a cart, a cart to a project and a project to a customer is covered in a separate piece on turning a calculation into a quote; the part that counts here is not the chain but the moment the record comes into being.
What a pre-sale record holds is not the decision but the request leading to a decision. That is why records on this side close: the survey happens, the quote goes out, the request turns into a decision. Their lives are short, and for the whole of that life they have to stand up unsupported, because there is nothing behind them to lean on.
After the sale, the record hangs on something already in place
After the sale the arrangement inverts. The thing a record attaches to is already there, and the record hangs underneath it.
In the dental clinic CRM that thing is a named tooth and the plan drawn for it. The plan records which procedure goes where, ordered into sessions that run across weeks. It stands apart from the calendar, which means it can be read without looking at any booking at all. An appointment attaches to it rather than standing in for it.
Because the record hangs on something that exists, it thickens over time. Sessions get added, the plan gets revised, procedures carried out get written down. The general-purpose booking software the clinic ran before held the hour and not the position in the plan. There was a record; there was no link. The thing worth naming here is the gap: what was being kept was a time, not a relationship.
AlgoKlima shows this side more sharply. Service history hangs on the machine rather than on the customer card: warranty status, the maintenance already carried out and every fault opened against it gather under that unit. Units at the same address keep their files apart. When a unit is sold on, its history goes with it instead of being retyped onto the new owner’s card. AlgoKlima, our own product, is live and still being extended.
The lesson is that a post-sale record does not always hang on the customer. Whichever object carries the weight of the relationship is the object the record opens against. When ownership changes, the party to the relationship changes while the record stays put. Hanging everything on the customer is the easy-looking route; if the same customer has several files, the shortcut comes back as histories that run into each other.
And where a pre-sale record closes by turning into a decision, a post-sale record does not close at all. As plan steps are added and jobs are opened against a machine, the same record keeps filling up underneath. What a CRM has to survive on this side is therefore different: the record has to stay readable years later, and whoever reads it probably will not be whoever wrote it.
Where the record is born relative to the sale
The rows here come from our own work. Read the table as a list of industries and the argument disappears; the column carrying the argument is the one asking whether the thing a record attaches to already exists when the record opens.
| Build | Which side of the sale carries the relationship | Does the thing the record attaches to already exist | What the record has to hold |
|---|---|---|---|
| Diotek | Before the sale | No: nothing has been picked out, and there is a space waiting to be seen | Getting the request into writing, and carrying which flow it belongs to |
| Calculator Resterm | Before the sale | No: the input is a heating requirement, and the calculation picks the product | Keeping the requirement, the heater it selects and the customer on the same chain |
| Dental clinic CRM | After the sale | Yes: a named tooth and the ordered sessions planned for it | Where in the treatment the patient stands |
| Pilatesco | At the sale and after it | Yes: a package already sold, with credits not yet used | The credit left between the moment of sale and weeks of usage |
| AlgoKlima | After the sale | Yes: a specific unit installed at an address | Warranty, maintenance and fault history staying with the unit |
Put side by side, the thing each record attaches to comes out different every time: a room, a heating requirement, a tooth, a package already paid for, a unit installed at an address. What produces the difference is not the sector but where the record is born relative to the sale. That is also what puts a clinic and a field service firm in the same column; businesses with nothing in common share a record behaviour.
The column asking whether the object exists yields something you can act on. On the rows reading no, a record’s first duty is not to lose the request. On the rows reading yes, its first duty is to hang history on the right object. If you can place your own business by reading that column, you have an answer before the conversation about screens even starts.
Before and after the sale meet in the same customer record
Up to here the distinction can read like a choice: the earlier side, or the later one. It is not. Before and after the sale are not separate systems but different arms of the same customer record.
Pilatesco shows it most clearly. An invoice comes out the moment a package changes hands, while the credits get used up over the weeks that follow. The sale happens at a point in time; the usage happens over a stretch of it. Those differently timed records land on the same customer record, and what the CRM holds is neither the sales document nor the calendar: it is the credit left between them.
The remaining credits ride on the customer record too, instead of a notebook kept beside the calendar. So the record on the later side of the sale is born out of a transaction on the earlier side. What each case does to that balance, though, is a rule definition rather than a CRM record; writing down during setup how a cancellation, a no-show and an attended class post to the balance belongs to the management software side of the work.
Diotek operates on the earlier side and the later side at once. Requests arriving through its site face before the sale on the survey end, and after installation on the maintenance and fault end. The same company has to keep records on each side of its own sale. How those flows get separated is the subject of the article linked above; the relevant fact here is that before and after the sale can sit inside the same business.
In practice this means the choice is not exclusive. Which side carries the weight sets the order of construction; it does not delete the other side. Whichever side gets built first comes out in more detail, and the side arriving later rides on the same customer record. The fear of picking the wrong side is therefore larger than it needs to be: what you pick is not a system but a starting point.
Which record gets defined first
Everything so far has been diagnosis. This part is about what you do next. When a CRM is set up, the record defined first is the record carrying the weight of the relationship, and everything else rides on top of it.
The dental clinic was built in that order: the treatment plan was defined first, and appointments were attached to its steps afterwards. Build it the other way round and you get a full calendar with an empty plan behind it. A calendar knows when work happened. It does not know where the work stands.
At AlgoKlima the record defined first is not even the customer. Because history belongs to the machine rather than the person, the spine of the system became the machine itself, and the customer attaches to it as its current owner. The rule holds across jobs: whichever object carries the weight of the relationship is the object the record opens against.
At Diotek the order shifts again. What opens from the site is not a sale but a request in writing; the request travels its own path to operations and the record stops depending on a phone note. In a business weighted towards the pre-sale side, the record defined first is the request, and the customer card follows behind it.
Explaining that decision to a development team is a skill of its own. Setting down what a stored line actually stands for gets you further than listing screens, which is the subject of a separate piece on describing what you need.
The question queued up behind all this is whether to run on a packaged product or have something built. This article does not settle that, and it cannot. We take that question up in a guide comparing packaged and custom CRM.
What you gain here is not the decision but the question you walk into it holding. If you want to see which information sits under which record, the CRM page lists them line by line, and every line comes from a build rather than a feature list.
