A custom CRM interface for teams working across dozens of ports

Published anonymously at the client’s request. No company, port or personal details are shared.

Where it started

Picture a group operating dozens of ports across several countries. Each port has its own commercial team, its own customers and its own agenda. Head office has to see all of it.

A standard CRM struggles from both directions here. Show a port team the whole group’s data and they cannot find what they need. Show them only their own and they cannot see what was discussed with the same customer at another port. Finding the middle ground is an interface problem.

What we built

“Which port” on every screen

The backbone of the application was this decision: port selection is not a filter, it is a point of view. The user chooses which ports they are looking at, and the entire page narrows accordingly — contacts, opportunities, risks, recent activity and their counts included.

Region and port filters cannot be used together; selecting one clears the other. That is a deliberate constraint: region casts a wide net, port focuses on a single location. Leaving both active made it harder for users to understand what they were looking at.

Meeting notes, grouped rather than scattered

The data commercial teams produce most is meeting notes. But a note on its own is not much use — you need to know which meeting it belongs to, who attended and which port it concerns.

We grouped notes by meeting. A single row shows the date, the title, how many notes it holds, the linked company, the ports involved and the participants. A task or an opportunity can be created directly from a note — so the note is a starting point rather than an archive entry.

A contact wizard that prevents duplicates up front

Creating a contact became a step-by-step wizard: basic information, duplicate check, scope definition and confirmation.

The critical step is the second. Once details are entered, the system looks for similar records and shows what it finds as cards — with job title, company, email and the relevant ports. The user can open the existing record and carry on from there instead.

The thinking behind that design: a duplicate should not be something you clean up afterwards, it should be something prevented before it exists. Merging later always carries a risk of losing data.

Scope: port-level or group-wide?

Every contact is either tied to specific ports or visible across the group. That is chosen in the final step of the wizard, and it determines who can see the record.

For certain account types the system also suggests a department based on the job title, and offers a separate marker for senior management. When the user changes the suggestion it is flagged as modified — the automation speeds the decision up without taking it over.

The account page: narrative, not just fields

We added a free-text strategic section to the account record: the customer’s strategy, key relationships, history and opportunities.

That is an unusual choice in a CRM built around filling in fields. But some information does not fit in a field. Two paragraphs explaining why a customer relationship is the way it is say more than fifteen separate picklists — particularly to someone new to the team.

It works on a phone

Port teams are not at a desk. How the screens behave on a phone was designed from the start rather than adapted afterwards.

Outcome

The real gain is that users never ask “why am I seeing these records on this screen”. When visibility rules are built into the interface, access control stops being an obstacle and becomes a convenience.

What we would do differently

On a custom interface project at this scale, the biggest risk is every team requesting its own exception. Thirty ports have thirty ways of working, and each wants its own habit written into the system.

Starting a similar project today, we would set out as a written principle, at the very beginning, which decisions stay fixed centrally and which are left to the port. Without that line, every request is debated individually and the schedule becomes a function of how many requests arrive.