A Freshchat desktop app: chats where you will not miss them

The search for a Freshchat desktop app almost always starts with a missed conversation. A chat came in, the browser was on a different window, and the notification either never appeared or appeared behind something else. By the time anyone noticed, the customer had left. That is a different problem from wanting a nicer interface, and it has a different answer. Freshworks does not publish a desktop application for the agent side of Freshchat, and the fix is to stop running the inbox as one tab among thirty.

What Freshworks publishes for Freshchat

The mobile side is clear. The App Store carries Freshchat, published by FRESHWORKS TECHNOLOGIES PRIVATE LIMITED, free to install, requiring iOS 15.0 or later. The same company publishes Freshdesk alongside it with the same platform requirement.

The compatibility blocks on those listings name iPhone and iPad. They do not name macOS. On Apple silicon a developer can opt to make an iPad build available on the desktop, and the listing states that when it happens. Neither listing does, and there is no separate release in the Mac App Store, so the agent console on a laptop is reached through a browser and nothing else.

That is the ordinary shape for a shared inbox product. The console has to show the same queue to every agent at the same moment, with routing and assignment decided on the server, and a browser keeps that consistent without shipping native builds for three operating systems. Nothing about the console is missing on a Mac. It simply lives in a tab.

Catalogue sites complicate the picture by listing the product under headings like desktop app for Mac and Windows. What those sites offer is a browser window they package themselves. It is not built or supported by Freshworks, which matters when the thing being logged into holds customer conversation history.

Why the search is really about notifications

Web notifications are granted per origin, to a browser, and they only fire while that origin is loaded. In practice that creates four failure modes during a shift.

The first is the closed tab. An agent tidies a crowded window, the console goes with it, and the queue keeps filling silently. The second is the quit browser. Closing the browser at lunch stops every notification until it is reopened and the console reloads. The third is the wrong window. On a machine with three browser windows open, a notification click brings one of them forward and the right tab still has to be found. The fourth is the unread count, which lives on a favicon a few pixels wide rather than anywhere glanceable.

None of those is a defect in the console. They are what happens when something that must run for eight hours is placed in a container designed for a few minutes. Putting the console in its own window closes all four at once, and Apple documents the specific behaviour that matters most.

For websites that send notifications, the web app's icon in the Dock can show the number of unread notifications. Source: support.apple.com

A count on a Dock icon is the difference between noticing a queue building and finding out about it in a report the next morning. It is also what makes the console visible to someone walking past the desk, which matters on a small team where one person covers chat between other tasks.

Where the download pages lead

Results for this query include pages that look like installers. They sort into three kinds, and telling them apart is quick once the pattern is known.

The first kind is emulator instructions. These explain how to install an Android emulator on a laptop and then run the mobile build inside it. It works, and what appears is a phone interface stretched to desktop size with a second operating system underneath it. For a console that has to notify reliably for eight hours, that is a large amount of machinery in exchange for a cosmetic change, and notification behaviour inside an emulator is the first thing to break.

The second kind is catalogue sites. Several of them list the product with a heading naming both Mac and Windows, because the site packages a browser window of its own and offers it as a download. Nothing about that package comes from Freshworks, and the login typed into it is going somewhere unannounced. For a tool holding customer conversation history, that is worth pausing over.

The third kind is community code on GitHub. Individuals build wrappers for the products they use daily, publish them, and sometimes keep maintaining them. The question to ask of any of these is who repairs it when a browser update lands, because browser updates arrive every few weeks and a wrapper that points at a fixed copy of the browser stops launching when the copy moves.

The useful observation is that all three are attempts at the same thing. Each one is trying to take a web console out of a tab and put it in a window with its own icon, its own notifications and its own session. That goal is correct. Only the method varies, and the methods differ mainly in who is responsible for keeping the result working next month.

There is also a separate matter these pages tend to blur. The widget that customers chat through and the console that agents answer from are different things, and neither an emulator nor a wrapper changes anything about the widget on a website.

What a tab costs a support shift

The costs are specific enough to list.

