Customer 360
Worked on LeadSquared's unified customer view from 0 to 1, for the agent who needs answers before the customer finishes speaking.
Context
Where this started
About six months into designing LeadSquared's ticketing tool, I spent a lot of time understanding how support agents actually work.
One thing kept coming up: The ticket showed the issue, but not the customer.
Agents had to keep leaving the ticket to understand context, history, or past interactions. It slowed them down and broke their flow.
That's where Customer 360 started — as a response to a pattern we kept seeing in real workflows.
Business context
- Customers used tools like Freshdesk, Zendesk, or Zoho separately for support
- LeadSquared was already strong on the sales CRM side
- The data existed — it just wasn't usable in one place
Opportunity
Bring customer context into the agent workflow, and extend LeadSquared into service in a natural way.
The person at the centre of it
Before jumping into solutions, we wanted to clearly understand who we were designing for and what a bad resolution actually feels like.
Priya, 29
Support Agent, Bangalore, BFSI.
It's 11:20 AM.
- A customer has been on hold for four minutes.
- He applied for a loan 12 days ago and hasn't heard back.
- Priya has five tabs open: CRM, Freshdesk, loan portal, WhatsApp, a tracking sheet.
- She's typing the same question into multiple systems.
- The customer is still waiting.
This wasn't a technology failure. The data existed. It was a visibility and speed problem, happening 40 to 60 times a day, per agent, across a 35-person team. The tools treated the ticket as the whole story. The customer was the story. The ticket was just one chapter.
Shift
Monitoring tickets
↓Anticipating customer needs
Shift
Data visibility
↓Decision support at the moment of resolution
Shift
Reactive resolution
↓Prepared before the first word
Discovery
Primary and secondary research
We spoke to support agents and team leads across 6 mid-sized companies, mostly in BFSI and EdTech, where LeadSquared was already being used on the sales side and teams were exploring service expansion.
Interview questions and what we heard
The aim was to understand the workflow end to end.
Q. Walk me through what you do from the moment a ticket comes in to the moment it's closed.
BFSI
Identify the customer, verify account, check product holdings, look for prior tickets then respond. That's 3 to 5 tool switches before a single word is said to the customer.
EdTech
Students contact support across email, chat, and calls for the same issue. Agents had no way to see that history without manually searching. Every ticket started from scratch.
Q. What information do you look for most often that takes too long to find?
BFSI
Loan application stage, EMI status, KYC completion — the three most frequently cited pieces of information agents had to leave the ticket tool to find.
EdTech
Course enrollment status, batch details, fee receipts, and whether a previous support promise had been made and not honoured.
Q. What makes a ticket harder to resolve than it should be?
BFSI
Fragmented tools, no visible customer history, and no direct action path. Knowing what to do but having to navigate away to do it was the biggest time sink.
EdTech
Repeated contacts from the same student with no way to track what was already promised. Agents over-apologised because they had no continuity.
Q. What does a really good resolution feel like compared to a bad one?
Both
Agents consistently described good resolutions as ones where they felt prepared before the conversation. When an agent could say "I can see your loan application is in the verification stage" before the customer had to explain anything, the customer's tone changed immediately. Bad resolutions happened when agents were visibly searching. Customers could hear it.
Q. Which tools do you use today, and what's the best and worst thing about them?
BFSI
Freshdesk for tickets, LeadSquared CRM for customer info, separate portal for product data. Best: each tool works for its job. Worst: they don't talk to each other.
EdTech
Zendesk and the LMS separately. Agents switched tabs constantly. The CRM had customer data but wasn't visible during a ticket. They wanted everything in one place, not one more tab.
Workarounds at this scale: sticky notes on monitors, WhatsApp groups with team leads, personal escalation spreadsheets — to try to do just the basics of their jobs.
Define
Who we were designing for
Two distinct user types emerged, each with a different relationship to the product and different definitions of success.
Radhika
35 · Technical Support Specialist
Switches between 4+ applications to resolve a single query
System lag during peak hours adds anxiety to every interaction
Identifying and verifying the customer delays first response
No contextual help when stuck on an unusual ticket type
Aman
37 · IT Admin / Service Configurator
Every configuration change requires back-and-forth with the service provider
Documentation is rarely available or current
No way to preview what agents see before publishing a layout
Integration updates risk breaking something without warning
After interviews, we had a lot of raw observations. The goal wasn't to list them — it was to translate each one into a clear product decision. Every widget needed to solve something real.
Some features which were good but failed impact effort analysis were to be picked in phase 2:
- AI-Suggested Layouts
- Cross-Sell Nudges
- Omnichannel Interaction History
- Export to PDF
Design
How the design actually moved
1
Observation from ticketing tool
Foundation
2
Stakeholder framing
PM + Director
3
User interviews
Companies
4
Synthesis + widget mapping
Insight → Feature
5
Entry point decision
First design call
6
Low-fi explorations
4 hypotheses
7
Hi-fi + heuristic + handover
Delivery
Designs had to be made considering the agent works in a high pressure environment and on machines that are not very powerful.
Some trials and sketches made at that time:
Early lo-fi sketches
The entry point decision
One of the important decisions was to decide the entry point to Customer 360.
Ticket detail page:
Persistent CTA on ticket detail to launch Customer 360
The Uniform Grid
Rejected
If every widget is the same size, agents can scan without learning a layout.
Why failed: Agents didn't scan equally. BFSI agents needed product holdings and account tier first. EdTech needed enrollment status. Equal prominence forced search.
Fixed Industry Templates
Rejected
If we pre-define the optimal layout per industry, agents never think about configuration.
Why failed: Broke down for edge cases. A BFSI agent handling a complaint needed a different hierarchy than one handling a loan query. Fixed templates felt imposed.
Configurable Canvas with Runtime Layout Switching
Chosen
If the admin defines the information hierarchy per use case, and agents switch between layouts at runtime, the layout does the cognitive work so the agent doesn't have to.
Solution
One for the agent resolving in real time. One for the admin configuring once for many.
The layout the agent sees is entirely determined by the admin's configuration. Widget hierarchy, actions, and content reflect the ticket type. Agents switch layouts at runtime without touching admin settings.
Final agent-side Customer 360 view
Some of the UI explorations that led to final design:
V-1
V-2
V-3
V-4
Final
Widget Listing
All available widgets browsable and selectable for layout configuration.
Widget Configuration
Detailed configuration options per widget type — toggle fields on/off, reorder, rename.
Layout Tab
Admin-side layout listing with all configured views and their assigned ticket types.
Layout Configuration
3-step admin process to configure layouts per industry — BFSI, EdTech, Fintech.
Data Source Tab
Connecting external data sources to populate the unified view — no engineering required.
Craft
Edge cases, errors, and the details that make it trustworthy
User Education
Informing users about system state instead of leaving them confused — confirmations, error messages with clear actions.
Consistency
Standards maintained across all flows and states throughout the platform.
Error Prevention
Clear recovery paths when errors occur — skeletal loaders for loading states, cancellation flows.
Help & Documentation
Contextual support throughout, reducing time-to-resolve for new admins and agents.
Error state illustrations
Error States
Skeletal Loaders
Data-driven testing via Microsoft Clarity provided heatmaps and session recordings to understand real agent behaviour post-launch. Pendo enabled in-app guides and A/B testing in focus groups, helping iterate on the configuration flow for admins.