Freshdesk · Omnichannel framework · 2025
Building a foundation, not another channel
I designed the modular framework — admin setup, agent inbox, platform rules — that brings live messaging channels into one Freshdesk workspace. A new channel inherits the system instead of inventing its own.
- Role
- End to End Product design
- Partners
- Product · Platforms · Design System · Admin · Agent Experience
- Timeline
- Facebook, WhatsApp, Instagram, Mobile SDK, SMS · Apr–Dec 2025
- Channels
- 5 built on the framework, 4 shipped
At a glance
Problem: Freshdesk and Freshchat were sold as one suite but worked as two. Agents switched products to serve one customer, and every new live channel shipped its own zero state, config pattern and editor.
Approach: I audited the full admin-to-agent journey through Facebook — our largest, messiest channel — then designed one modular framework instead of another one-off redesign: fixed interaction rules, a configurable channel skin.
Result: Facebook active usage nearly tripled (8.2% → 23.7%). WhatsApp setup completion reached 75.21%, up from a drop-off rate above 40%. Five channels shipped on the same foundation without redesigning the suite.
- 8.2% → 23.7%
- Facebook active usage, over the first six months
- 75.21%
- of Unified Freshdesk accounts completed WhatsApp setup — 446 of 593
- 40% → 24.79%
- drop-off during WhatsApp integration
- 5 channels
- built on the framework; 4 shipped
Who this was for
Two roles used what I designed, every day:
- Admins — usually a support-ops lead — who discover, connect, configure and manage a live channel so their team can start working tickets from it.
- Agents who identify, prioritize and reply to tickets from any live channel inside one inbox, without learning a new pattern per channel.
The scale behind that: 46,234 Freshdesk accounts and 1,728 Freshdesk Omni accounts at baseline, with Facebook alone carrying 8,056 Freshdesk customers and 2,806 Freshchat customers. Thousands of customers now run their live channels on the unified product.
Read full case study
Sold as one product, architected as two
Freshworks has shipped three versions of omnichannel:
- 2019, Freshdesk Omni channel: Facebook and WhatsApp as live channels, and everything else async, all inside Freshdesk.
- 2023, Customer Service Suite: After COVID, demand for live chat surged. Freshworks bundled Freshdesk (async) and Freshchat (live) and sold them as one suite.
- 2025, Unified Freshdesk Omni: Every channel lives inside Freshdesk.
The suite looked unified on the pricing page but not in daily work. Agents switched between two products to serve one customer, and churn on the suite traced directly back to that friction. The company decided to consolidate into Freshdesk because it has the largest customer base.
That decision created three stakes:
- Business: Competitors already offered live channels inside one workspace, and upgraded suite accounts were churning when the unified promise broke in daily work.
- User: Agents lost focus switching tools. Admins configured and tracked support across two systems for one account.
- System: Live channels had no shared foundation. Every launch risked another one-off admin flow and another agent inbox variant.
Baseline adoption of live channels was low:
| Surface | Accounts | Facebook adoption / usage | WhatsApp adoption / usage |
|---|---|---|---|
| Freshdesk | 46,234 | 10.2% / 1.1% | 1.1% / 0.8% |
| Freshdesk Omni | 1,728 | 13.3% / 8.2% | 1.0% / 1.0% |
Facebook shows what the old setup cost. It had 8,056 customers in Freshdesk and 2,806 in Freshchat. Engineering maintained the Freshdesk integration as a separate app, so Meta rejected it often and it needed manual fixes.
The real problem was the next channel, not this one
Moving channels into one product removed the switching. It didn't answer how to build these channels, or how to make them feel good to use. Web chat, Facebook and WhatsApp each looked and behaved differently, and Instagram, SMS, Apple Messages for Business and Mobile SDK didn't exist in Freshdesk yet.
Rather than asking how to add more channels, I reframed the challenge around a scalable, consistent multi-channel foundation. That changed what we optimized for: reuse, compliance, and admin and agent parity, rather than feature parity for each channel.
- How might we add new channels without creating more inconsistency?
- How might we add future channels without redesigning everything? If a channel ships an improvement three months after another, we shouldn't have to hand-port it back into every other channel.
- How might we create one consistent experience for agents and admins across all channels? The agent's job is to resolve the ticket. Channel-specific behavior only gets in the way.
What customers were telling us
We had an advantage competitors didn't: years of support tickets from our own customers, resolved by our own agents. I analyzed 337 evidence records from Freshdesk and Freshchat tickets and community feedback about channels.
| Theme | Evidence | Customers | ARR attached |
|---|---|---|---|
| WhatsApp integration and configuration | 66 records (20%) | 69 | $2.95M |
| Social channels (Facebook, Instagram, Line, TikTok) | 36 records (11%) | 41 | $1.32M |
| Freshdesk ↔ Freshchat setup and drop-off | 33 records (10%) | 36 | $990k |
| Unsupported message types and media | 32 records (10%) | 33 | $1.29M |
| Pre-integration and channel discovery | 30 records (9%) | 33 | $591k |
| Channel configuration complications | 26 records (8%) | 23 | $1.82M |
A few signals shaped the design directly:
"I've been trying to integrate WhatsApp Business for over 2 months and it's been impossible."
Customers said setup was "too complicated," with conflicting documentation, unclear prerequisites and no guided onboarding.
- Facebook DMs sometimes failed to appear as tickets. Classic omnichannel allowed only one Facebook page, and the V2 migration blocked re-integrating pages that had been connected before.
- Images, voice notes and quoted replies weren't visible to agents. One customer called missing quoted replies a "blocker for rollout."
- When a customer had used multiple channels, agents sometimes saw the wrong reply editor. For example, a WhatsApp template selector appeared on a web chat conversation.
- The Apple Messages for Business entry point was only an "I'm interested" button with no setup flow behind it.
Competitors (Zendesk, Intercom, HubSpot and Salesforce) had already proved the pattern: a unified inbox, centralized admin and source-aware agent UI. But their support was uneven. Zendesk handles Facebook DMs and comments as separate tickets, and agents can't reply to a comment ticket by DM. Intercom doesn't support Facebook comments at all. Our job was a Freshdesk-native foundation that matched that baseline and went further where our ticket data showed demand.
I audited the experience through one channel: Facebook
I mapped what an admin and an agent actually do. The admin discovers a channel, connects it, configures it, and manages it so agents can resolve faster. The agent identifies a ticket, understands the context, and replies. Then I audited every step on Facebook, the channel with the largest base and the most message types (DMs, comments, ad comments and visitor posts).
Admin experience
Zero state: Every channel's zero state looked and behaved differently. Facebook's was a wall of text that caused banner blindness and pushed admins into trial and error.
Integration: The Meta permission window replaced the Freshdesk setup page. If an admin clicked "Not now," they were stranded outside the product.
Integration list: Pages were shown as cards, which was fine for one page and broken for many. That was risky for number-based channels like WhatsApp.
Configuration: Settings were text-driven and up to four levels deep. Changing a child setting sometimes affected the parent.
Agent experience
Ticket list: Comments, posts and messages each created tickets, and they shared one monotone icon. Agents couldn't triage at a glance.
Ticket details: Navigation was built for async email. Live conversations are bursts of short messages, and they arrived ungrouped.
Message types: Stories, audio notes, reactions, quoted replies, read receipts and unsent messages weren't supported.
Reply editors: Facebook messages and Facebook comments each had their own editor. On comment tickets, the editor appeared twice on the same page, once for a general comment and once for replying to a specific comment.
Comment hierarchy: There were two different threading approaches in ticket details.
What I found: the inconsistency was structural. Each channel brought its own workflow, its own editor and its own configuration pattern — this wasn't a Facebook problem, it was a foundation problem.
Insights became principles, and principles became design bets
| Insight | Principle | Design bet |
|---|---|---|
| Each channel brought its own workflows, editors and config patterns | Consistency | Shared admin listing and an adaptable configuration page across live channels |
| Live channels break async mental models. Fragments, compliance rules and editor states differ by channel | Live-channel compliance | Unified reply editor behaviors and comment hierarchy in ticket details |
| Setup friction kills adoption before the business sees value | Scalability | A prerequisites flow and a zero state with guided integration (video and CTA) |
| Admins and agents asked to keep what already worked in Freshdesk and Freshchat | Retain what works | Selective parity: carry forward proven Freshchat patterns without cloning Freshchat wholesale |
The framework: fixed interaction rules, configurable channel skin
| Layer | What it standardizes | Modules | Fixed vs flexible |
|---|---|---|---|
| Admin setup | How admins discover, connect, configure and manage channels | Zero state, prerequisites, scalable listing, config page templates | Fixed: flow stages and layout grammar. Flexible: channel copy, permissions, compliance fields |
| Agent inbox | How agents identify, prioritize and respond across channels | Source icons, reply editor behavior, comment hierarchy, channel switching | Fixed: inbox primitives. Flexible: editor capabilities for each channel's API |
| Platform rules | Principles and constraints every channel must pass | Consistency, scalability, compliance, parity | Fixed: a review gate for new channels. Flexible: phased parity |
In practice, the configuration page always has anchor tabs on the left for navigating the page, but each channel decides which tabs it needs. Engineering can switch sections on or off per channel instead of building them.
Key decisions
Seven decisions carried the framework from principle to shipped product. Each one traded a local win for consistency across the whole suite.
Decision 1 of 7
Fix the flow and the layout. Let the channel own only its skin.
In short: One integration flow and one config layout for every channel — only branding, copy and compliance fields change per channel.
Tension: Bespoke layouts let each channel team ship faster, but every bespoke layout adds another thing for admins to learn.
Options considered: Let each channel design its own setup; force one rigid template; or fix the interaction rules and let channels configure the surface.
Chose: The integration flow and layout are the same for every channel. Branding, copy, compliance fields and the configuration anchor tabs change per channel.
Because: Admins shouldn't face a new learning curve, in behavior or visuals, each time they add a channel.
Evidence: The audit found different zero states on every channel and configuration up to four levels deep. The config template was validated on the Facebook redesign, then reused for WhatsApp and Instagram with compliance-specific field sets.
Cost: Channel teams lost some freedom to customize.
Pushback: Some channel teams wanted bespoke layouts. I kept customization inside defined template regions so the foundation stayed recognizable across channels.
Decision 2 of 7
Teach before handing off to Meta
In short: A zero state that explains and shows, then a prerequisites step that stays inside Freshdesk before the Meta handoff — so admins arrive at OAuth ready, not stranded.
Tension: Every extra step before OAuth looks like friction, but admins were reaching Meta's permission screen unprepared.
Options considered: Send admins straight to OAuth; link out to documentation; or add a short prerequisites step inside Freshdesk.
Chose: A consistent zero state with a two-line explanation, a 30-second video and one primary CTA, followed by a prerequisites popup that stays inside the Freshdesk shell before the Meta handoff.
Because: When the OAuth window replaced the setup page, "Not now" left admins in limbo. WhatsApp raised the stakes: a business can have several business accounts, each with several numbers, and a number may already be in use elsewhere. Admins needed to know that before they started, not after an error.
Evidence: 33 records on integration setup and drop-off, 66 on WhatsApp setup, and the "over 2 months" quote. The Facebook PRD specifies the prerequisites as a popup on the same screen rather than a new window.
Cost: It adds a step before the happy path, and each channel needs its own content: copy, articles and a video. I optimized for completed integrations, not the shortest flow on paper.
Result: On WhatsApp, integration drop-off fell from above 40% to 24.79% between launch and August 2026: 446 of 593 accounts (75.21%) completed setup. The prerequisites pattern became the default entry point for OAuth-based channels and informed the Mobile SDK consent flow.
Decision 3 of 7
Replace cards with a list that scales, and make removal reversible
In short: A shared, searchable list module replaces one-off cards, and disabling a page is reversible instead of destructive.
Tension: Cards look approachable for one page, but a business can connect up to 50 Facebook pages.
Options considered: Keep the cards; paginate the cards; or use a list-first page.
Chose: A shared listing module with source info, an enable/disable toggle, Configure, remove with confirmation, and search once there are more than eight pages.
Because: Admins need to find a page and act on it without scanning cards. The toggle is a soft delete: an admin can pause incoming tickets from a page without removing the integration.
Evidence: In the audit, delete actions had no confirmation, which created a risk of accidental data loss.
Cost: The page looks less like marketing and more like an operational tool. That's the right trade for admins managing five or more handles.
Reuse: Every live channel's admin surface uses the listing module. New channels add their columns through configuration instead of redesigning the page.
Decision 4 of 7
Split one channel into two sources so agents can mute the noise
In short: Facebook and Instagram each split into Messages and Comments as separate, filterable sources — so volume doesn't bury the conversations that need a reply.
Tension: One channel as one filter is simple. But Facebook comments are mostly repetitive, and bundling them with DMs buries the conversations that need an agent.
Options considered: Keep one "Facebook" source; treat comments as a separate channel; or keep one channel with two sources and give admins filtering controls.
Chose: Two sources, Facebook Messages and Facebook Comments, applied to channels with public comments (Facebook and Instagram). Admins can convert all comments or only those with page mentions or specific keywords, and choose between one ticket per comment or all comments threaded under a single post ticket. Source info is stored as "Channel - Source info," so automations, SLAs and analytics can target an individual page.
Because: 82% of Facebook customers had comments enabled, but 55% of Freshchat accounts used DMs only. Customers wanted comments available without having them flood the inbox.
Evidence: The audit's "discovery overload" finding for the ticket list, and the Facebook usage data in the PRD.
Cost: It adds more filter UI to an already dense inbox. In exchange, agents keep one inbox and control their own queue.
Reuse: The filter model extends as each channel launches. New sources appear as filter options without an inbox redesign.
Decision 5 of 7
One reply editor with channel-aware modes
In short: One editor family for every channel, with modes instead of separate editors — Reply as message, Reply as comment, Email.
Tension: DMs and comments follow different platform rules, and Freshdesk's async editor couldn't meet either set.
Options considered: Keep a separate editor for each message type; copy Freshchat's editor; or build one editor family with modes.
Chose: A single editor with channel-aware modes: Reply as message, Reply as comment and Email. It includes compliant disabled states, explicit switching rules and a recipient summary showing where the reply will go. Clicking Reply on a comment auto-tags the customer's handle, and the reply posts as a child comment.
Because: The agent's goal is to resolve the ticket. If the editor changes shape with the channel, the agent has to relearn it.
Evidence: The audit found the comment editor appearing twice on one page. The ticket data included a "reply editor channel mismatch" that blocked agents from replying.
Cost: Editor rules grew complex. There are 7-day DM windows, image-only attachments on comments, one DM per comment, and different character limits for DMs (20,000) and comments (8,000).
Differentiator: Handle tagging in comment replies lets businesses reply personally. None of the competitors we reviewed offered it.
Reuse: I documented editor compliance as a module that channel teams deliver against. Instagram and later social channels reused it.
Decision 6 of 7
Show comments the way the customer saw them on Facebook
In short: Ticket details mirror Facebook's own two-level comment model instead of a flat transcript, so agents can see what a reply is actually responding to.
Tension: In ticket details, comments arrived as flat fragments. A compact transcript saves space, but agents couldn't tell which comment a reply belonged to.
Chose: Two-level nesting that mirrors Facebook's own model (a parent comment and its replies). Each comment carries a label next to the customer name, either "Commented on a post" or "Replied to a comment." Tickets show an inline post preview with "View post on Facebook," three sort orders, and three comments by default with "View replies" to expand.
Because: Without the thread structure, the agent was missing context.
Cost: It takes more vertical space in ticket details. I optimized for comprehension on high-volume social tickets.
Decision 7 of 7
Ship trustworthy core fragments first
In short: Ship the message types that carry most of the volume; hold back reactions and quoted replies for a fast follow rather than delay the whole foundation.
Tension: Parity with Freshchat meant every message type. The foundation had to ship reliable core patterns first.
Chose: Ship stories, audio, GIF, video, images, unsent and "content unavailable" states, and delivery failures. Images are cropped to a 1:1 square, as Facebook and WhatsApp do, so several can be grouped consistently. Reactions and quoted replies were descoped from v1.
Because: Reactions and quoted replies were less likely to be used than the other fragments, and the foundation needed trustworthy core patterns before expanding parity.
Cost: One customer called quoted replies a "blocker for rollout." Descoping them was a deliberate bet against a real signal, and it is a candidate fast follow.
Drag to explore
The hardest moment: two Facebooks in one Channels page
The new Facebook channel belonged to the Platforms team. Legacy Facebook belonged to the Freshdesk team. Moving ownership fixed the Meta rejections, but migrating existing integrations across the two systems turned out to be technically impossible.
We had almost overlooked migration and had very little time left. The options were to break existing customers or accept an inconsistency. I designed a coexistence and deprecation experience:
- Legacy Facebook stays on the Channels page with a "Legacy" label next to the new Facebook channel.
- Admins are told that the legacy channel will be deprecated.
- Admins are guided to connect the same page to the new channel before that happens.
- Legacy is then retired, and all customers move to the new version.
This decision knowingly broke the consistency principle for a while. Two entry points for the same channel is not what the framework is for. But it protected customers who already relied on Facebook in production, and it made the path forward explicit.
What stayed flexible
Channels still differ where the platform requires it:
- Branding, copy and the onboarding video.
- Compliance fields and permissions (Meta business accounts, WABA numbers, page limits).
- Which configuration sections and anchor tabs appear.
- Editor capabilities allowed by each channel's API (attachments, windows, formatting).
- Supported message fragments.
Everything else — the flow, layout, listing, source identification, editor behavior and hierarchy — is fixed. That split is what lets channel number five avoid redesigning channel number one.
Edge cases were treated as product behavior
On Facebook alone, the designs cover:
- The 7-day DM window. DM replies are disabled with an explanation, and Email is offered if the contact has an email address.
- Access revoked and handle disabled, with banners and editor messaging.
- The 50-page limit, including a batch that would exceed it.
- Pages that are already integrated appear disabled in onboarding.
- A toast for every mix of success and failure when integrating several pages.
- Trial accounts are limited to one page.
- A failed message splits its cluster, with the error shown directly beneath it.
- Unsent messages and expired or hidden stories show "Content unavailable."
- One DM per comment, with a banner until the customer responds.
- Downgrade: replies are disabled, the integration is deleted after 14 days, and it revives on upgrade or reconnect.
- The DM and comment character limits.
Trade-offs and descoping
- Two Facebook channels for upgraded customers, caused by the change in ownership (see above).
- Reactions and quoted replies were cut from v1 to protect the core fragment set.
- Apple Messages for Business was put on hold after the design was delivered. The mocks were ready and the channel would have been quick to deploy, but it was held back by roadmap conflicts and low demand. The few customers who wanted it already used it in Freshchat and would have had to upgrade their whole product to use it in Freshdesk.
Going beyond the assigned scope
- Mobile: After layoffs removed the mobile design team, I defined the mobile experience for these channels.
- Onboarding videos: Five channels needed zero-state videos at once, which would have overwhelmed the video team. I wrote the scripts and built storyboards and audio with Google's video tools, then coordinated the visual design, video and technical writing teams.
- Migration: I designed the Facebook coexistence and deprecation experience under a compressed timeline.
Outcome
| Metric | Design lever | Effect |
|---|---|---|
| WhatsApp setup completion: 75.21% (446 of 593). Drop-off above 40% → 24.79% | Prerequisites and zero-state guidance | More admins finish setup, and agents see live tickets sooner |
| 5 channels built on the framework, 4 launched | Modular admin and agent patterns | New channels ship without redesigning the suite |
| Facebook active usage: 23.7% of accounts (8.2% before) | Unified inbox, source identification and reply editor | Agents keep social tickets inside Freshdesk |
| Thousands of Freshdesk customers | Facebook migration experience | Upgraded suite accounts keep their value instead of juggling two products |
Note: the WhatsApp setup numbers (593/446) and the 1,716 usage figure are different scopes and windows by design — WhatsApp only vs. all channels, and since launch through August 2026 vs. the first six months after launch — not the same population.
Facebook is the most-used framework channel, and its usage skews higher outside the US: about 27–29% of accounts in EUC and APMEA use it, against 20% in the US.
The framework's value shows in reuse. Facebook and Instagram shipped first, and WhatsApp, SMS and Apple Messages for Business inherited the zero-state module with only the media and copy swapped. The Facebook configuration template carried over to WhatsApp and Instagram. Source identification became a gate: no channel launches without all four touchpoints (listing badge, Quick List View snippet, subject header and reply editor context) built to the shared spec.
Reflections: what this taught me about platform design
- A framework only compounds when adoption is a success metric from day one, not something you hope for after launch.
- Compliance constraints are design inputs, not exceptions. Documenting them early prevents rework across channel teams.
- The hardest alignment work is saying no with a principle. Descoping reactions was right for v1 because the foundation had to ship trustworthy core patterns first.