Testing Agentforce in Production: What the Pilot Reveals About Your Asset Data

Management wants to see by the end of the year what AI can bring to the service department. Inside sales have been accurately tracked for years; service cases are handled through the same system, and technicians receive their assignments from it. Now it’s time for an agent to show what he can do. The obvious question is: Where do we deploy him, and how will we know after four weeks whether it’s working?

You’re not alone in facing this pressure. In a Gartner survey of 321 service and support managers, 91 percent said their senior management is pushing them to implement AI by 2026 (Gartner, February 2026). As a result, the decision to launch a pilot is made quickly. However, the insights it reveals about a company’s own data are rarely analyzed. Here’s a quick overview of what matters:

• Anyone who already manages their machines in the service system has completed the most important preliminary work. An agent can start working on real cases there right away.
• Triage of incoming cases is the most sensible first step. Classify, identify possible causes, find similar cases, suggest the next step: This takes the load off the inside sales staff and relies on existing data.
• The pilot demonstrates, case by case, where the agent offers advice. Every weak response can be traced back to a specific gap, such as measurement data from a separate system or maintenance tasks that are not related to the machine.
• Gaps are closed one by one, wherever the pilot points them out. A complete renovation is not necessary for this.

Agentforce in Action: Why triage is the best first step

A service case in machinery and equipment begins almost the same way. A customer reports a malfunction via email, phone, or the portal—often with a fault code, sometimes with a photo, and rarely with a serial number. Inside sales staff read the report, locate the machine, review its service history, consult an experienced colleague, and decide: callback, remote maintenance, spare part, or on-site technician visit. With 40 or 60 reports a day, this is the bottleneck of the entire service operation.

This is exactly the kind of work an agent can prepare. In this context, “triage” refers to four things:

• Classify: Category, Urgency, Affected Assembly.
• Suggest possible causes: two or three hypotheses, each with a rationale.
• Find similar cases: involving the same model series, with the same error message, and with a documented solution.
• Suggest next step: Follow up with the customer, remote diagnosis, spare part, service call.

The person decides. The agent saves them the trouble of searching, and the inside sales staff notices this from day one.

There’s also a practical reason: Triage doesn’t need anything that isn’t already there. Anyone who has been using Salesforce for service for years already has the cases—which the system treats as assets—along with their custom extensions, service history, and, in most cases, documentation stored in the system. An agent can work with this data without having to create a new data model first. The platform already includes built-in modules for categorizing incoming cases, such as classification by type and priority based on previous cases.

Agentforce for Field Service, which has been gradually available since 2025, focuses on a different set of tasks: scheduling, briefing the technician before the assignment, troubleshooting on-site, and reporting afterward. These elements complement each other. Triage decides whether a service call is necessary at all and what the technician’s initial hypothesis is when they head out.

Launching the pilot program: real-world cases, transparent evaluation

Many pilot studies fail because of the evaluation process. Testing lasts three weeks, the feedback is “somewhat good, somewhat off the mark,” and no one can say what went wrong. A pilot study only becomes informative when each response is evaluated individually.

The most revealing test is a “retrospective” test: The agent is given closed cases whose outcomes are known. Ideally, these should come from a product line with many machines in the field, covering the past six to twelve months, and involving a mix of simple and complex malfunctions. Because the actual cause is known, each response can be clearly classified:

• Confirmed: The hypothesis and next step match the actual course of events, as evidenced by data in the system.
• Plausible, but unsubstantiated: The answer sounds correct, but is based on general knowledge rather than data from this machine.
• Off-topic: The answer doesn’t fit the case, or the agent is making up a connection.

The second group is the most interesting. In this group, the result is correct either by chance or based on the language model’s experience—not on your data. The next model could just as easily get it wrong. That’s why each answer in groups two and three is accompanied by a brief note: What information would the agent have needed, and where can it be found today?

This should be evaluated by the people who handled the cases back then—that is, the inside sales staff and experienced technicians. They can immediately tell whether a hypothesis holds up from a technical standpoint. If you’re conducting the pilot with your implementation partner or with support from Agentforce, this evaluation checklist should be included in the project plan.

What the Agent Recommends: What It Says About Your Asset Data

After reviewing several dozen cases, the notes begin to repeat themselves. Often, just a few causes account for a large portion of the poor responses. Typical scenarios:

The fourth line is often underestimated. Extensions to the asset that have accumulated over the years are taken for granted by the people in the company: Everyone knows what “Special Version Code” means or which value in the “Control Generation” field is critical. An agent doesn’t know this. He reads field names, descriptions, and selection values. If the descriptions are missing, he ignores the field or misinterprets it. The effort required to fix this is minimal: a list of the 20 to 30 most important fields, each with a brief explanation, maintained in the system.

One gap at a time

The list of notes becomes a priority list. At the top is the gap that explains most of the weak responses and can be closed with the least effort. Often, these are the field descriptions or the assignment of maintenance history. Integrating the measurement values takes longer because it involves a second system. The article “From Machine Data to Service Order” describes how a measurement value is turned into an editable case.

The structure you have established with your implementation partner will not undergo any fundamental changes. Mappings, descriptions, and, if necessary, individual fields will be added. After each gap is closed, the same set of test cases runs through the system again. This reveals how many responses shift from “guessed” to “correct,” and the next investment can be justified using your company’s own data.

The pilot also serves as a data check. It costs barely more than the test you’d be taking anyway, and it provides a prioritized list that will still be useful after the pilot is over.

What a Triage Agent Should Be Able to Do in Machinery and Equipment

Three qualities determine whether an agent is suited for this job. He must be able to work with machines—that is, with model series, serial numbers, assemblies, and fault codes, which have different meanings depending on the variant. He must support every hypothesis with the data sets on which he relies. And they must acknowledge when data is missing, rather than filling in the gaps with general knowledge. Without the last two points, evaluation in the pilot is virtually impossible, because “plausible” and “substantiated” look the same. Why this is so crucial for service agents is explained in the article “When Agentforce Hallucinates.”

To address this challenge, logicline has developed Service Decision Intelligence (SDI), a Salesforce-native triage and diagnosis agent for the machinery and equipment manufacturers’ service sector. SDI runs on the standard platform with your own customizations; the Digital Machine File (IOTAM) is not a prerequisite. Every recommendation includes a source citation, and any missing data is explicitly identified as such. This is exactly the information the pilot needs. SDI runs on your infrastructure, is EU-compliant, and is independent of any language model; it can also be accessed directly from Agentforce. With every gap closed, the responses improve.

Next step

An agent pilot program within the service department reveals what information your service department is currently missing with every decision—including that of the inside sales staff. This list is the real benefit, and it remains regardless of which agent ends up being productive.

Two pragmatic approaches:

• Installed Base Assessment – if machines, maintenance tasks, and measurement values are currently spread across multiple systems and you want to know, before the pilot phase, what data is being collected at the machine.
• introductory call – if your machines are registered in the service system and you want to clarify which cases and which assessment criteria the triage pilot will use when it launches.

For the first round, choose the product line for which the inside sales department receives the most reports. That’s where the agent will first lighten the inside sales department’s workload, and that’s where the gaps will become apparent the fastest.