Gather the Right Inputs for a CNC Coolant Filtration Review

A manufacturing engineer calls about dirty coolant and a machine count, and expects a model number back. That is not enough to build a filtration review on. Before anyone can size a system or propose a configuration, a technical sales engineer needs verified facts about the machines, the fluid, the interfaces, and the constraints of the plant around them. Skip that step and the proposal you send back is a guess dressed up as an engineering answer, and it will show the first time someone on the plant floor checks it against reality.

Why this conversation goes wrong

The pressure on this call is to sound helpful fast. A plant contact describes five machines and dirty coolant, and the instinct is to name a filtration unit on the spot. That instinct causes real damage. Coolant chemistry varies by machine even within one cell, tramp oil and bacteria produce symptoms that look identical from a phone description, and a return line that looks standard in one plant often is not standard in the next building over.

The second failure mode is treating the caller's summary as a diagnosis. "Dirty coolant" could mean tramp oil contamination, bacterial growth, chip fines, mixed chemistries in a shared sump, or a filtration system that was undersized from the start. Naming a cause before you have the coolant analysis in hand is not confidence, it is a guess that engineering will have to unwind later. And once you have quoted a model number out loud, the customer anchors on it. Walking that back costs you credibility even if the correction is right.

How to prepare before the call

Preparation here means building a short, specific list of what engineering needs before it can evaluate a configuration, not a general checklist you recite from memory.

1. Machine manuals and model numbers for every unit in the cell, since coolant system interfaces differ by machine generation even within the same manufacturer line.
2. Current coolant analysis for each chemistry in use, covering concentration, pH, tramp oil level, and bacteria count where available. If no recent analysis exists, note that as an open item rather than filling the gap with an assumption.
3. A record of which machines run which chemistry, since mixed chemistries in a shared return system change the filtration approach entirely.
4. A cell layout or sketch showing return lines, tank locations, and available floor space for new equipment.
5. Utility availability at each cell, including power, floor drains, and clearance for service access.
6. Any maintenance log entries describing when the contamination was first noticed and what, if anything, has already been tried.

Read through what the plant contact tells you and mark every value as confirmed, assumed, or missing. That list becomes your call agenda. If you're preparing for these calls generally rather than for one account, the Manufacturing practice conversations hub has other scenarios that follow the same pattern of confirming inputs before committing to a technical answer.

What to say

Jorge, a manufacturing engineer, opens the call by saying, "We have five machines running dirty coolant. Which model fits our operation."

Mei, the technical sales engineer, answers, "I want to start the technical review with the machine manuals, the current coolant analysis, and the cell layout, so we size this correctly the first time. Do all five machines run the same chemistry and the same return arrangement."

Jorge explains that two different coolant chemistries are in use across the cell and that maintenance never documented where the contamination started.

Mei responds, "Then we treat each machine separately for now. I want each machine's interface, the utilities available at that cell, and the current fluid data recorded on its own line. I will write down every assumption we're making for engineering, and once we have that, we can define the conditions a proposed configuration has to meet."

Jorge pushes back a little, saying he was hoping for a faster answer since the coolant smell is bothering operators on the floor. Mei acknowledges that directly. "I understand the urgency, and that's exactly why I don't want to guess at a model now and have engineering send it back in two weeks because the chemistry data didn't support it. Let's get the analysis and the layout to me this week, and I can turn a configuration review around quickly once the inputs are solid."

That last exchange matters as much as the technical questions. Mei names the tradeoff instead of just refusing the request, and she gives Jorge a concrete next step instead of leaving him with nothing.

Mistakes to avoid

1. Naming a contamination cause from a phone description. Tramp oil, bacterial growth, and chip fines all produce a similar smell and appearance, and guessing wrong sends engineering down the wrong path.
2. Quoting a model number before confirming chemistry compatibility across every machine in the cell. A unit sized for one chemistry can fail against another.
3. Assuming all machines in a cell share the same interface and return arrangement just because they sit in the same area. Confirm it machine by machine.
4. Promising a delivery date or a fix timeline before engineering has reviewed the actual data. A date given too early becomes a commitment you did not mean to make.
5. Letting urgency talk you into skipping the coolant analysis. A rushed recommendation without that data usually costs more time later than the delay would have.
6. Recommending that the plant switch coolant suppliers or change chemistry without being asked. That decision belongs to the plant, not to a filtration review.

How to practice and score it

The best way to build this skill is to rehearse it against an incomplete brief, the same way Jorge's call arrives. Hand the engineer a partial machine list, missing at least one chemistry type and one utility detail, and ask for the first five clarification questions they would ask before offering any recommendation.

Score the questions against one standard. Does each one produce a specification, a constraint, or an acceptance criterion, or is it a question that only satisfies curiosity without moving the review forward. A good call note names the source document behind every technical value, whether that's a manual, a coolant analysis report, or a maintenance log, and it flags every unknown explicitly for engineering rather than quietly filling it in. This is the same discipline behind a good utility review before a seasonal changeover, like the approach in Coordinate a Cooling Tower Startup Review Before the Warm Seasonwhere the engineer holds off on recommendations until the plant's actual constraints are on paper. The same restraint applies when a plant contact asks you to commit to stock levels before demand data supports it, which is the situation covered in Revisit Cutting Tool Consignment Levels Without Promising Coverage.

DealSpeak lets you run this exact scenario against an AI counterpart that plays Jorge, pushes back on the delay the way a real plant contact would, and scores whether your questions actually produced usable inputs for engineering.

Before you configure anything

A coolant filtration review only holds up if every number behind it traces back to a document, not a guess made to sound responsive on a call. Confirm the machine data, the chemistry, and the interfaces first, and the configuration you propose later will actually survive contact with the plant floor. Practicing this exchange until the clarifying questions come automatically is what separates a fast answer from a correct one.