Goal

Your users need a way to reach your team without leaving the app, and your team needs a place to hear them and answer. By the end of this guide, your app will have a dedicated support-chat button: a user taps it and lands in a private conversation with whichever admins you’ve chosen, and every message they send pings those admins with a push notification so they can reply straight from their own thread list.

This whole setup is no-code. You install one plugin, fill in two fields and a checklist on a settings page, and drop one button into your app’s navigation — no theme edits or custom code needed.

What you’re building

MAM Suite’s chat feature (built on the mam-chat-manager plugin) actually covers several kinds of in-app messaging. This guide zeroes in on support chat — the built-in channel that connects an app user to your admin team.

It comes together from two pieces:

• A Chat Settings admin page where you choose the admin display name, the avatar users see, and which WordPress administrators participate in support.
• A support-chat button you place in your app’s navigation. When a user taps it, the app opens (or creates) a thread tied to your admin team.

Behind the scenes, the plugin keeps a single “admin chat group” made up of whichever admins you’ve ticked, and gives each app user their own private thread with that group. That’s what makes support feel one-on-one to the user, even though any ticked admin is free to jump in and answer.

Prerequisites

• WordPress admin access (the activate_plugins capability)
• MAM Suite installed, with MAM Main activated under Mobile App Manager → Software
• A MAM Suite plugin entitlement that includes the Chat Manager
• A short list of which administrators should answer support chat — usually a subset of your site’s admins, not all of them
• At least two test app users. Chat is a two-party feature, so you can’t fully smoke-test it from a single account.

Step 1 — Turn on chat

Chat won’t do anything until the plugin is running, so start there. Go to Mobile App Manager → Software and find the Chat Manager plugin in the list. Choose Install and Activate from the action dropdown and apply.

Once the page reloads, look for two new entries in the Mobile App Manager sidebar:

• Chat Settings
• Chat History

Don’t worry if they’re missing — that almost always means the entitlement check is failing, since chat only lights up when your MAM Suite entitlement includes it. There’s no separate on/off switch to hunt for either; the plugin is simply on whenever it’s active and entitled.

Want the fuller walkthrough, activation plus a basic two-user smoke test of chat in general? See the related Enable chat recipe.

Step 2 — Choose who answers support chat

This is where you decide who’s actually on call. Open Mobile App Manager → Chat Settings.

The page lists every WordPress user with the administrator role, each with a checkbox — tick the admins who should be reachable through support chat.

Here’s what ticking an admin actually does:

• Only ticked admins receive a push notification when a new support message arrives.
• Only ticked admins’ replies appear under the display name and avatar you configure below.
• Saving rewrites the support group’s membership to match your selection. Unticking an admin removes them; ticking a new one adds them. Existing conversations pick up the change on the next refresh.

Gotcha: save with zero admins ticked, and you get a support channel nobody’s actually watching — users can still send messages, but no one gets alerted. Tick at least one admin.

Step 3 — Set the name users see

Next, decide what your team is called from the user’s side of the conversation. On the same Chat Settings page, fill in the Chatting with Name for Admins field — this is the name shown in the conversation header and in the user’s thread list whenever they message your team.

Pick a name that fits your app’s voice:

• A company name for a marketplace — for example, Acme Marketplace
• A generic helper label for a single brand — for example, Customer Support
• A friendly first name for a more personal tone — for example, Riley from Acme

Keep in mind this name is global: every user, on every app role, sees the same support name. (Message-bubble colors can vary per role — the name itself doesn’t.)

Step 4 — Set the avatar users see

Give the support thread a face. Still on Chat Settings, use the Avatar Image for Admin Chat field to upload an image or pick one from the media library — a square logo around 256×256 or 512×512 works well.

Leave it empty and nothing breaks — the plugin simply falls back to a bundled placeholder image. But setting your own logo here is what makes the support thread feel like part of your brand rather than a generic chat box.

Once the name, avatar, and admin selection are all in place, save the page.

Step 5 — Add the support-chat button to your app

Configuring Chat Settings doesn’t automatically put support chat in front of anyone — you still have to place the button yourself, in your app’s navigation.

Head to the navigation configuration for the role you’re building (home screen, tab bar, or left menu) under Mobile App Manager → App Settings, and add a button with content type Admin Chat. That button comes in two presentation modes:

