Production Support Specialist

# **Company Overview** Avantos AI is shaping the future of client relationship management by reimagining it through the lens of artificial intelligence. We are building the industry’s first AI-native operating system for financial services, transforming how firms onboard clients, deliver advice, and manage critical servicing workflows. Our platform consolidates fragmented data, automates complex processes, and embeds intelligent decision-making throughout every stage of the client lifecycle. Supported by Bessemer Venture Partners and MIT’s investment arm, our team comprises execution-focused, design-driven, product-centric founders and leaders from Wharton, MIT, top design programs, and unicorn SaaS companies. We move swiftly, tackle deep industry challenges, and build technology that empowers users to take charge of their workflows. # **About the Role** Avantos is the platform enterprise financial firms run their client operations on: the advisor-facing portal, the data ingestion that feeds it, reporting and notifications, third-party integrations, AI-assisted features, and the automated journeys that carry a client process end to end. When any part of it misbehaves in production, you are the person who finds out first, works out what actually happened, gets it to the team that can fix it, and tells the client the truth about it. You will own production issues from detection through investigation, routing, and client communication, to shepherding the fix through UAT into production. This is a technical coordination, triage, and client advocacy role. You will not write production code day to day, but you do need technical literacy: reading logs and traces, understanding how the pieces of an application fit together, and holding your own in a conversation with engineers. People arrive at that from several directions — technical support, QA, implementation or solutions work, technical operations, or development. What matters is that you have it, not where you picked it up. Be clear-eyed about one thing. A good deal of this work is manual. Nothing chases a fix ticket into a cycle for you, and two issue trackers do not reconcile themselves. The role suits someone who is systematically persistent rather than someone waiting to be paged. # What You’ll Do ### Detection — monitor every intake channel - Watch the client’s Linear board for new tickets and status changes such as Ready for Dev and Failed UAT. - Watch #support in Slack and the queue for auto-created SUP tickets, and confirm the auto-reply actually went out. - Watch Datadog monitors and error-rate alerts so we find production problems before the client reports them. ### Triage — acknowledge, classify, prioritize - Acknowledge to the client on the ticket, and on the email thread where one exists. - Read the report and establish what it is actually about. Go back to the client when it is not reproducible as written. - Set the real severity against the written rubric. A client-set priority is an input, not the answer. - Set the Customer field and labels so the Linear automations fire correctly. ### Investigation — establish first-line root cause - Reproduce the issue in the relevant environment and record the exact steps on the ticket. - Query Datadog logs, traces, and dashboards for the affected service and time window, and attach the evidence. - Separate platform defects from data, configuration, permissions, and user error — and say which it is. Much of what a client sees is tenant configuration rather than product code, and telling the difference is what makes an escalation useful. - Check whether the issue is already known, already fixed on an unreleased branch, or a duplicate. ### Routing — assign to the team that can fix it - Route to the engineering triage queue that owns the affected service or surface, never to a default queue. - Link the support ticket as blocked-by the engineering fix ticket so the dependency is visible. - Chase the fix ticket into a cycle, and keep chasing it. Nothing does this automatically. ### Synchronization — keep both systems telling one story - Cross-link the two tickets in both directions as soon as the support ticket exists. - Mirror every status transition onto the client’s board: In Review, Ready for UAT, In UAT, Ready for Production, In Production. - Maintain the mapping between our statuses and theirs, and flag where the vocabularies have drifted. - Reconcile both boards on a fixed cadence to catch mirrors that were missed. ### Communication — own the client conversation - Give the client a status update on the agreed rhythm, including on tickets where the answer is “no change”. - Communicate outcomes on the ticket and on the parallel email thread, so both records close cleanly. - Frame dates as estimates until release notes confirm them, and say plainly when an estimate slips. - Represent the support queue in the Tuesday and Thursday huddles with current numbers, not recollection. ### Release — shepherd fixes through UAT to production - Friday release prep: confirm every expected ticket is on the release board, is QA’d, is Ready for UAT on the client’s side, and appears in the release notes. - Send the release notes, then flip every ticket to In UAT on both boards after the Monday evening deploy and smoke test. - Triage Failed UAT sub-issues, judge patch runway against the written cut-off, and see agreed patches through with whoever is on deployment duty. - On production deploy: confirm the branch, monitor the release in Datadog, coordinate the client’s smoke tester, and log their confirmation on the ticket. # Minimum Qualifications - **Experience:** Roughly 3–6 years in a technical role with real client or production exposure — technical support, QA, implementation or solutions work, technical operations, or software development. - **Technical Literacy:** You understand how web applications, APIs, and services fit together, and you can read an error and form a sensible hypothesis about where it came from. A formal engineering background is one route to this; it is not the only one. - **Observability:** Comfortable working with logs, traces, and monitors. We use Datadog; experience with Splunk, New Relic, CloudWatch, or similar transfers, and the tool itself is quick to learn. - **Data Literacy:** Enough SQL to check whether a record exists and whether it looks right — or the appetite to pick that up in your first few weeks. - **Issue Tracking:** Linear, Jira, or similar, including work spanning more than one instance or workspace. - **Client-Facing Aptitude:** Strong empathy, and the composure to hold a difficult client conversation, set realistic expectations, and translate technical detail into plain language. - **Process & Detail Orientation:** Exceptional organization. Ticket parity across two boards, Slack, and email is held together by attention, not by tooling. - **Communication:** Business-fluent spoken and written English. - **Hours:** Full-time aligned to US East Coast hours, including Monday evening deploy windows. # Preferred Qualifications - Financial services exposure: wealth management, client onboarding, account opening, or custodial operations. - Experience supporting a configurable platform, where much of what a client sees is tenant configuration rather than product code. - Familiarity with Linear automations, or with administering an issue tracker across multiple workspaces. - Experience writing runbooks or triage rubrics that other people then used. - Prior work on a release train — UAT coordination, release notes, cut-off management.