We don't run a call centre. We don't staff a support desk that asks for ticket numbers before saying hello. We answer technical questions on Telegram in minutes, not days, and we treat asynchronous tickets as the channel for things that aren't urgent. For visitors who reach us over Tor, the .onion mirror works identically to the clearnet site.
We use Telegram because it's the de-facto standard among the customer base we serve, and because the alternative (running a separate Slack workspace or Discord server) creates more friction than value. You don't need to install anything new. Most operators we work with are already on Telegram.
Open Telegram →Tickets are the right channel when you have a long technical brief, attachments, or a request that benefits from a written record. We don't expect 24/7 ticket response. If it is urgent, Telegram is faster. If it is a careful migration plan you've spent an hour drafting, ticket is the right place.
# Email gateway address provided after first Telegram conversation. We do not publish a public email address because every public address gets ~2,000 daily spam attempts which our Telegram channel does not.
Get the ticket address →The Tor mirror is the same site, served over a v3 .onion address. Visitors arrive via the Tor browser without the network ever resolving our clearnet domain. From our infrastructure side, requests appear with no identifying source IP. After initial contact you can switch to Telegram for the actual conversation.
Note: the .onion address rotates if the operator key is ever compromised; the current address is shown in the footer of every page on the clearnet site.
# With those six points, we can usually return a quote and a configuration recommendation in the first reply.
# Operational questions go straight to engineering. We do not have a tier-1 or tier-2 escalation pattern. The first person who reads your message is the same person who fixes it.
# Active incidents jump the queue. We don't ask you to fill out a form first.
The three channels are not interchangeable. Each has a distinct response-time profile, conversational pattern, and fit for specific operational situations. Picking the right one for the situation produces faster resolution and better information transfer than defaulting to whichever is most convenient.
Telegram is correct for: pre-sales conversations where you want to scope a service against your situation, urgent operational issues affecting production sending, configuration questions during onboarding, deliverability incident triage, and anything where back-and-forth dialogue would be faster than written exchanges. Median response time is 12 minutes during our covered hours, which is roughly 16 hours per day rolling across our operational team. Late-night and early-morning UTC windows see longer response times, typically 30-60 minutes.
Ticket is correct for: async engineering questions that require attached configuration files or detailed technical context, follow-up on previous engagements where conversation continuity matters more than speed, situations where the operator submitting the question wants a written record of the exchange for internal documentation, requests involving sensitive material that benefits from PGP encryption, and anything that does not need a response within hours. Median response time is 4 hours during covered windows; we read the ticket queue every two hours from 09:00 to 02:00 UTC and respond to outstanding items in batches rather than continuously.
Tor mirror is correct for: visitors who require Tor for their own threat model and want to browse the site or initiate contact without clearnet traffic, operators in jurisdictions with restrictive internet conditions that block direct access, and any contact situation where clearnet metadata would itself be undesirable. The Tor mirror operates the same site as the clearnet version with identical functionality; contact initiated through the mirror is handled the same way as contact initiated through clearnet, with the same response times and the same operational staff.
Telegram median response across Q1-Q2 2026: 12 minutes for messages received during covered hours (roughly 16 hours daily rolling). 90th percentile: 47 minutes. Worst case during 2026 has been 4 hours and 22 minutes, which occurred on a Saturday evening when the on-call operator was dealing with an active customer incident in another timezone. We do not staff Telegram outside covered hours; messages received outside the window get answered when coverage resumes, with the message timestamp preserved so urgent context is not lost.
Ticket median response across Q1-Q2 2026: 3 hours and 47 minutes for tickets submitted during the 09:00-02:00 UTC window. 90th percentile: 7 hours and 12 minutes. Tickets submitted between 02:00 and 09:00 UTC pick up at the start of the next covered window. We have not had a ticket sit longer than 24 hours without acknowledgement in 2026, which is the operational commitment we make to all customers.
The response-time data above describes acknowledgement and substantive engagement, not resolution. Some questions are answered in the first reply. Others require us to do forensic work or coordinate across infrastructure, which extends the resolution timeline by hours or days depending on the situation. We acknowledge promptly even when resolution will take longer, and we provide intermediate updates if the work extends beyond initial estimates. The worst customer experience is not slow resolution; it is slow resolution without communication about the delay.
Our operational staff communicates fluently in English, Spanish, and Portuguese-BR. Telegram conversations and ticket exchanges in those three languages are handled natively without translation overhead, with response times equivalent to English. We can handle conversations in German and French at a working level, with occasional translation latency on technically complex topics. For other languages, we suggest English as the working language for clearest technical communication.
Our coverage window is roughly 09:00 to 02:00 UTC, which is approximately 16 hours of daily rolling coverage with some overlap between handoffs. The window covers business hours in the Americas (Eastern Time 04:00-21:00), Europe (CET 10:00-03:00 next day), and most of APAC except deepest Australia/New Zealand. Customers in those regions who need 24-hour coverage typically pair with our monitoring service, which includes pager-style escalation for production-impacting issues regardless of when they occur.
Holidays follow a published calendar that we share with customers on monthly billing. The major coverage gaps are December 24-26 and January 1-2 (around the year-end holiday), and one week typically in August for staff rotation. During gap periods we maintain emergency-only coverage for production incidents through the on-call system. Non-urgent inquiries during gap periods get queued and answered when coverage resumes.
Our team responds directly rather than through scripted templates — the person who answers your question is the same engineer who'd touch your infrastructure if it broke. We tell you when we don't know something, push back when your plan has problems, and mention competitors openly when they fit your needs better than we do.
| Channel | When it fits | Median response |
|---|---|---|
| Telegram | Technical questions, operational issues, scoping. Most conversations. | ~12 min during ops hours |
| Ticket | Detailed documentation, formal incident response, audit trail. | under 4h during ops hours |
| If you prefer email over real-time channels. | matches ticket pace | |
| Voice/video | Complex scoping or severe incidents. Scheduled in advance. | 1-3 business days lead |
Operating hours: primary coverage 06:00–22:00 UTC weekdays. Incidents get 24/7 attention regardless of hours — acknowledgment within 30 min for active production issues. Routine inquiries outside ops hours resolve within next-day.
Escalation: request it explicitly through your current channel. Standard escalation reaches operational leadership same business day. Incident escalation gets direct leadership engagement within 30 min. Billing/scope disputes get dedicated leadership review outside the standard support queue.
Language & timezone: English and Spanish are primary. Other languages handled through async translation (slower). Scheduling follows your timezone, not ours.
# Conversation records retained per privacy policy. Customer data accessed on need-to-know basis. Not disclosed to third parties except legal process. See privacy policy for full detail.