Special Service Request (SSR) helps provide a platform for shipping lines and freight forwarders to request ad hoc services, allowing the terminal to offer these services profitably and prevent revenue leakage.

CONTEXT

Reimagine the legacy Special Service Request module into an independent, global product to eliminate revenue leakage across all terminals.

During my time as a Product Designer II at DP World, I owned all design aspects of the Special Service Request (SSR) module. The project came with tight deadlines and constant changes to requirements from our initial customers— the two terminals we were serving first—while also considering the broader audience for the product’s future launch. To navigate this, I carefully documented every iteration, ensuring the design process stayed organized and transparent. My goal was to create a simple, user-friendly experience while staying adaptable to the evolving needs of the product.

MY ROLES

I owned all design responsibilities, including research, wireframing, prototyping, and user testing, while collaborating closely with product and development teams to successfully bring this project from concept to production.

PROJECT IMPACT

SSR is live in two locations, and has a transaction value of USD 2,270,246 until 31st June 2024. Yearly revenue collected by the service is estimated to be 1 million dollars, and the service is able to track revenue leakage which is critical for terminals.

SSR now records around 7000 successful daily transactions.

GOAL

Enable the stakeholders like shipping lines, shipping agents, and clearing agents easily request on-demand services from terminals.

The system should centralize these requests, allowing third-party service providers to offer their services directly through the platform.
Terminals can seamlessly track and manage these interactions - acting as the central point of contact for customers and providers, and gaining a new revenue stream by earning a share of service fees while improving overall efficiency.

PROCESS

I kicked things off by diving deep into the legacy product to figure out what was working and what wasn’t.

Then, I talked to users to get a real sense of their daily routines and how SSR could make their jobs easier.

USER 1: TERMINAL OPERATOR

Terminal operators are the key players ensuring everything at the port runs smoothly. When a shipping line makes an ad-hoc request like extra storage, special equipment, or priority handling, they’re the ones who make it happen. This makes them one of the primary users of the SSR system.

USER 2: THE END CUSTOMER

The target customer in this case was someone who represents a shipping line - a Shipping Line Agent. They’re the go-to person for managing all the logistics and coordination on behalf of the shipping line - the company who owns and operates container/cargo ships.

Turns out, customers want a simple solution that helps them achieve the following

To get a full picture, I also ran a workshop with Product and Development team to explore how SSR communicates with other software systems, which was key to understanding the backend

From all of the above, I identified three main problems. Once we tackled them, terminals may find this product incredibly valuable.

Identified Problem 1

Identified Problem 2

Identified Problem 3

Tight timelines means quick decisions. So, I relied on my research to guide me in making the right calls and then iterate based on feedback.

Decision 1: Use an existing DP World design system that will work for this project's needs and requirements to help meet the timelines

Decision 2: Simplify selecting existing SSRs: It should be quick and easy to configure workflows for types of SSRs that were already existing in the system

Decision 3: Reduce the amount of information to be entered on a single page to allow the user to focus on the fewer fields at a time

Decision 4: Reduce steps required to configure new SSRs so the terminal is able to make many SSRs available to the customer

What wasn't working in the first iterations?

Even though we simplified the workflow, users still had to set up each Service Request one by one, which didn’t really cut down their overall effort by a lot. Setting up one Service Request was easier, but what we really needed was to either make the process even shorter or allow for bulk SSR creation.

Proposed Prototypes

For Customers

Seamless Integration: Works smoothly with the Terminal Operating System (TOS) and Port Community System, keeping everything connected.

Transparent Costs and Approvals: Get a clear breakdown of SSR costs

Streamlined Document Handling: Upload documents directly to the platform without extra hassle.

Clear Communication and Tracking: Add comments and view an audit trail for full transparency.

For Terminal Operators

Terminal Operators can quickly handle special service requests online, no more messy manual work.

A dashboard with real-time status helps Terminal Operators track jobs, and have control activate or de-activate the special services based on Terminal capacity

"This is exactly what we are looking for, solution look good and straight forward, can see Ports and Terminals using it"

- Soren (Senior Director - Revenue & Pricing Ports & Terminal - Commercial - Europe)

Special Service Request (SSR)

Team

STATUS