Integrations

How a customer issue reaches your desk

A support desk is only as good as what gets into it. These are the routes in — what each one needs from you, and how much work it is. Where something is not built yet, it says so.

Live today

Email, on your own domain

The one that needs no code. Mail sent to an address you own arrives as a ticket, and replies go back from that same address — your customers never see a SupportAndGo or MyAndGo address anywhere in the thread.

You can start without touching your mail routing at all. A mailbox can be mirrored to the desk read-only first, so you see real traffic being classified and prioritised while your team keeps answering wherever they answer today. Cutting over is a later, separate decision, and it is staged: an address is opened, proven with a real delivered message, and only then does anything customer-facing move.

In-app chat, over a signed callback

A conversation in your product becomes a ticket, and the agent's reply is pushed back to your application rather than emailed — so the customer answers in the place they asked, with the thread intact. Your application keeps ownership of the chat UI; the desk supplies the triage, the SLA clock and the human.

The embeddable help widget

@myandgo/help is published on npm — Preact in a shadow DOM, so it inherits none of your styles and leaks none of its own. One embed, and a "Get help" surface exists in your product.

It deliberately never asserts who the user is. Identity comes from your application or not at all, because a widget that guesses at identity is a widget that occasionally attributes one customer's message to another.

Incidents from your error monitoring

Push an incident and the desk correlates it with the tickets arriving about it. A spike of complaints and the error behind them stop being two separate investigations — which is the difference between answering forty customers individually and telling all of them the same true thing at once.

Voicemail as a ticket

A missed call is answered, recorded and becomes a tracked ticket with the caller's number on it, rather than a notification someone has to remember to act on. Inbound SMS arrives the same way where a product relays it.

A wallboard feed

A read-only summary endpoint for a dashboard or screen on a wall — volumes, SLA state and what needs attention, with no ticket content and no session. It separates real customer traffic from your own test traffic, and reports which is which, so a wallboard cannot quietly count your own probes as customers.

Sending tickets in from your own code

The ingestion API takes an HMAC-signed POST: a shared secret, a timestamp, and a signature over the raw request body, valid for five minutes. Anything that can compute an HMAC-SHA256 can talk to it, in any language, with no SDK to install and no library to keep current.

Signing is over the raw bytes, not a re-serialised object — so a proxy that reorders JSON keys cannot invalidate a legitimate request, and an attacker cannot craft a body that verifies against a different one.

If that is more than you need, forward email instead. It requires nothing but a forwarding rule and it is how most desks start.

Not built yet

Listed because a roadmap presented as a feature list is how software gets bought for something it cannot do.

  • Outbound SMS. The desk receives a relayed text message and threads it correctly. It cannot yet answer one — replying to an SMS means using a phone.
  • Answered phone calls. Voicemail becomes a ticket today. A call answered and triaged in the moment is designed and not shipped.
  • MCP tools. Letting an AI assistant read and resolve a ticket directly is the direction this product is built toward, and it is not available yet.

The AndGo products

SupportAndGo runs the support desk for every product in the MyAndGo ecosystem — SignAndGo, ShareAndGo, BookAndGo, InspectAndGo, WorkAndGo and the rest. They are not a special case with private access: they are tenants on the same multi-tenant rails described above, using the same signed ingestion any customer gets.

That is deliberate, and it is the most useful thing on this page. Every integration here is one we depend on daily for our own customers, so it breaks for us first. A support product whose makers do not use it for their own support is a product nobody is checking.