Behaviour	Browser tab	Standalone window
Keeps notifying after the research browser is quit	No	Yes
Unread count visible at a glance	Favicon only	Dock badge
Reachable by name in Command+Tab	No	Yes
Reopens on the conversation queue	New tab page	The address it was built from
Closed by accident along with other tabs	Often	Rarely
Session separate from general browsing	Shared with the profile	Isolated per app

Session isolation deserves a note of its own. An agent console signed in through the same browser profile used for everything else inherits that profile's cookie clearing, privacy extensions and sign in state. A password manager set to purge on quit, or a privacy extension trimming storage, will log an agent out mid shift. Isolating the console means those settings stop reaching it.

There is a performance angle too. A browser holding a live websocket connection to a conversation queue, alongside thirty other live pages, is doing more work than it needs to. When the machine slows down, the only available fix is closing the browser, and that cannot be done while the console is inside it.

Two free routes on a Mac, and where each stops

Safari has the feature built in from macOS Sonoma 14 onward. Open the console, choose File then Add to Dock from the menu bar, give it a name, and confirm. It is saved to the Applications folder inside the home folder and opens from the Dock or Spotlight. Notification permission is then granted to the window rather than to Safari, which is what enables the badge.

Chrome has an equivalent. Open the console, use the menu at the top right, choose the cast, save and share group, and pick the option to install the page as an app. Google's help describes the result as opening from the launcher or home screen, with notifications and icon badges available to some apps.

Both routes take about a minute and cost nothing. Both share the same ceiling. The window is bound to the browser it was created in and to the profile that browser is signed into. Safari limits which extensions travel with it. Chrome brings the entire profile along, including every other account signed into it, which is the wrong outcome for a console holding customer records.

That ceiling is where a purpose built tool matters. Choosing the browser engine, deciding which extensions load inside that one window, and getting a genuinely separate profile per application are configurable choices rather than defaults, and the Features page sets out which ones exist. Anyone who wants to check whether a service is already covered before setting it up will get there faster through the Supported services list.

Running more than one inbox at once

Support teams rarely have one console. There is the live chat queue, there is the ticketing side, and on agencies there is a second client's account entirely. In a single browser profile those compete, because one session cookie per domain means signing out of one to reach the other.

Separate windows with separate profiles remove that competition. Two accounts on the same domain can be signed in at the same time, each in its own application, each with its own notifications. For an agency covering several clients, that turns account switching from a repeated chore into three icons in the Dock.

The same arrangement helps with roles. A supervisor watching the availability dashboard and an agent working the queue are looking at different screens for long stretches. Two windows hold both, and neither has to be rebuilt each time attention moves.

A practical note on placement. Assigning the console window to one desktop space, with the research browser on another, makes the switch between answering and looking something up a single keyboard shortcut. That is impossible while both live in the same browser window.

What the plan decides, and what a window does not

Pricing sets the boundaries, and a window changes none of it. Freshchat lists a Free plan at $0 for up to 10 agents, then Growth at $19 per agent per month, Pro at $49 per agent per month, and Enterprise at $79 per agent per month, each billed annually. Freddy AI Copilot is listed at $29 per agent per month, and Freddy AI Agent includes the first 500 sessions with additional sessions at $49 per 100. Day passes are priced per plan at $2, $7 and $12.

Feature gates follow the same logic. The chat widget, the team inbox and email are on every plan including Free. Social messengers and text messaging channels start at Growth. Multilingual conversations, covering over 45 languages, and custom dashboards start at Pro. Skill based routing and audit logs are Enterprise.

Two things follow from that. Agent seats are billed per agent, so building three windows for one person does not create three seats and does not add cost. And nothing in a window unlocks a channel that the plan does not include, because channels are account level settings.

What to change first

Give the agent console its own window today, using Safari or Chrome, and grant notification permission inside that window rather than in the browser. Work one full shift with it before changing anything else, because the value shows up in the conversations that no longer get missed rather than in how the console looks. When a separate profile per account, a specific browser engine or per window extensions start to matter, Kagemusha is where those are chosen.