N Admin
Product designer
Portfolio 2026Systems thinking
Workflow architecture
Product auditsHealthcare · Fintech
Education · Retail
Civic dataDelhi, India
28.6139 N
77.2090 E01

Paisalello: the brief asked for a CRM, the business needed an operational foundation

Case 03
Fintech
Product Designer
Full scope, web and mobile
4 months
Discovery, architecture, interface
Case 03 / Fintech

The brief asked for a CRM. The business needed an operational foundation.

(Asked for)A CRM for used-vehicle loans.
(Found)An operating foundation instead of digitised dysfunction: one record, three role-shaped products.
(Changed)Disconnected activities came together in one system, with each role seeing what its decisions need.
Role
Product Designer, full scope (web and mobile)
Methods
Workflow discovery, operational mapping, information architecture, role-based experience design, interaction design
Scope
The customer lifecycle, from first inquiry to final decision, across three roles
The evidenceFrom the workflow mapRoles, activities and stages02

The evidence

roles sharing one system, each with its own interface
3
activity areas the product is organised around
5
stages in the loan evaluation workflow
5
interconnected problems found in discovery
3
ContextUsed vehicle financingSales, managers, administrators03

The process worked. Until it didn’t.

Paisalello finances used vehicles. Loan decisions depend on customer verification, vehicle assessment, financial evaluation and documentation review, and every application involves several stages and people.

A sales representative could get customer details by call, WhatsApp or in person, and enter them into the system later.

Managers often had to reconstruct an application’s status by calling sales representatives and cross-checking their notes. A decision that should have taken hours took days.

  1. (01)CallsCustomer details, entered into the system later.
  2. (02)WhatsAppMore details, in a chat rather than a record.
  3. (03)SpreadsheetsPart of the process, kept outside the system.
  4. (04)System recordsFragmented, so status had to be reconstructed.
ApproachCustomer lifecycle, inquiry to decisionSales, management, administration04

Mapping the organisation before the interface.

I mapped the complete customer lifecycle, from first inquiry through evaluation to final decision, and how information moved between sales, management and administration. The workflow, not a list of CRM features, defined what the product had to support.

  1. 01Customer
  2. 02Vehicle
  3. 03Documents
  4. 04Credibility
  5. 05Decision
The turnFrom CRM to operational system05

Digitising a broken process doesn’t fix it. It makes the dysfunction harder to see.

So the product was organised around work, not data: acquiring leads, onboarding customers, conducting evaluations, making decisions and reporting outcomes, instead of customers, vehicles, documents and leads.

What was actually brokenThree structural problemsFound in the workflow06

What was actually broken

Diagnosis

Information existed, but it had no consistent home.

(001) Fragmented informationCustomer data sat across several channels, with no reliable source of truth.
(002) Disconnected rolesSales, managers and administrators needed different things, but the system treated them too similarly.
(003) Unstructured evaluationLoan assessment had no consistent sequence, ownership or visibility, so decisions were hard to compare or audit.
ImpactFour design decisionsWork, not data07

One operational system, shaped around each role.

  1. 01

    Organised around work

    The information architecture follows activities, from leads to reporting, not objects like customers and vehicles.

  2. 02

    Role-shaped interfaces

    Sales, managers and administrators share one system, but each gets the interface their decisions need.

  3. 03

    Evaluation as a workflow

    Defined stages from customer information to final decision, with progressive disclosure and explicit ownership.

  4. 04

    Staged lead capture

    A minimum set of fields creates the record, and the system tracks what is still missing.

What I learnedThe right problem is rarely in the brief08

What I learned

Digitising a broken process doesn’t fix it.

Structure applied to dysfunction only makes the dysfunction more permanent. The first job was diagnosis.

Access control is a design problem.

Role-shaped experiences are harder to build than one interface with visibility rules, but they feel coherent to every user.

The right problem is rarely the one in the brief.

The brief asked for a CRM. The real need was an operational foundation the organisation could build on.

Building a platform that fixes the surface while leaving the structure intact doesn’t solve the problem. It redecorates it.

Next caseCase 04 / Retail6 months09

Koala Living

Read the next case