This is a release I've been genuinely excited to ship. Fluent Support 2.3.0 is out now, and the headline is big: your helpdesk now speaks MCP.

What does that mean?

Fluent Support now ships a Model Context Protocol (MCP) server. In plain words, AI agents like Claude, Cursor, Codex, or any MCP-compatible client can now connect directly to your support data and actually work inside your helpdesk. No copy-pasting ticket threads into a chat window anymore.

And this isn't a read-only integration. We shipped 25 tools covering almost everything an agent does in a normal workday. Once connected, you can just talk to your AI assistant like this:

• "Catch me up. What's waiting on me right now, and is anything breaching SLA?"
• "Summarize ticket # 4521, check what this customer purchased, and draft a friendly reply."
• "Find all open tickets mentioning refunds, tag them 'refund-request', and assign them to Sarah."
• "How did we do last month? Average first response time, and who handled the most tickets?"

Triage, replies, internal notes, tagging, assignments, bulk actions, reports, saved replies. If you use WooCommerce, FluentCart, or FluentCRM, the AI even sees purchase history and CRM tags right in the ticket context, so it knows it's replying to a customer who bought your Pro plan two weeks ago.

Setup takes about five minutes. Go to Settings → MCP for AI Agents, flip the toggle, install FluentHub with one click (WordPress 6.9+), create an Application Password, and paste the generated config into your AI tool. Done.

Also in this release:

• Multi-Provider AI. The AI assistant is no longer OpenAI-only. Pick between OpenAI, Google Gemini, and Anthropic from the new AI Model Setup page.
• Commerce Workflow Conditions (Pro). Branch your automations on purchase history. Purchased Product, Purchased Variation, and Has Active License conditions for both FluentCart and Easy Digital Downloads. Perfect for routing tickets by product tier or enforcing SLAs by license type.
• CLI Migration for Zendesk and HelpScout. Two new WP-CLI commands to import your full ticket history, and both are resumable if a large import pauses midway.

Plus a solid round of bug fixes and security improvements. Full details and the complete changelog are here: https://fluentsupport.com/fluent-support-2-3-0/

Update from your dashboard, connect your AI tool of choice, and tell me what you ask it first. I'm really curious what workflows you'll build with this.

Happy supporting!

Our users complain they can't find their product quickly as the list isn't alphabetacised or searchable, one team has over 30 products important for reporting. If you could consider at least the option to have it alphabetacised, it would be much appreciated. Thanks for all the good work the dev's do!

The current way when you lose an agent is to delete them and then reassign their tickets to someone else.

Problem is you have no historical data on that users actions, ie. old tickets show the reassigned user as the one 'replying' etc. That's bad for auditing, and people being miscredited for their actions.

My workaround at the moment is to just take all the permissions off the user, and set their title to 'former agent'. Problem with this is their names still show in 'Assign Agent' so we have a heap of former agents filling up the list.

Would the developers consider an archive agent instead , you could make it so you can't archive if they have open tickets, meaning you need to go reassign those, then you can archive.

Thank you for reading ^_^

Over the last weeks I’ve been digging deep into FluentSupport email workflows and ran into a few limitations that surprised me.

Mainly around:

• Reply-all behavior (especially preserving original CC recipients)
• Adding extra CC recipients on replies
• Not receiving tickets if we are in CC
• Better handling of forwarded emails
• Inline CID image rendering (screenshots/newsletters staying visible inside tickets)
• Stricter thread matching (preventing unrelated emails with similar subjects from being merged)
• More transparent logging of inbound mail flow

I ended up building a bridge on top of FluentSupport using Postmark inbound webhooks instead of the native piping flow.

Important: not as a replacement of FluentSupport itself, but as a narrower and more controlled mail-routing layer.

We are still in testing mode

That gave me much better control over:

• mailbox routing
• threading logic
• reply-all recipients
• inline attachments/images
• debug visibility

My question to the community:

Do you recognize these limitations in real-world support setups?

And for the Fluent team:
Thanks for your answers so far in our private communication.

But still curious: Were some of these choices intentional (to keep complexity low), or are they simply not high-priority yet?

Fluent Support currently does not provide a setting to change date display from relative time, such as "2 hours ago" or "5 days ago", to an exact date and time.

It would be very useful to add an option for absolute date/time display, so admins can see the exact creation or update date and time of a ticket instead of relative time.

When people send me an email to my business inbox, is there a way to automatically turn that into a support ticket instead of me having to reply from my personal email?

Customers email me at support@myemail.com. I have that forwarding to my personalemail@myemail.com. Instead, I want it to create a ticket inside FluentSupport so I can have that history and use the features inside the plugin.

TIA

Hi,

I like to build sites locally on MAMP, and when ready, I migrate to Live.

I have 1 license for FluentSupport and even though I use a .local domain on my computer, it uses up the license. Is there no "dev/staging" separation allowing us to work how I do it?

Thanks

In the info/icons next to each ticket and in the 'sort by' filter, I'd like to be able to organise support tickets by 'date received'. So, support tickets that might have been raised 3 weeks ago or more could get my full attention to get sorted. I know we have 'waiting time,' but that was not what I'm after.

or... have I missed something? Does anyone else agree?

Please update the agree to t&c check on the checkout page to show the ✅ when one agree or a dot. Currently one cant tell when it is check or not check

Although the ticket status strings are present and translated in Loco Translate, they remain untranslated in the frontend.

The same is true in the backend, along with ticket priorities and time also.

Please fix this.

Shahjahan Jewel