I rebuilt rate handling and terminal setup as tracked workflows

The product is end-to-end procurement for port-call services, making sure purchase orders are created at the right time using the right rates. I joined after the first release and picked up the design from the second release onwards, initially improving workflows around rate management.

A large part of my work focused on terminal onboarding: turning a complex setup process into a more guided workflow for configuring, validating, reviewing, approving, and activating terminal-specific procurement logic. The latest release extended the product beyond rate handling into more advanced configuration, onboarding, and decision-support workflows.

The original framing positioned the product as something that automated PO generation. Alongside the system architect, I drove the design towards a system that explains and resolves the decisions behind every PO.

That meant treating both rate management and terminal onboarding as governed, observable workflows inside the product rather than fragmented file-based or expert-led processes. Rates, configurations, validation results, approvals, and exceptions became structured steps the system could support and record.

For terminal onboarding, the design challenge was to help users move through a complex setup process with enough guidance, visibility, and control to make confident go-live decisions.

The change has been qualitative: rate management moved from uploading data and hoping it works to managing, validating, approving, and tracking rates as an explicit workflow inside the system.

Terminal onboarding time dropped from 26 days to 5 days and became a more guided product workflow, helping users configure, validate, review, approve, and progress onboarding decisions with clearer status and accountability.

Repositioning it from a PO generator into a decision system happened in stages, across three versions. Joining mid-product meant working with an inherited architecture and the choices that had already been made.

Terminal onboarding made those tradeoffs more visible. The workflow had to support complex configuration, validation, exception handling, and approval decisions without overwhelming users.

Aligning its components with other procurement apps also took longer than I wished and meant some product-specific optimisations had to wait until the product team decided to touch them again.

The decision-system framing had to be retrofitted in later releases rather than set upfront in the first. If I were picking up a product like this again, I’d push for that framing at the first opportunity, especially before expanding into complex onboarding workflows.

For terminal onboarding, I’d also define success measures earlier around decision quality and operational confidence: whether users understand what has been configured, know what still needs attention, and can progress or pause onboarding without falling back to offline coordination.