How to Run an Additive Manufacturing Workflow Software Pilot Before You Commit

To evaluate additive manufacturing workflow software before committing to a wider purchase or rollout, agree a limited set of representative jobs, define acceptance criteria before configuration begins and test the workflows with the people who will use them. Record what works, what requires manual intervention and what remains untested. Use that evidence to decide whether to proceed, investigate further or stop.

A demonstration can show how a system handles a prepared workflow. Your buying decision also needs evidence about how it handles your jobs, data and responsibilities. For an AM team, that might mean following several parts through a shared build, then checking that each retains its own downstream route and order connection.

This guide assumes you have already shortlisted software against your requirements. For the wider selection context, see our complete guide to additive manufacturing workflow software. The next task is to turn those requirements into tests that produce a useful purchase decision.

Agree what the evaluation needs to prove

Start with the uncertainty that could change your decision. Perhaps your team needs to know whether operators can update work without duplicate entry, whether planners can understand the impact of a priority change, or whether quality staff can retrieve the history of an individual part. Write each uncertainty as a question with an observable answer.

For example: “Can the planner identify which orders are affected when this build is delayed?” gives the team something specific to test. “Does the software improve visibility?” leaves too much room for interpretation. Select a small number of questions that matter enough to influence the decision, and identify who will judge each answer.

Agree what the supplier means by a demonstration, proof of concept or pilot. These labels can describe different arrangements. Confirm whether users will operate the system themselves, whether it will use your data, which integrations will function and whether any live production is involved. Also agree the evaluation cost, responsibilities, deliverables and end date.

The UK Government’s Digital, Data and Technology Playbook recommends clear objectives, defined scope and time to assess results when designing technology tests. It addresses public sector procurement; the useful principle for an AM buyer is to decide what evidence you need before the evaluation starts.

Choose a representative workflow and bound the scope

Select jobs that expose the relationships your operation depends on. A useful AM test might involve parts from separate orders sharing a build, followed by different post-processing and inspection routes. This gives you a way to examine both build-level coordination and individual part history without attempting to reproduce the whole factory.

Include the people who handle those transitions: planning, production and quality, with IT involved where data exchange or access needs testing. Identify the records they need, where those records originate and who updates them. Use representative data under your organisation’s sharing rules, retaining the complexity that matters to the test.

Write down the boundaries. Specify the site, process, users, job types and systems included, plus anything excluded. If the ERP connection is simulated, describe it as simulated. If material information is entered manually, do not treat that result as evidence that automated material data exchange works.

Choose the smallest scope that can answer the important buying questions. Then agree how to handle new questions: add them only if they affect the decision and the team can accommodate them. Otherwise, record them for a separate evaluation or implementation phase.

Write acceptance criteria before testing

An acceptance criterion describes what must happen for a requirement to pass. It should identify the scenario, expected result and evidence. “Traceability available” is too broad; “the quality reviewer can retrieve the selected part’s build reference, recorded inspections and disposition from its record” is more testable.

Separate mandatory requirements from preferences. A mandatory requirement should act as a decision gate, rather than becoming one item in an average score. A system that performs well on several convenient features may still be unsuitable if it fails a requirement your operation cannot work around.

Agree the criteria with the supplier before configuration begins. This gives both sides an opportunity to identify missing data, clarify responsibilities and flag requirements needing additional work. Record whether that work involves standard configuration, an integration, custom development or a proposed future capability.

If reducing administrative effort is a priority, measure a comparable task in the current process and during the evaluation. Keep the starting data and endpoint consistent, and record assistance given to users. A small test can provide evidence about that task; it cannot establish an annual saving across the operation without further assumptions.

Test routine work and realistic exceptions

Run the normal workflow first, then introduce a few changes that reflect how your team actually works. The following scenarios are illustrative tests, rather than claims about any particular product. Adapt them to your requirements and the evaluation scope.

First, follow two parts sharing a build but requiring different downstream operations. Ask users to retrieve each part’s status and order connection after the build completes. Check whether the records remain understandable when the parts take separate routes, and record any manual reconstruction needed.

