What should a chemical distributor track that a CRM does not?

How does a CRM differ from a technical customer record?

A CRM and a technical customer record differ in the question each answers: the CRM answers "where is this deal and who do we talk to", while the technical customer record answers "what is running at this customer, under which conditions, and what have we told them about it". A CRM is organized around accounts, contacts and opportunities. A technical customer record is organized around the customer's sites and equipment, so that every product, measurement, visit finding and document sent hangs on a place where something is actually used. Contacts are the one item both need, so link them instead of keeping two copies.

The table below decides where each customer item belongs.

The row that creates legal work is the last one: in the EU, an updated safety data sheet has to reach every customer supplied in the preceding 12 months (Regulation 1907/2006, Article 31), so the list of who received which revision has to exist somewhere.

Why does a CRM miss a customer's technical history?

A CRM misses a customer's technical history because it is built to record sales interactions with an account, not technical facts about the places where the customer uses a product. Salesforce, a CRM vendor, describes CRM as a system that "helps businesses and their employees manage interactions with customers and prospects to improve relationships, streamline processes, and drive growth" (Salesforce, 2026). The same page lists what such systems store: contact information, sales opportunities, service issues and marketing campaigns.

A chemical maker's own description shows the same shape. WACKER's 2018 sustainability report says its CRM "contains customer profiles and all other relevant information about our customers" and supports correspondence, business opportunities and sample processing, with complaints "tracked until our final reply has been sent to the customer" (WACKER, 2018). Nothing in that list is a site condition, a product running in a given machine or a measured value.

The gap is structural, which suggests custom fields rarely close it. A CRM note is dated by the conversation and attached to an account or a deal. A technical fact needs a site, a piece of equipment, a unit and a measurement date, and it needs to stay comparable with the same fact recorded a year later. In call notes, that history has to be rebuilt by rereading every note.

Which site conditions should you record for each customer?

The site conditions to record for each customer are the ones that change how your product performs or whether its use is covered by the safety data sheet: what the product touches, the temperatures it sees, what it is mixed with, and what the customer uses it for. Fix the site and equipment identity first, then attach every condition to that identity, not to the account as a whole.

A practical minimum per site or piece of equipment:

• Process and use: what the product does there, in the customer's own words and in your category.

• Materials in contact: metals, elastomers, coatings, substrates.

• Operating range: temperature, pressure or speed, each with a unit and how it was obtained.

• Inputs: make-up water, other chemicals in the same system, known contaminants.

• Date measured and source: your measurement, the customer's reading, or a nameplate value.

Use matters for compliance as well as for product fit. Under REACH, a downstream user may make its use known in writing to its supplier so that it can become an identified use, and distributors "shall pass on such information to the next actor or distributor up the supply chain" (Regulation 1907/2006, Article 37). A customer whose use falls outside the exposure scenario in its safety data sheet must prepare its own chemical safety report unless an exemption applies (Regulation 1907/2006, Article 37). A recorded use per site is what lets you see that before the customer's auditor does.

How do you record which products each customer uses?

You record which products each customer uses by listing each product against the site and equipment where it runs, using the product identifier printed on its safety data sheet, with a start date and a status. An order history tells you what was billed to an account; a products-in-use list tells you what is in which machine today.

Record four things per entry:

1. Product identifier exactly as it appears on the safety data sheet, plus grade or variant.

2. Site and equipment where it is used, using the customer's own asset tag when one exists.

3. Start date, and the product it replaced, if any.

4. Status: in use, on trial or stopped, with the date the status changed.

Using the safety data sheet identifier is not a style choice. Under the US Hazard Communication Standard, the customer's written program must include a list of hazardous chemicals known to be present "using a product identifier that is referenced on the appropriate safety data sheet", and that list may be kept for the workplace or for individual work areas (OSHA, 29 CFR 1910.1200, 2026). The same standard requires the employer to keep a safety data sheet for each hazardous chemical in the workplace, readily accessible during each work shift (OSHA, 29 CFR 1910.1200, 2026). When your list uses the same identifier, you can tell at a glance which sheet each work area should hold.

What should a visit record hold that a CRM activity note does not?

A visit record should hold what you observed and measured at a named site, how it compares with the last visit, and what was agreed, while a CRM activity note usually holds only who met whom, when and what it means for the deal. The difference is whether the next person can act on it without calling you.

Use this checklist for each visit record:

• Date in an unambiguous format. ISO 8601 sets out the YYYY-MM-DD order, which removes the doubt in a date such as 01/05/22 (ISO 8601-1:2019; ISO date format guide).

• Site and equipment visited, by the same identifiers used in the products-in-use list.

• Observations in plain words: appearance, odor, deposits, leaks, foam, wear.

• Measurements with value, unit, method or instrument, and where the sample was taken.

• Product and lot involved, if the finding concerns a specific delivery.

• Comparison with the previous visit: same, better or worse, and by how much.

• Action agreed, owner on each side, and the date by which it should be checked.

• Documents handed over or promised.

The comparison line is the one a CRM note rarely carries, and it is the one that turns a set of visits into a history. If the previous visit used a different unit or method, write that down instead of comparing the two numbers.

Why track the technical documents sent to each customer?

You track the technical documents sent to each customer because safety data sheet rules in both the US and the EU tie a distributor's duty to who received which version and when. In the US, paragraph (g)(7)(i) of the Hazard Communication Standard says distributors "shall ensure that safety data sheets, and updated information, are provided to other distributors and employers with their initial shipment and with the first shipment after a safety data sheet is updated" (OSHA, 29 CFR 1910.1200, 2026).

The EU rule reaches further back. Suppliers must update a safety data sheet without delay when new hazard or risk management information appears, or once an authorisation has been granted or refused, or once a restriction has been imposed, and the new version, "identified as 'Revision: (date)'", must go free of charge to all former recipients supplied in the preceding 12 months (Regulation 1907/2006, Article 31). To meet that, you need a list per product of customers supplied in the window, and a record of the revision each one received.

For each document sent, record:

• Document type: safety data sheet, technical data sheet, certificate of analysis, declaration or test report.

• Product and the revision date or lot printed on the document.

• Customer, site and recipient name.

• Date sent and channel: with shipment, email or portal.

An email log with attachments holds the same facts but cannot answer, in one query, which customers still hold an older revision.

How do you run a CRM and a technical customer record side by side?

You run a CRM and a technical customer record side by side by giving each one a job, sharing one customer identifier between them, and keeping technical facts out of deal notes. The CRM keeps contacts, quotes, opportunities and commercial complaints; the technical customer record keeps sites, equipment, conditions, products in use, visits and documents sent.

A workable split:

1. Use the same customer and site identifiers in both systems, so a deal can point to the site record instead of repeating it.

2. Decide which system owns each field, using the table earlier in this article, and write that rule down.

3. After each visit, write the technical findings once in the technical record; the CRM activity note links to it.

4. When a safety data sheet revision arrives, run the customer list from shipments in the preceding 12 months and record each send against the customer (Regulation 1907/2006, Article 31).

5. Review the technical record before any quote for a changed product or application, so the quote rests on current conditions.

Lubinpla collects technical records per customer account, such as contacts, notes, outputs, projects and work logs, instead of deals, and it does not manage a sales pipeline. Whatever tool you use, the test is the same: a colleague who has never visited the site should be able to say what runs there, under which conditions, and which document revision the customer holds.