The Situation
The brief was simple on paper: build a support function. The reality was more layered — build it, hire for it, manage it, and keep running your CSM book at the same time.
In fintech and payments, customer support isn't a back-office function — it's part of the commercial relationship. When a merchant can't process a transaction, or a client's payment flow breaks mid-day, how fast and how well that gets resolved is felt at the account level. Support quality is relationship quality.
The starting point was a company with no formal support infrastructure. Inbound queries arrived by email. Customers called a general phone line for help — and sometimes to make payments directly. No ticketing system. No SLAs. No defined ownership. Questions sat in inboxes until someone picked them up, which meant the most persistent customers got the fastest answers regardless of urgency or commercial importance.
As CSM, I was the most visible customer-facing person in the business. When support didn't exist, it defaulted to me. Building it properly wasn't optional — it was the only way to protect the strategic account relationships I was there to manage.
Building the Support Function
Before a single agent was hired, three things needed to exist: a clear picture of what support actually needed to handle, a basic operational structure, and a realistic view of what "good" looked like at this stage. Without those anchors, the first hire arrives with no context and no guardrails.
The first step was a manual audit of the inbound email backlog — categorising every query by type, urgency, and customer. In payments, the mix matters: account queries, transaction questions, billing disputes, integration issues, and phone-based payment requests each need a different response path.
- Query type breakdown documented (billing, technical, payments, general)
- Volume patterns identified — daily peaks, end-of-month spikes
- Recurring issues flagged for template responses
- Phone-based payment call volume estimated separately
A support function without SLAs is just a hope. Response time expectations needed to be set internally before they were communicated to customers — and they needed to be honest. An SLA you can't consistently meet is worse than no SLA at all, because it creates a broken promise at scale.
- Response SLAs defined by query type and channel
- Shared support email inbox set up (away from general inbox)
- Phone line assigned to support team via Genesys
- Escalation threshold defined: what goes to CSM and when
- Out-of-hours coverage model agreed
The fastest way to get a new agent up to speed is to give them answers to the questions they'll receive in their first week. A basic knowledge base — even a shared doc at this stage — means agents aren't improvising on live customer interactions while they're still finding their footing.
- Email response templates for top query types
- Phone payment process runbook — including PCI data handling
- Escalation decision tree: what to resolve vs. what to escalate
- Customer-facing FAQ drafted for common questions
Hiring the Support Team
Frontline support in fintech is a specific hire. The customer base has above-average technical literacy, higher-than-average expectations, and genuine commercial sensitivity around anything related to payments. Agents need to be comfortable on the phone taking payment details, clear in writing, and calm when a client is frustrated about money.
The wrong support hire creates more CSM work, not less. Every mishandled ticket or dropped call lands on someone's desk — and in a small team, that desk is usually yours.
Composure under pressure
Payments customers calling about a failed transaction or a billing dispute are not always calm. Agents need to stay measured, gather information accurately, and de-escalate without making promises the business can't keep.
Written clarity
The majority of volume came in by email. Responses that are clear, concise, and accurate the first time reduce back-and-forth and build trust. Agents who write in walls of jargon or vague reassurances create more work, not less.
Process compliance
Taking payments over the phone requires following a defined process without deviation — every time, regardless of how rushed the call feels. PCI compliance isn't optional and it isn't negotiable. Hire people who take procedure seriously.
Escalation judgment
Knowing what to resolve vs. what to escalate is a skill, not a checklist item. Agents who escalate everything become a bottleneck. Agents who escalate nothing become a liability. The ones who read the situation correctly are worth their weight.
Payments or fintech familiarity
Not essential — but agents who already understand the vocabulary (gateways, disputes, settlement, chargebacks) ramp significantly faster. Domain context reduces the time before they can handle complex queries independently.
The Escalation Bridge
The most important design decision in a blended support / CSM model is the escalation path. In this setup, support wasn't a separate function that occasionally surfaced account issues — it was a live feed of relationship signals that directly informed my CSM motion. But only if the bridge between the two tracks was well-designed.
A poorly designed escalation path has two failure modes: agents escalate too much (the CSM becomes a second-tier support agent, strategic work suffers) or agents escalate too late (a brewing account issue becomes a crisis by the time it surfaces). The goal was a path clear enough for agents to follow consistently, and signal-rich enough to give me the context I needed when something did reach my desk.
Inbound Contact
Email or phone via Genesys. Agent picks up, logs the contact, and begins triage against the query type framework.
Support TeamFirst Resolution Attempt
Agent handles from the knowledge base. Standard queries resolved at this layer — billing questions, transaction status, general account queries, phone payments processed per runbook.
Support TeamEscalation Trigger Assessment
If the query meets escalation criteria — senior account, payment dispute above threshold, repeated contact on the same issue, relationship risk language from the customer — the agent flags for CSM review before responding further.
Support TeamCSM Intake
Escalation reaches me with full context: query history, account tier, previous contacts, agent notes. I assess whether to handle directly, coach the agent on response, or loop in a third party (product, finance, leadership).
CSMAccount Signal Feed
Beyond individual escalations, support volume and patterns feed the broader account health picture. A spike in contacts from a key account, a recurring complaint, a customer who's called three times in a week — all of these are signals that inform the proactive CSM cadence.
CSM MotionThe Tooling Reality
The tools started scrappy and evolved as the process stabilised. The sequencing matters — a ticketing platform bought before the team knows what it's doing is expensive overhead. Tools should systematise a working process, not substitute for one that doesn't exist yet.
Shared Inbox & SharePoint
One support email address, one SharePoint knowledge base, and Genesys handling inbound calls from day one. Unglamorous but functional. The priority was ensuring nothing got lost — a shared inbox everyone could see beat five separate inboxes where queries disappeared, and Genesys gave us call routing and recording without building that infrastructure from scratch.
Basic Ticket Tracking
Spreadsheet-based ticket log for volume tracking, query categorisation, and SLA monitoring. Not elegant, but it produced the data needed to make the case for a proper ticketing system — and it forced the team to develop logging habits before a platform enforced them.
Helpdesk Platform + Genesys Reporting
Once email ticket volume and team process were stable, a proper helpdesk made sense for the written channel. Genesys was already handling calls — and its reporting suite became a core part of the operating rhythm, surfacing call volume, time-of-day patterns, and handle times. That data fed directly into agent performance reviews alongside ticket quality.
CRM Integration
Support activity connected to the account record in Salesforce — so ticket volume, escalation history, and recurring issues were visible alongside commercial relationship data. This is where the blended model pays off at scale: one account view, not two parallel tracks.
Managing the Dual Track
Running support build and CSM work in parallel is a prioritisation challenge as much as an operational one. The work of building the support function — hiring, onboarding, process design, quality monitoring — competes directly with the strategic work of managing accounts, running QBRs, and staying proactive on churn risk.
The way through is to be deliberate about which track gets which kind of attention, and when.
Operational & Time-Boxed
Support build work was batched into defined blocks — hiring reviews, process audits, quality checks, training sessions. Reactive escalation handling was addressed as it arrived, but build work was protected from interruption where possible.
Strategic & Calendar-Driven
Account management operated on a fixed cadence — weekly pulse reviews, monthly account health checks, quarterly business reviews. The calendar was the protection mechanism. If a QBR was in the diary, it happened. Support build work didn't displace strategic account time.
Escalations as CSM Intelligence
The blur between the two tracks was intentional at the escalation layer. Support escalations weren't interruptions to CSM work — they were inputs to it. A pattern of escalations from one account informed the next QBR. A recurring complaint became a product feedback item.
Knowing When to Delegate
The most common failure mode in this model is the CSM becoming a second-tier support agent by default. As the team grew in confidence, the work was to push more decisions down — and resist the pull to stay involved in queries the agents were fully capable of handling.
Systems Integration Awareness
The manual phase of this build was always designed with the connected-stack endpoint in mind. Process decisions that seem purely operational — how tickets are categorised, how escalations are documented, how call outcomes are logged — all become data architecture decisions when the tooling matures.
In a mature implementation, support operations and CSM motion share a single account view. Salesforce holds the commercial relationship — contract value, renewal date, account tier. The helpdesk platform surfaces operational health — ticket volume, resolution times, escalation rate, recurring themes. Genesys contributes call data — volume by time of day, handle times, recording access for quality review. Jira tracks the product issues that originated as support contacts. And a CS platform like Gainsight or Totango synthesises all of these signals into an account health score that both the support team and the CSM can act from.
Building that integrated stack from day one isn't realistic at the scrappy stage. But designing the manual process to mirror that eventual architecture means the transition from spreadsheet to platform is an evolution — not a rebuild.
What Goes Wrong
The recurring failure modes in this model — from this build and others like it in the fintech space.
The CSM becomes the default escalation point for everything
If escalation criteria aren't clear, agents escalate everything to avoid being wrong. The CSM's time fills with second-tier support work, strategic account time collapses, and the whole model inverts. Defining — and enforcing — the threshold is ongoing work, not a one-time setup task.
Phone payment process designed informally
In payments, taking card data over the phone has compliance requirements that can't be improvised. PCI scope, call recording rules, what agents can and can't repeat back — these need to be designed into the process from the start, not bolted on after an incident.
Support and CS treated as entirely separate tracks
When support and CS operate in silos, the account view is always partial. A CSM going into a renewal conversation without visibility of support volume, escalation history, or recurring complaints is flying blind on a significant part of the customer experience.
Hiring for personality over process compliance
Frontline support in fintech needs warmth and composure — but it also needs people who follow the process precisely and document consistently. A charming agent who improvises on payment calls or skips logging is a risk. Hire for both.
Buying the platform before the process is stable
A ticketing system configured before the team knows what it's actually handling produces a platform that reflects aspirations, not reality. The categories are wrong, the workflows don't match how queries arrive, and adoption suffers. Wait until the manual process is stable — then systematise what's working.
The Framework at a Glance
The build sequence — from nothing to a functioning, integrated support and CS operation.
Categorise every inbound query. Understand the volume, the mix, the peaks. Know what you're building before you build it.
Define response SLAs by query type, centralise the inbox, document the phone payment process, establish escalation criteria. All before the first agent starts.
Email templates for the top query types. Phone payment runbook. Escalation decision tree. Agent one should have answers before their first live contact.
First hire shapes team culture. Hire for composure, written clarity, and process discipline. Domain knowledge is a bonus. Sequence one agent before scaling.
Design the escalation path so support activity becomes account intelligence — not just a reactive queue. Volume patterns and recurring issues inform the proactive CSM cadence.
Introduce the helpdesk platform once manual process is stable. Connect to CRM. Use Genesys reporting data in performance reviews. Delegate more decisions to the team as competence grows. CSM time protected for strategic account work.