MX12 Documentation
A simple reference for setting up AI support, tickets, lead generation, billing, referrals, and owner tools inside MX12.
MX12 company snapshot
MX12 is a managed support operations and AI assistance workspace for companies that need website chat, customer support, ticket tracking, lead generation, balance-based billing, and structured owner reporting. This documentation explains where each feature lives and how clients can set everything up without guessing.
MX12
US-based support operations, AI chat, ticketing, leadgen workflow, multilingual support, and CRM-connected workspaces.
Contact and location
- Website
- mirrax12.world
- mirrax12@protonmail.com
- Phone
- +1 929 322 8848
Where each feature is located
Use this quick map when you know what you want to do, but not where to open it. The exact menu can change by role, but the functional areas stay the same.
Use settings to add company identity, team members, AI knowledge, widget rules, Google Authenticator, and profile details.
Create requests, claim work, track time, end chats, and keep customer history attached to the ticket.
Top up through Stripe, activate AI plans, buy chat packs, review ledger movements, and watch company spending.
Work leads one by one, copy contact data, save outcomes, schedule callbacks, and reassign leads when needed.
Owners review system health, distribute leads, inspect companies, audit payments, and manage operational alerts.
Share an invite link, track referred users, request payouts, and transfer bonus balance where allowed.
How the workspace works together
The website widget receives the message and keeps the conversation thread attached to the company.
Company fields, knowledge sources, website references, and language rules guide the first answer.
Pricing, custom requests, complaints, urgent questions, and complex work can be routed to a manager.
Tickets store status, source, company, messages, internal notes, time tracking, and final outcome.
AI plans, chat packs, ticket time, package spend, and owner adjustments are recorded for review.
Owners watch companies, users, AI usage, economics, leadgen distribution, payroll, and alerts.
What MX12 Helps You Run
MX12 combines AI website chat, human manager handoff, ticket tracking, company settings, lead generation workflows, internal balance spending, and referral tools in one workspace. Use this page as the first place to understand which field controls which behavior.
Quick start path
Register, confirm the profile role, and complete any required leadgen face capture if the account is for lead generation.
Add the company name, logo, owner, team members, contact channels, and invite links before connecting AI.
Add services, support rules, knowledge sources, official website references, languages, and handoff rules.
Copy the widget public key, add allowed domains, place the script on the site, and test a real customer question.
Managers process tickets, lead generators work lead cards, owners watch reports, balance, alerts, and payouts.
Roles and Access
Each account has a role. The role controls the pages a person can open and the actions they can perform.
| Role | Typical access | Main responsibility |
|---|---|---|
| Owner | Owner workspace, companies, users, billing reports, leadgen allocation | Controls company-level operations and distribution. |
| Manager | Tickets, chats, assigned work, customer communication | Handles support conversations and ticket outcomes. |
| Client | Dashboard, balance, tickets, AI settings, company settings | Configures their company and monitors service usage. |
| Lead generator | Leadgen workspace, assigned leads, referral kit | Works lead cards and records outreach results. |
Access guardrails
- Leadgen pages should be visible only to owners and lead generators.
- Owner pages are owner-only and should redirect other roles to their normal workspace.
- Company settings should show only the current company unless the user is an owner.
- Billing reports separate company history from owner-wide payment reporting.
Registration and Security
Account creation
New users register with email, profile details, and role-specific onboarding. Lead generators may also complete a face capture step before password setup so the profile has a verified account photo.
Google login
Google sign-in uses the OAuth callback configured for the application. If Google shows
redirect_uri_mismatch, add the exact callback URL shown by Google to the OAuth client in Google Cloud.
Two-factor authentication
In Settings → Security, users can connect Google Authenticator. After setup, login requires email, password, and a fresh 6-digit code.
How to set up Google Authenticator in MX12
MX12 uses a dedicated Authenticator setup page. The account owner, client, manager, or lead generator opens Settings → Security, clicks Set up Authenticator, and then connects the phone app with either the QR code or the manual setup key shown on the MX12 page.
Go to the account settings page and open the Security card.
Scan the QR code with Google Authenticator. If the page is open on the phone, copy the setup key instead.
Type the fresh code from the app into the MX12 verification cells. Full-code paste is supported.
After email and password, MX12 asks for a current Authenticator code before opening the account.
Company Settings
Company settings define the public identity and team structure used across widgets, tickets, and AI responses.
- Company name
- The visible organization name used in the account, widget header, reports, and billing records.
- Logo
- Shown in the header and chat surfaces when available. Use a clear square or horizontal logo.
- Company owner
- The account that manages users, billing, and high-level permissions for the company.
- Team members
- People attached to the company. Click a member card to open their profile and contact surface.
- Invites
- Share invite links with users who should join the same company workspace.
Company field map
| Field or block | Where it appears | Why it matters |
|---|---|---|
| Logo | Header, widget, account surfaces | Gives visitors and team members a clear company identity. |
| Owner email and phone | Company cards, member profiles, owner tools | Helps route questions to the correct responsible person. |
| Members list | Company settings and profile links | Shows who belongs to the company and opens member profile details. |
| Invite links | Company settings | Lets new users join the correct workspace without manual reassignment. |
| Support contacts | AI replies, manager handoff notes, company profile | Helps the assistant and support team know where to route business conversations. |
| Role badges | Team list and user cards | Clarifies who is the owner, manager, client, or lead generator without reading long text. |
Recommended company setup checklist
These fields make the widget and account surfaces feel official and help customers trust the chat.
Keep the team list clean so tickets, profile pages, and internal handoff actions point to the right people.
Clear routing reduces missed requests and prevents the assistant from promising a handoff without a responsible person.
Use this as the base layer before adding AI knowledge sources and website references.
AI Setup
The AI configuration page controls how the assistant answers, when it creates tickets, and which sources it trusts. Saved company fields and knowledge sources should be treated as the primary source of truth.
Recommended setup order
- Add company description, services, language preferences, and contact instructions.
- Add knowledge sources such as FAQ, policies, website overview, support rules, and internal notes.
- Add official website references before using broad web context.
- Set manager handoff behavior and ticket creation rules.
- Test the widget with real customer questions and refine gaps.
How an AI reply is built
The widget or support surface receives the message and keeps the conversation thread.
Saved company fields, service notes, language settings, and active knowledge sources are checked first.
Higher priority knowledge sources and official MX12/company pages are preferred over general guidance.
The assistant either answers, asks for missing details, requests a manager, or creates/routes a ticket.
AI settings field map
| Setting | How to fill it | Effect on replies |
|---|---|---|
| Company summary | Explain what the business does, who it serves, and what should be offered first. | Shapes the default answer when no specific FAQ source matches. |
| Support goals | Describe whether the assistant should qualify leads, answer support, collect details, or route tickets. | Controls whether the assistant answers directly or moves toward handoff. |
| Languages | List the languages the company supports and the fallback language. | Helps replies follow the visitor language instead of always using a default language. |
| Manager handoff | Write when the AI must stop and involve a person: pricing, contract, complaint, urgent issue, or custom quote. | Prevents the assistant from over-answering when a human should take over. |
| Web references | Add official websites or pages that the assistant may use when saved settings are not enough. | Lets AI find public facts while still prioritizing internal company context. |
Knowledge source anatomy
- Source title
- Short human label, visible in the settings list.
- Source type
- Company info, FAQ, policy, website page, internal note, or support rule.
- Priority
- Higher priority wins when sources disagree. Use 10 for the most trusted core context.
- Reference URL
- Optional official URL the assistant may cite or use as context direction.
- Content
- The actual answer material. Keep it concrete, current, and written like an internal operating note.
- State
- Only active sources are included in the AI context.
How web context should work
Company fields and saved knowledge sources come first. If the answer needs extra website context, prefer the official MX12 website and official company-owned pages before using general web information.
- Use web context for contact details, service pages, official positioning, and current public page copy.
- Do not invent phone numbers, LinkedIn links, prices, or legal facts if the source is missing.
- If the assistant has enough saved knowledge, it should answer directly and avoid unnecessary browsing.
- If a visitor asks for a manager, contacts, pricing discussion, or implementation help, create or route a ticket.
Website Widget
The website widget connects visitors to AI first replies, manager handoff, file upload, and ticket creation. Use the public key generated in AI settings.
Install snippet
<script>
window.mirra = window.mirra || function(){(window.mirra.q = window.mirra.q || []).push(arguments)};
mirra('init', {
public_key: 'mw_53da044de99fb609dea9b924',
base_url: 'https://mirrax12.world',
ticket_hint: 'General Support Question',
translation_display_mode: 'original'
});
</script>
<script async src="https://mirrax12.world/static/js/widget-loader.js"></script>
Important fields
- Public key: connects the widget to the correct company.
- Allowed domains: restrict where the widget may run.
- Ticket hint: labels requests created from the widget.
- Manager handoff: switches from AI replies to live support when needed.
Widget testing checklist
Tickets and Chats
Tickets are the operational record for support work. A ticket may be created manually, from a widget conversation, or from a manager request.
How a client orders support or asks for help
The AI answers first, collects the company name, issue, contacts, and request details, then routes to a manager if needed.
Inside the account, the client can open Tickets, create a request, and keep the discussion tied to the company.
A manager takes the ticket, tracks work time, replies in the thread, and updates status as the issue moves forward.
For widget-origin conversations, ending the chat can show a short rating prompt to the visitor.
Chat vs ticket
| Item | Chat | Ticket |
|---|---|---|
| Purpose | Live or AI-assisted conversation with a visitor or customer. | Structured work record with owner, manager, status, time, and outcome. |
| Best for | Fast questions, qualification, manager handoff, and first contact. | Issues that need tracking, billing, escalation, follow-up, or reporting. |
| History | Conversation messages and uploaded files. | Conversation, internal notes, status changes, time tracking, and rating. |
- Created
- The ticket exists and can be picked up by the right team member.
- Tracked time
- Shows how much work time was spent on the ticket.
- End chat
- Stops active work on the ticket and may ask the visitor for a rating in the widget.
- Rating
- Visitor feedback from 1 to 5 stars after the manager conversation is finished.
Ticket statuses and timing
| Signal | Meaning | Operator action |
|---|---|---|
| Scope | Total planned work window for the ticket. | Use it to understand the expected support budget. |
| Tracked | Time already spent by the manager on the ticket. | Stop work when the active chat is finished so time stays accurate. |
| Left | Remaining time inside the current ticket scope. | Escalate or clarify if the remaining time is too low for the issue. |
| Rating prompt | Visitor feedback shown after a widget-origin chat is ended. | Keep the prompt short and in the conversation language when possible. |
Leadgen Workspace
Leadgen tools help owners distribute datasets and help lead generators work one lead at a time without losing history.
Lead card fields
| Field | Meaning |
|---|---|
| Status | Current result such as follow-up, won, no answer, not interested, or in work. |
| Score | Priority signal used to decide which leads deserve faster attention. |
| Contacts | Phone, email, social links, website forms, and discovered channels. |
| Next touch | The next callback or outreach date for this lead. |
| Internal notes | History and private comments for the next person who works the same lead. |
| Handoff | Send a lead to another user when help, review, or another attempt is needed. |
Lead handoff and repeat cycles
Lead data should travel with the card. If an owner reassigns a lead after no answer, not interested, or follow-up, the next worker should see the previous status, contact attempts, notes, channel, and next touch.
Balance and Billing
MX12 uses a company wallet for prepaid service credit. Stripe adds credit to the wallet; internal actions spend from it.
- Main balance
- Available wallet amount for packages, AI plans, extra chat packs, and internal service spending.
- AI chats left
- The shared company AI reserve used by widget replies and AI-assisted support replies.
- Billing history
- A timeline of top-ups, debits, package payments, AI packs, and owner adjustments.
- Owner payment report
- Owner-only report across companies with filters, pagination, and status summaries.
How balance spending works
Choose a preset or custom amount, continue to Stripe checkout, and return after payment.
MX12 services spend from this balance after checkout or owner-approved internal actions.
Widget replies and AI-assisted support replies use the same company AI chat reserve.
Top-ups, package purchases, AI packs, ticket time, and manual adjustments appear in billing history.
Billing history rows
| Record type | What it means | Where to check |
|---|---|---|
| Top up | Stripe payment that added prepaid credit to the company wallet. | Company billing history and owner payment report. |
| Subscription | AI plan activation, renewal, or chat pack spending from balance. | AI balance block and billing history. |
| Ticket time | Internal support time charged for tracked manager work. | Ticket detail and billing timeline. |
| Manual adjust | Owner-side wallet correction or company credit adjustment. | Owner payment report. |
Referrals
Referral pages show codes, invite links, payout status, referred users, and bonus history. Use the ready message to share the invite without manually rebuilding the text.
- Referral code: short code attached to signups from your link.
- Referral link: public registration URL with your code included.
- Bonus balance: earned referral amount before transfer or payout.
- Payout request: action that asks the owner team to process a payout.
Owner Workspace
Owner pages give a company-wide view of people, clients, companies, economics, AI usage, pricing, payroll, referrals, and lead generation operations.
Owner attention signals
Troubleshooting
Google login says redirect_uri_mismatch
Add the exact callback URL from the Google error page to the OAuth 2.0 client allowed redirect URIs.
Widget does not answer with company facts
Check the AI knowledge sources, priority order, saved company fields, and allowed web references.
Ticket was promised but not created
Review the AI handoff rules and ticket creation setting for the widget configuration.
Lead card is missing contact data
Open the lead detail page. Empty fields stay empty, but discovered phone, email, social, and form links are grouped in contact cards.
Frequently Asked Questions
Can MX12 add an AI chat to my website?
Yes. Configure AI settings, add trusted knowledge sources, generate a widget key, install the script, and test AI replies plus manager handoff.
Can the AI create a ticket when a visitor asks for a manager?
Yes, when ticket creation and handoff behavior are enabled. The ticket should include the company, source, thread history, request details, and contact notes.
What should I add to knowledge sources first?
Start with company overview, service list, pricing or quote rules, support policy, contact rules, FAQ, and official website references.
What happens when the AI chat reserve runs low?
The company should top up balance, buy an extra AI chat pack, or renew the AI plan before the current reserve ends.
Who should enable Google Authenticator?
Every account that has access to company settings, billing, owner tools, tickets, lead data, or customer conversations should enable it.