Transforming fragmented manual contract workflows into a scalable enterprise experience as part of GEMS 2.0
I designed a customer contract module for a leading logistics company to replace an entirely manual contract-creation process, where every shipment's pricing, service commitments and billing rules are decided.
First, a little context
A modernization program, not a redesign, an entire enterprise system built from the ground up.
The client is a leading logistics company (kept confidential here), rebuilding its core enterprise system from the ground up as GEMS 2.0. I joined the program for a year and led design for four months on one specific piece: the Customer Contracts module, where every commercial relationship with a shipping customer gets defined, pricing, service commitments, credit terms and legal clauses, all previously locked inside static Word documents.
Four roles, one shared workflow
Different jobs, different stakes, the same screens had to work for all of them.
The module wasn't built for one job title. It sat at the intersection of commercial, legal and client-facing work, and each of these four roles came to it needing something slightly different.
Draft and finalize contract terms, pricing and service commitments, the primary authors of every contract in the system.
Review clauses for regulatory and legal soundness before anything goes out for signature.
Track where a customer's contract stands and manage the relationship, especially through renewals and negotiation.
Review and negotiate terms as the counterparty, the audience the whole document ultimately has to satisfy.
Everything ran on Word docs and email
No baseline data to inherit either, the older system this replaced didn't feed into GEMS 2.0 at all.
Before this module existed, contract creation was entirely manual. Terms were drafted in Word, pricing was worked out by hand or in disconnected spreadsheets, and negotiation happened over email and phone calls with no single thread to follow. Nothing was structured, nothing was searchable, and there was no connection to the company's earlier system, so this wasn't a migration of existing data, it was a genuinely blank slate.
🐢 Drafting was slow
- Every contract typed and formatted from scratch
- No reusable structure between similar customers
- Rounds of manual edits before anything was final
⚠️ Errors slipped through
- Rate mismatches from manual pricing calculations
- Inconsistent clauses across similar contracts
- No systematic check before a contract went out
📅 Renewals got missed
- No centralized view of what was expiring and when
- Tracking relied on individual memory or personal spreadsheets
- Lapsed contracts discovered only after the fact
✉️ Negotiation had no trail
- Back-and-forth scattered across email and calls
- No record of who agreed to what, or when
- Status updates required chasing someone down
Grounding it in how people actually worked
No legacy data to reverse-engineer, so I went straight to the people doing the work.
With no existing digital baseline to study, I couldn't start from an old interface or a data model that already reflected real usage. So I went to where the work actually happened, the corporate office, and spent time with the people who lived in this process every day.
Spent time at the corporate office to see contract creation and negotiation happen in real time, not described secondhand.
Sat with commercial, legal and relationship teams as they worked through actual contracts, watching for where they slowed down or improvised.
Catalogued every field a contract actually needed, dense and highly interconnected, with no existing system to lean on for structure.
Most users were experienced professionals in their 30s to 60s, comfortable with their domain but not necessarily with software, which shaped every layout decision that followed.
the brief wasn't "digitize a form," it was "give dense, high-stakes data a home that doesn't overwhelm the person entering it."
Five decisions that shaped the module
Each one traded a simpler build for a workflow that actually held up under real use.
Auto-populate from Customer Onboarding, don't re-ask
A customer's details already existed in the Onboarding module. Instead of letting creators retype them, I pushed for auto-populated, editable fields marked for quick verification.
Account, KYC, address and contact information arrive already filled in from onboarding data, organized into clear sub-sections the creator can expand, check and correct rather than type from scratch.
A four-level structure to tame a genuinely dense form
A contract spans customer info, commercial terms, rates, insurance, documents and clauses, far too much to show flat. I grouped it into a four-level hierarchy, moved through step by step, with each section collapsible.
Thirteen legal clauses, from transit time to arbitration, each collapsed by default with a standard/custom choice up front, so reviewing a contract never means scrolling through a wall of legal text.
A rate card calculator, not a rate card field
Pricing used to be worked out by hand, then typed into a document. I built a rate configuration tool where a manager sets charge type, category and slab rules, and sees the rate card calculated live.
Charge type, rate type, category and slab rules feed directly into a live rate card preview, by range, sector and applicable service, so the number on screen is always the number the system actually computed.
One tracking view for every contract's status
Knowing where a contract stood meant asking whoever owned it, and that broke down if they were away. I designed one list view with clear status tabs so status became a fact anyone could look up.
3,200-plus contracts, filterable by status and searchable by customer, LOF ID or account, replacing the informal tracking that used to live in someone's spreadsheet or memory.
Negotiation, moved into the portal itself
Negotiation used to run over email and phone with no shared record. I moved it into the existing customer portal, where a customer comments directly on a clause, and that routes to an approval queue internally.
Inline comments sit next to the exact clause they reference, with approval cards showing who accepted or rejected each point, so negotiation history lives with the contract instead of scattered across email.
A complete, ready-to-sign contract, generated directly from the structured data entered across every step above, no manual assembly required.
From scattered documents to one system
No formal usability metrics were run in this window, so I'm framing this against what the module was built to fix.
Three things this taught me
No baseline data is still a starting point
Without a legacy system to reverse-engineer, going straight to the people doing the work by hand became the most reliable source of truth I had.
Pushing back on scope can be the design
Arguing to keep the onboarding prefill in, against the easier option of cutting it, was as much a part of this project as any screen I drew.
Enterprise density needs structure, not simplification
The data couldn't be reduced, so the job was making thirty fields feel like four, through grouping and progressive disclosure rather than removing anything that mattered.