Next, place an inspection hold on one selected part. Test whether the responsible user can identify the affected work, record the decision and retrieve its history. Define the expected effect on related work beforehand, so the team can judge the result against its own process rather than an assumption made during the test.

Finally, change an order’s priority and ask the planner to review the consequences. Examine what information supports the decision, who must approve it and how the changed plan reaches the relevant users. If scheduling automation is outside scope, assess the planning workflow that is available and record that boundary.

For each scenario, capture the starting conditions, actions, result and supporting record. Include unsuccessful attempts. If the supplier corrects an issue, repeat the test and retain both results so the final assessment explains what changed.

Record configuration effort, workarounds and user experience

Successful output is only part of the evidence. Record what it took to achieve it: data preparation, configuration, training, supplier assistance and repeated manual steps. Distinguish initial setup from effort that would recur for every job, and identify who would own each activity after purchase.

Ask users to perform the agreed tasks themselves once they have received the planned training. Observe where they need help, whether they can locate the right records and whether another person can understand the resulting updates. Feedback should describe a task and its consequence, such as difficulty identifying the next operation, rather than a general preference about the interface.

A workaround may be acceptable for a rarely used activity. The same workaround repeated for every part could affect the value of the purchase. Record its frequency, owner and likely operational burden, then ask whether the proposed resolution is included in the offer and can be retested.

From an Authentise perspective, an AM evaluation should examine how jobs, machines, materials and approvals stay connected as work changes. FlowsAM brings planning, scheduling, production tracking, traceability and reporting into one workflow platform. Buyers should still agree which capabilities and connections will be demonstrated in their own evaluation, and assess the resulting evidence against their requirements.

Use an AM software pilot scorecard

Use one shared scorecard so that operations, quality, IT and the supplier can refer to the same evidence. Keep the outcome separate from its limitations. A completed scenario may pass while leaving an important integration or production-volume question unresolved.

Requirement	Test scenario	Acceptance criterion	Evidence	Outcome and limitation
Preserve individual part context	Two orders share a build, then follow separate routes	Each selected part retains the correct order and downstream route	Part records and route review	Record pass, fail or untested; note manual steps
Make a quality decision retrievable	Apply and resolve an inspection hold	Authorised reviewer can retrieve the recorded decision and its history	Hold and disposition records	State any missing information or workaround
Support planning decisions	Change one order’s priority	Planner can assess the agreed impacts and communicate the revised plan	Before-and-after plan and user observations	Identify what was demonstrated and what remains untested
Reduce duplicate administration	Complete an agreed status update	Update reaches the required record without the specified duplicate entry	Task observations and records	Note assistance, setup and excluded integrations

These rows are examples, not a universal acceptance standard. Add your mandatory requirements and mark them clearly. Use consistent outcomes such as passed, failed, untested or passed with a documented workaround. Attach evidence that someone outside the test session can review, and assign an owner to every unresolved item.

Decide whether to proceed, extend or stop

Review the findings against the criteria agreed at the start. Proceed when mandatory requirements have been demonstrated and remaining work is understood well enough to inform the purchase and implementation plan. Include costs, responsibilities and dependencies alongside the successful results.

Extend the evaluation when a specific unresolved question could change the decision. Define the additional test, owner, deliverable and decision date. An extension needs a clear purpose; continuing to explore features without an endpoint makes it harder to reach a purchase decision.

Stop when a mandatory requirement fails without an acceptable resolution, or when the effort required is disproportionate to the expected value. Retain the findings so the next evaluation starts with better requirements. A useful pilot can end with a decision to choose another approach.

Keep the limits visible. A short evaluation does not prove performance at every production volume, long-term support quality or whole-life ROI. Security, deployment, support and applicable quality requirements need their own review where the pilot has not addressed them. Carry those questions into the next decision stage with named owners.

Before your next supplier conversation, prepare one representative AM job, the exceptions you want to test and a short set of acceptance criteria.

Discuss your workflow with Authentise and agree what a scoped evaluation would need to demonstrate. Use that conversation to agree the scope, evidence and responsibilities for any proposed evaluation.