CRM 2.0: a deal-origination system for infrastructure finance · Case study

Problem

This institution guarantees local-currency bonds that fund infrastructure across Nigeria: clean energy, transport, housing, healthcare, manufacturing. Moving a project from first conversation to financial close is a long, regulated, multi-stage process, and deal teams were running it out of spreadsheets and email threads. CRM 2.0 is the rebuild.

No shared view of the pipeline. Leadership couldn’t see the portfolio by sector, stage or project type without someone building a deck.
Inconsistent records. Company and project data lived in a different shape on every team.
Origination context was scattered. Deal team, activities, checklists, documents and discussion sat in nobody’s system of record, so the history of a decision was somebody’s inbox.

Evidence / research

I started from the workflow deal teams were actually running: a spreadsheet per team, email threads for discussion, and portfolio decks assembled by hand whenever leadership asked. Modelling a deal’s lifecycle from first contact to financial close against that workflow showed where information was re-keyed, where it changed shape between teams, and where the reasoning behind a decision dropped out of the record entirely.

My role

As lead product designer, I set design direction, modelled the deal lifecycle and owned the design system shared by the CRM, learning platform and internal service desk. My role also included design QA and mentoring two designers.

Constraints

The design had to be delivered in one month, for deals that move through a long, regulated lifecycle across multiple infrastructure sectors. The record needed to retain history as its stage changed, and operations needed to adjust taxonomy and permissions without requiring an engineering change each time.

Options considered

The obvious build was a screen per deal stage, which mirrors the process diagram but scatters a deal’s history across screens as it moves. Free tab navigation from the very first step would have been flexible, but it lets every team capture a new deal differently, which is the problem the rebuild exists to fix. And hard-coding sectors, stages and roles would have been quicker to ship, but every change in a regulated taxonomy would then need an engineering ticket.

Decision

One deal record, not a screen per stage. A tabbed record keeps context in one place; the deal’s stage drives which checklist and activities apply, so the structure guides the work without boxing teams in.

Wizard to create, tabs to manage. Structured capture up front buys consistent data; free navigation afterwards keeps it usable day to day.

Move the deal-team conversation into the record. In-record comment threads replace the email chains that used to be the only trace of why a call was made.

Configuration over hard-coding. In a regulated institution the taxonomy shifts; the settings layer lets operations move with it safely.

Design

What I did

Modelled the full deal lifecycle (Origination → Due Diligence & Structuring → Credit Approval & Financial Close) into one consistent record with the same tabs (Company Details, Deal Team, Other Details, Files, Activities, Checklist) whether a deal is in pipeline or mandated.
Designed a guided creation flow that mirrors those stages, so every deal is captured the same way regardless of who opens it.
Built the portfolio dashboard: distribution by project type, approval stage, categorisation, stage and sector. It is the deck leadership used to ask for, now live.
Designed a deep settings layer (business units, departments, roles & permissions, industries, lead sources, financial-year targets, email templates, activity logs, system variables) so operations can change the taxonomy without an engineering ticket.
Own the design system shared by the CRM, the learning platform and the internal service desk.

CRM pipeline list — Pipeline: every deal, filterable, with new / mandated / total counts

CRM guided deal creation — Guided creation: the same capture, every deal

CRM deal checklist tab — Inside a deal record: a stage-driven checklist

CRM deal team tab with role assignments and an in-record comment thread — Deal Team: who's on it, and the conversation stays with the deal

CRM system settings — Settings: operations owns the taxonomy

CRM roles and permissions table mapping role IDs to user types — Roles and permissions, configured, not hard-coded

Collaboration / implementation

I worked through DREEF with the client’s product and engineering leads and mentored two designers on the wider internal suite. Design-system ownership connected the CRM work to the learning platform and service desk.

Measurement

Adoption across deal teams, the change in origination cycle time, and how many deals now live in the system rather than a spreadsheet are still early. I hold them as targets rather than confirmed results, with firm figures to follow once there is a stable stretch to report.

Result

One system now models 5+ sectors of infrastructure deals on a single deal record that carries a project from first contact through financial close. The portfolio dashboard replaced the manual decks leadership used to ask for, and the settings layer lets operations adjust the taxonomy themselves, without an engineering ticket.

What I learned

The central lesson was to establish what stays consistent as a deal moves forward. Its stage, checklist and team activity can change, while the underlying record needs to retain its history. That distinction gave the interface a stable structure across a complex lifecycle.

Configuration also deserves the same design attention as everyday deal work. Taxonomy and permissions shape what teams can record and see. In a next iteration, I would review how operations manages those settings and where deal teams still rely on spreadsheets, using those gaps to guide improvements.