• One on One Chat with Admin Group — the default, and what most apps want. Every user gets their own private thread with your admin team. This is the true “support inbox” experience.
• Group Chat with Admin — all users share a single thread with the admins. This behaves more like a town-hall channel than a support inbox and is usually only appropriate for very small communities.

Unless you specifically want everyone piled into one shared room, go with One on One Chat with Admin Group, then save the role.

Tip: if you’d rather your users reach their full conversation list (not just support) from a button, there’s also a separate “standard chat” content type and a built-in Chat tab-bar button — both covered in the Enable chat recipe.

Step 6 — Test it end to end

Now confirm all of it actually works. Sign in to the app as a regular (non-admin) test user and tap the support-chat button. You should see:

• A conversation opens. If it’s the user’s first time, a fresh thread is created on the spot.
• The header shows the name and avatar you set in Steps 3 and 4.
• Sending a message fires a push notification to every admin you ticked in Step 2.

Then switch hats and sign in as one of the ticked admins. You should see:

• The user’s message shows up in your chat thread list.
• Your replies are attributed to you personally (your own name and avatar), while the user continues to see the single support name.

Want the view across the whole site? Use Mobile App Manager → Chat History, a read-only list of every thread with participants and a last-message preview.

Styling the chat screen (optional)

Activating the plugin also adds a Chat Settings category to the role-aware MAM settings panel, where you can fine-tune how chat looks per role, including:

• Message-bubble color and text color for the sender vs. the other party
• The default avatar color and the unread-message dot color
• Whether timestamps show on every message
• The message-input bar background and send-icon color
• An optional character counter, and an alert message shown when a user types a phone number or email address into a chat

None of this changes who can answer support — it’s presentation only. For the complete list, see the related Style chat bubbles and behavior recipe.

Common gotchas

• No admins ticked = no notifications. An empty admin group still accepts messages — it just doesn’t alert anyone. Always tick at least one admin (Step 2).
• The support name is global, not per-role. Bubble colors can vary role to role, but the “Chatting with Name for Admins” value is shared across every one of them.
• The button doesn’t place itself. Filling out Chat Settings doesn’t put anything in your app for you — you still need to add the Admin Chat button under App Settings (Step 5) before users can reach support.
• Removing an admin keeps their past replies. Unticking an admin turns off future notifications to them, but any messages they already sent stay right where they are, on the thread.
• Avoid the chat-reset action. There’s an admin action that permanently wipes every chat thread on the site. Treat it with care — it can’t be undone, and it affects all users, not just support.

Going further (developer hooks)

Everything above is no-code. If your app needs support routing that the settings page can’t express, the plugin exposes filters a developer can use:

• Pin the support thread to a specific context post (e.g. per-storefront support in a marketplace) so each context gets its own thread.
• Route a user to a tier-specific support group at runtime instead of the single configured admin group.
• Attribute each reply to the specific admin who sent it, rather than the shared support name.

You’ll find these referenced in the Configure the admin support chat recipe and the chat-manager hook articles — reach for them only when the no-code settings genuinely can’t cover your case.

Related articles

• Plugin: mam-chat-manager
• Recipe: Enable chat
• Recipe: Configure the admin support chat
• Recipe: Style chat bubbles and behavior
• Hook: mam_chat_set_chat_user_name
• Hook: mam_chat_add_to_chat_thread

Verification

This draft was grounded against:

• Plugin: mam-chat-manager v2.0.0
• Source: includes/mam_chat_manager_admin_settings.php (chat_settings_page(), settings category injection)
• Source: content-classes/content-class-admin-chat.php (the mam_admin_chat content type and its one-on-one / group modes)
• Existing user docs: 01-plugin-overview-mam-chat-manager.md, 02-recipe-enable-chat.md, 04-recipe-configure-admin-support-chat.md
• WP options referenced: mam_chat_admin_name, mam_chat_admin_avatar, mam_chat_admin_chat_group

Re-verify whenever the Chat Settings field labels change, the admin menu page slugs (mam-cm-chat-settings, mam-cm-chat-history) change, the Admin Chat content type’s mode labels change, or the listed option keys are renamed.