Prepare a PLC Network Segmentation Workshop With the Right Owners

A technical sales engineer walks into a controls conversation ready to talk value, and the customer says something like "pull data from three PLCs onto our dashboard." That request sounds simple, but it crosses plant network zones, machine controllers, and often a vendor's remote access path too. The person asking for the connection rarely owns the rules that govern it. Before you sketch any architecture, you need the automation lead and the information technology owner in the room, because network segmentation and remote access are decisions the customer's own review process controls, not something you can approve by nodding along.

Why This Conversation Goes Wrong

Most technical sales engineers get into trouble here for a good reason. They want to show momentum. A customer floats an idea, you see a path to a proof of concept, and you start describing how the interface could work before anyone has confirmed who actually owns the network zones involved. The controls manager you are talking to may know the machines well and still have no authority over the corporate network side of that connection. Central IT may never have heard the request. A machine supplier with existing remote access adds a third party whose access agreement nobody in the room can speak to.

When you propose a design before those owners are identified, one of two things happens. Either the customer's security team blocks the idea later and you look like you skipped a step, or worse, someone builds toward your sketch and finds out mid project that the data path was never allowed to exist in the first place. Either outcome costs you time and costs the deal trust. The fix is not more technical detail in the pitch. It is a shorter list of promises and a clearer list of names.

How to Prepare

Before you take this call, do the homework a controls manager cannot do for you in the moment. You want to walk in already knowing what questions to ask, not discovering them live.

1. Find out how the customer talks about their network zones. Some plants use formal segmentation models with numbered levels, others just say "plant floor" and "corporate." Either is fine, but you need their language before the call.
2. Ask your own engineering team what a workshop like this usually requires as evidence. That typically means a data point list, a connection path diagram, and a note on what review or approval each zone owner needs before a proof of concept can even start.
3. Identify who else needs an invite. If a machine builder or integrator already has remote access to any of the PLCs in question, that vendor's access agreement belongs in the same conversation, not a separate one you have later.

If you want more reps on scenarios like this, DealSpeak's library of Manufacturing practice conversations covers a range of situations where a technical sales engineer has to slow a customer down without losing the deal.

What to Say

Here is roughly how this should go. Asha, a controls manager, opens with the kind of request that sounds small but is not. "We want production data from three PLCs on the corporate dashboard," she says.

Grant, the technical sales engineer, does not answer with an architecture. He asks a question instead. "Which network zones contain those PLCs, and who owns the rules for data leaving each zone?" Asha explains that the plant network team maintains one zone and central IT manages the dashboard on the other side.

Grant uses that answer to shape the actual ask. "Can we bring both of those groups into a short workshop along with your automation lead? Before we talk about any interface, we should document the data points, the connection path, and whatever review each zone requires." Asha agrees, then adds a detail that changes the scope. "One thing worth mentioning, one of our machine suppliers already has remote access to a PLC on that line."

That last line is the kind of detail that gets missed when a technical sales engineer is focused on closing the interface conversation. Grant treats it as core information, not a footnote. "That needs to be part of the same review. Can you also loop in whoever manages that vendor's access agreement? We want one picture of every path in and out of that zone, not two separate conversations that miss each other."

Notice what Grant never does in this exchange. He never says the connection is secure. He never says his company's proposed design will work with the customer's existing controls. He builds a workshop with a defined purpose, a defined guest list, and a defined output, which is a scoped understanding of ownership and evidence, not a green light.

Mistakes to Avoid

The biggest mistake is answering a network question with a sales answer. If a customer asks whether an interface is secure, do not reassure them. Ask who owns the rule that decides that, and let their own security process answer the question.

A second mistake is treating the person on the call as the only stakeholder. A controls manager can speak to production needs and PLC configuration with authority. That same person usually cannot speak for the corporate network or for a vendor's remote access setup. If you let one voice stand in for the whole review, you build a proposal on an incomplete map.

A third mistake is skipping the vendor thread entirely. Remote access from an outside machine supplier is often the least visible risk in the room, because it predates the conversation and nobody thinks to mention it until you ask directly, the way Grant did.

A fourth mistake is leaving the call without a written list of what evidence the customer needs before engineering will even consider a design. Without that list, the workshop you scheduled has no clear finish line, and the customer has no reason to move faster than their normal review cycle.

How to Practice and Score It

Roleplay this scenario with a colleague or a manager, and have them play a controls manager who pushes back the way a real customer would. Have them ask whether the interface is secure, the way Asha might if the conversation went a different direction. Your job is to redirect that question toward ownership instead of answering it yourself.

Score the roleplay against a short set of checks. Did you ask who owns the network rules before describing any technical approach. Did you ask for a diagram or a written list of the zones involved. Did you catch a mention of vendor remote access and pull it into the same review instead of letting it slide. Did you close the call by stating exactly what evidence the customer team will review before your engineering group even considers a design.

DealSpeak scores calls like this one on exactly those behaviors, which makes it a fast way to drill the habit before you are on a real call with a customer whose network policy you do not yet know. The same discipline applies elsewhere on a plant floor, such as when you need to Check Pneumatic Fitting Availability Before Moving a Repair Window before you promise a shorter repair schedule, or when you Design a PPE Standardization Trial That Includes the Workers instead of picking equipment without the people who wear it.

A controls project moves faster when you name the right owners early, not when you sketch the fastest possible architecture. Ask who owns the rules, write down what evidence the customer needs, and let their review process do the approving. That is what earns you the next meeting.