Challenge

CIAL Dun & Bradstreet is the Latin American arm of Dun & Bradstreet, the global standard for commercial credit data. Their database covers over 500 million organisations worldwide. Finance teams using CIAL360 were making credit decisions on top of that data — and doing it manually, one report at a time.

Three roles were operating on the same data at different reading speeds and with different decision rights: credit analyst, finance manager, executive. The platform needed to serve all three without collapsing into either an analyst tool with a management dashboard bolted on, or a dashboard with buried detail.

‍

The Architectural Decision

CIAL360 is organised around three states: search, analyse, decide. Every screen, every permission scope, and every view mode maps onto one of these three. That structure wasn't inherited from the brief — it came out of the design sprint, where I worked with finance managers, credit analysts, and reporting staff to establish what the platform actually needed to do before any interface was designed.

The sprint produced a journey map across four stakeholder rows (Sales, Analyst, Manager, Committee) and three stages (Reach, Learn, Use). One stakeholder note from that session named C360 as the company's core product offering — the business stakes were clear from day one. The workflow structure I committed to in that sprint is the one that shipped.

‍

Research

Post-sprint interviews with clients and internal reporting staff confirmed the core problem: every credit evaluation happened in isolation. Users examined reports one at a time, with no aggregation layer and no comparison mechanism. Decisions were slow and inconsistent across the same portfolio. This validated the Analyse state as the platform's hardest design problem — not the search interface, and not the permissions model.

‍

Solution

The three features below are not independent — they are the three states of one workflow.

Search

Access to over 587 million companies in the CIAL Dun & Bradstreet database, searchable across multiple criteria. The search surface is the entry point to the workflow; its job is to move users into analysis as quickly as possible.

‍

Analyse

Two views for the same data: a table view for side-by-side report comparison and a dashboard view for portfolio-level metrics. Days to close, deal amount, payment terms, in-progress and closed requests, country and industry breakdowns — all surfaced in one place. The decision to give analysts two modes rather than one unified view came directly from research: analysts needed granular comparison, managers needed aggregate status. Forcing one view would have served neither.

‍

Decide

A structured approval workflow with defined stages: Start → Initial decision → Investigation → Approval → Final decision. Role-based permissions scoped to each position: analysts evaluate, managers recommend, executives approve. The Default Policy Settings layer — approvers, watchers, max amount for auto-approval — is the proof that the workflow holds under the constraints of a regulated business process.

‍

Testing

I ran usability sessions with early clients who had previously used manual credit processes. Three changes came directly from that feedback: expanded filtering options to reduce time-to-insight in the Analyse view, improved workflow status visibility across team members, and role-specific navigation adjustments that reduced decision overhead at each permission level.

‍

Result

Finance teams stopped comparing reports manually. Credit decisions moved into a single structured workflow — search, analyse, decide — with the right data visible to the right role at each stage.