Start with the operating model
Union management software should explain relationships, not only store names. A useful model connects people to positions, organizational entities and agreements, then keeps that context available in casework, communication, meetings and reporting.
Ask vendors to show what happens when a position changes, a grievance moves to another representative or a meeting is published. Those changes reveal whether the product preserves history and accountability or simply replaces one set of disconnected lists with another.
Use repeatable demonstrations
Prepare a small set of controlled scenarios before product meetings. Give every vendor the same member change, case intake, communication hand-off, report question and access test.
- Observe the workflow in the current product.
- Separate configuration work from generally available behaviour.
- Record limitations and external provider requirements.
- Include denial and recovery paths, not only the happy path.
Evaluate implementation with the product
Migration, access design and administrator ownership are part of the purchase. A technically capable system will still disappoint if the union’s terminology is unresolved or nobody owns data corrections.
A controlled trial should prove one end-to-end outcome with representative users. That evidence is more valuable than a broad tour that nobody can reproduce afterwards.