How tickets sync

• When a customer writes in BILLmanager, the message shows up in the Inbox: within a minute with the module, within 30 seconds with API polling. A new BILLmanager ticket becomes a new ticket, and a reply to an existing one becomes a message in the same ticket.
• When an operator replies in SupportHub, the reply goes to the BILLmanager ticket from the system operator (module) or from the account in the channel settings (API). The customer gets it as usual: in the panel and by email from BILLmanager. Internal notes are posted as internal comments, which the customer doesn't see. If a reply can't be delivered, SupportHub retries it every 3 minutes for a day (internal notes aren't retried).
• A staff member's reply from the BILLmanager panel also lands in the ticket. If the ticket isn't assigned yet, it's assigned to the operator with the same name; failing that, to the operator whose email starts with that name (the part before the @), and as a last resort to an operator whose name contains it. The timeline shows “📌 Assigned to … (replied from BillManager)”. An internal comment from the panel doesn't assign the ticket.
• Internal comments left in the BILLmanager panel arrive as internal notes with API polling (except comments by the channel's own account). The module doesn't carry them over.

The customer's files from the BILLmanager ticket appear in the ticket. Files from an operator's reply are uploaded to the BILLmanager ticket as regular attachments — by the module and with API polling alike. The module takes files up to 25 MB, sends a larger file as a link, and always sends files in an internal note as links. A file that fails to upload is sent as a link too, so nothing gets lost.

When a customer rates replies 👍/👎 in BILLmanager, the module copies those ratings to the same replies in SupportHub. API polling doesn't carry ratings over.

In BILLmanager 6, closing by a staff member doesn't change the ticket status right away. BILLmanager first asks the customer to confirm the closure (the ticket waits for the customer's confirmation), then moves it to the archive once they confirm, or on its own after a few days. So:

• When you close a ticket in SupportHub, the BILLmanager ticket is closed too, on behalf of the system operator (module) or the channel account (API). Any close works this way: the button, changing the status to Resolved or Closed (on the board or with a macro), auto-close and deleting the ticket. From there it works as if a staff member had closed it in the panel: BILLmanager waits for the customer to confirm.
• When a ticket is closed in the BILLmanager panel, the module notices within a minute, and our ticket becomes “Resolved”. With API polling, the ticket closes when BILLmanager changes the ticket status itself: closed becomes Resolved, archived becomes Closed; API polling doesn't see a close that is still waiting for the customer's confirmation.
• A new message in the BILLmanager ticket — from the customer or from staff in the panel — reopens a closed ticket, as long as the BILLmanager ticket is still active.
• With the module: if an operator reopened the ticket in SupportHub after it was closed in BILLmanager, the ticket stays open until someone writes or BILLmanager moves the ticket to the archive.

A BILLmanager ticket status maps to a ticket status like this:

• new → New;
• under review (the customer is waiting for you) → Open;
• awaiting a reply (you replied, waiting for the customer) → In Progress;
• closed → Resolved, archived → Closed.

API polling also knows the accepted (In Progress) and delayed (Snoozed) statuses. A status from BILLmanager never downgrades a ticket that is In Progress, Resolved or Closed to New or Open.

On a module channel, if a staff member wrote the first message in a BILLmanager ticket (for example, a notice about a copyright infringement or an abuse complaint), no ticket is created in SupportHub: there's nothing to work on yet, so it waits for the customer. As soon as the customer replies, the ticket appears with the conversation (up to the last 200 messages), including your notice, so you can see what they're replying to. With API polling such tickets are created right away, and the channel's account takes them in BILLmanager at once.

“Snooze” works the same as in other channels: while a ticket is snoozed, statuses from BILLmanager don't bring it back, and the SLA is paused. The ticket comes back when the customer writes, when the snooze runs out, or when someone resumes it manually. A staff member's reply from the BILLmanager panel doesn't wake a snoozed ticket. Closing in BILLmanager closes a snoozed ticket too.

Messages from a customer who is blocked in SupportHub don't create tickets and don't reach open ones.

A ticket goes to a department according to the mapping on the “Departments” tab, with API polling and with the module alike: the module sends the BILLmanager department with every message (from version 1.0.0-13). A ticket from a department that isn't in the mapping goes to the department of the “fallback” row, if there is one. A module older than 1.0.0-13 doesn't send the department, so on such a channel only the “fallback” row applies. The department is applied again on every update of the ticket from BILLmanager, so moving the ticket to another department by hand may be undone.