Design your CRM around the service you sell

Most CRMs arrive with a fixed vocabulary: leads, contacts, accounts, deals. That fits a sales team selling one thing. A service business runs on different nouns — policies and claims, patients and appointments, clients and retainers — and when the CRM doesn't have them, they end up in spreadsheets beside it.

klerc takes the opposite approach. Every workspace starts with two system objects, Person and Company. Everything else, you name. This guide walks through modelling a service business: choosing objects, picking field types, connecting records, letting formulas do the arithmetic and putting the process on a flow.

Start with the nouns you already use#

Before you open settings, list the things your team already tracks — on paper, in spreadsheets, in someone's head. For each one, ask two questions:

1. Does it have its own details? A policy has a number, a premium, an insurer and an expiry date. That makes it an object.
2. Does it move through stages? A claim goes from intimation to assessment to settlement. Those stages belong on a flow over the object, not in a status field.

Anything that's only a label — a lead source, a product type — becomes a field on an existing object rather than an object of its own.

Pick the right field types#

Objects are defined in a visual schema editor: a name, an icon, a colour and a list of fields. There are 28 field types:

Each field can be marked required, unique, indexed or hidden, and select fields carry their own options — they show up as coloured badges in lists and on cards. A few habits pay off later:

• Use currency for money, not number, so totals and reports format themselves.
• Use phone for phone numbers. They're stored with the country code and shown in your organisation's format.
• Use user and team fields for ownership, so assignment, permissions and reports follow the record.

Connect objects with lookups#

A lookup points one record at another: a policy looks up the person who holds it and the insurer that issued it. A lookup-many holds several — a family floater covers more than one person. Lookups are what make the rest of klerc understand your model: a record's page lists its related records, filters can reach across them, and reports can group a claim by its policy's insurer.

Let formulas do the arithmetic#

Formula fields compute a value from other fields. They're written in a Salesforce-compatible formula language, checked when you save them and evaluated when a record is read — so the answer is never stale. A commission that depends on the product type looks like this:

IF(  ISBLANK(premium),  0,  premium * IF(type = "Motor", 0.15, 0.12))

Anything you'd otherwise recalculate in a spreadsheet — a commission, a margin, a days-to-renewal count — is a candidate.

Put the process on a flow#

Once the objects exist, layer a flow over the ones that move. Flows are kanban pipelines with board and table views. Stages can require fields before a card enters them, flows can carry fields of their own, and every stage change is written to the record's history, whether a person or a workflow made it. See Pipelines for the details.

Three worked examples#

An insurance and wealth brokerage#

klerc's demo workspace is a brokerage with 19 objects and 33 flows. Policies look up their holder and their insurer; motor policies look up a vehicle; commissions look up the policy they were earned on. Renewals, claims, endorsements and investor onboarding each run on their own flow, and a telecalling flow moves leads from allocation to a calling queue, a contact attempt and a callback.

A clinic#

A clinic can extend Person with the fields it needs — date of birth, preferred channel, a consent form as a file — and add Appointments, Treatments and Invoices that look up the patient. A treatment plan becomes a flow, with a required field that stops a card moving on until the consent form is attached.

An agency#

An agency extends Company into Clients and adds Projects and Retainers. A retainer carries its value as currency and its owner as a user; projects run on a delivery flow from brief to review to delivered, with the account team set in a team field so the right people see the work.

Bring in what you already have#

Every object and flow has Import / Export. Import a CSV and download the rows that failed; export back out whenever you like. Each record also remembers where it came from — a form, a chatbot, the API or an import — so you can tell the difference later.

Mistakes worth avoiding#

• A select field where you needed an object. If the "type" has details of its own, it's an object.
• The same person in three places. Keep people on Person and point to them with lookups.
• Stages in a status field. You lose required fields, overdue flags and history. Use a flow.

When the model matches the work, everything downstream gets simpler: reports group by the things you care about, workflows act on real fields, and Molly answers questions in your own vocabulary. The objects and fields guide goes deeper on every field type, and Records covers list views, filters and bulk edits. For the module overview, see CRM & Records.