By Kristofor Erickson, Director, Product & Development, Triage Partner
When people talk about flexibility in software, they usually treat it as an obvious advantage.
More flexibility means more options. More options mean the system can support more processes.
From a configuration standpoint, that makes sense.
In ITAD operations, too much flexibility at the point of execution can create problems quickly.
If someone is testing a device, completing an inspection, routing an asset, or following a customer-specific disposition workflow, they should not have to decide what happens next. The ITAD workflow system should already know.
For the worker, there should be very little flexibility.
I consider that a good thing.
Why Should ITAD Workflows Be Rigid for Operators?
ITAD operations often support processes with very little tolerance for interpretation.
A device may need to move through a specific sequence of tests. A returned asset may follow a different path based on condition or customer disposition rules. A scan may need to validate against another data point before the process can continue.
The technician should not be deciding which rule applies.
The system should evaluate the conditions, provide the next instruction, and validate that the required action was completed.
This reduces the amount of process knowledge each person has to carry and makes execution less dependent on experience.
A new employee can follow the same ITAD workflow as someone who has been doing the job for years because the operational logic lives in the system rather than in someone’s memory.
The interface can remain simple even when the process underneath it is not.
Flexibility Belongs Behind the Scenes
The people configuring the operation have a very different need.
An ITAD provider may support several customers with different processing requirements on the same platform. Mobile devices may follow one workflow, while network equipment or computing assets require another.
The software has to support those differences without forcing every technician to navigate them.
The execution layer needs to be highly controlled, while the configuration layer needs room to adapt.
I often describe the distinction this way: flexibility is low-code, while simplicity is no-code.
Low-code gives administrators and technical teams the ability to configure deeper workflow logic when necessary. No-code gives users a straightforward way to interact with that logic without needing to understand how it was built.
The mistake is exposing both layers to the technician.
More Options Can Create More Process Variation
Software teams naturally want to build systems that can do more.
I understand the instinct. I have spent most of my career building software.
The problem is that every option presented to an operational user becomes another decision they have to make.
Should this asset move to another process?
Can this test be skipped?
Should the record continue if required information is missing?
Once those decisions are left to the individual, process variation begins to appear.
One technician may handle an exception differently from another. Over time, those variations become harder to manage, especially when ITAD customers expect consistent processing, documentation, and chain-of-custody records.
A well-designed ITAD workflow system should remove decisions that have already been made at the process level.
Once a customer rule is established, enforcement belongs in the software rather than with the technician.
ITAD Workflow Automation Should Simplify Execution
Consider a returned mobile device entering an ITAD program.
Its next step may depend on cosmetic grade, functional test results, or the customer’s disposition requirements.
There may be a significant amount of logic behind that decision.
The technician should not need to interpret it.
The system should determine the appropriate path and present the required next step.
When we think about workflow design in wipIT, this separation is intentional. A simple instruction presented to a technician can represent a much larger set of rules operating behind the scenes.
Scan this asset.
Run this test.
Move this unit to the assigned location.
Those instructions are simple because the system has already done the more complicated work.
Configuration Cannot Require Custom Development Every Time
Making execution controlled does not mean making the entire platform rigid.
ITAD operations change too often for that.
A customer may introduce a new requirement. A program may expand into another facility. A new service may require the workflow to behave differently.
If every change requires developers to rewrite application logic, the software becomes harder to maintain and slower to adapt.
Low-code configuration helps solve that problem.
Administrators can change the workflow as programs evolve without rebuilding the application around every new requirement.
The technician’s experience can remain straightforward while the platform adapts underneath it.
Where I Look for Flexibility
When I evaluate operational software, I look at where the flexibility lives.
Technicians should not need to understand the workflow logic in order to complete the process correctly. When they do, the system is pushing too much complexity downstream.
A stronger ITAD workflow platform gives administrators enough control to support customer-specific processes while limiting unnecessary decisions during execution.
That separation becomes more important as ITAD providers take on more customer requirements and increasingly varied programs without wanting to rebuild the underlying system every time.
Designing for Two Very Different Users
When we design wipIT, we are designing for two audiences at the same time.
The person configuring the operation needs control.
The person executing the process needs direction.
Administrators should be able to adapt the system as customer requirements change. Technicians should be able to complete the process without having to determine which rule applies.
That balance has become one of the principles I return to most often in system design.
Give the people designing the process enough flexibility to configure what the operation requires, then keep the execution experience as simple and controlled as possible.
When those experiences are separated correctly, the system can support highly variable ITAD operations without pushing that complexity onto the people doing the work.