Building a customer support function at a B2B integration firm

About the client

Starting point

The client delivered specialist integration solutions to its customers, which after successful implementation transitioned into long-term application support. Support ran within the same company — but the shift in operating model never happened. Support ran in much the same mode as delivery, often with the same or overlapping team. There was no formal handover, no “closed” transition between project phases, no dedicated organisational unit treating support as a discipline in its own right.

On paper it looked like support was working — customers called a dedicated number, sent emails, or raised tickets through their own service desks. In reality, the process behind it was missing. There was no formal capacity planning, priorities were managed by intuition, and contracts with individual customers varied. SLA breaches happened regularly and generated penalties that further eroded the division’s financial performance.

Management recognised that the company was creating a problem that would only grow as the customer base expanded. At the current trajectory, penalties would keep increasing, and every new tender would be not just about price but about what compensation customers could claim for SLA failures.

What the problem was

• No handover/takeover process between the delivery and support phases of a project
• No dedicated support manager role with defined outputs
• Support capacity planning was driven by intuition, not data
• Ticket prioritisation was “whoever shouts loudest”
• Application support contracts varied from customer to customer without a clear rationale
• No unified service catalogue — one customer got service A, another a similarly named service B with a different definition
• Management reporting used development metrics, not operational support indicators
• SLA breach penalties were growing to financially significant levels

What I did

The engagement lasted 2–3 months from initial analysis through to stable operations and ran several parallel workstreams.

Process and role analysis

I went through the actual flow of engagements from both sides — delivery and support. Interviews with heads of delivery and support, operators, account managers, and the key people who were carrying the whole discipline in their heads.

Three key findings emerged from the analysis:

• The company made no distinction between project mode and support mode — even though these are fundamentally different operating disciplines with different metrics, culture, and organisation of work.
• The support manager role formally existed but had no defined outputs or mandate.
• The contract base was the result of historical evolution, not deliberate design — every customer had a different support SLA and a different service catalogue.

Designing the handover/takeover process

I designed a formal handover process between delivery and support with clear gates:

• Technical readiness checklist — documentation, runbooks, known incidents, dependencies
• Handover presentation — the delivery team walks the support team through the solution
• Validation and sign-off — the support team confirms it has everything needed to take over
• Formal handover — written record signed by both sides, hard transition date
• Post-handover support — delivery team remains on escalation for tickets from the first 30 days

Standardising contracts and the service catalogue

I reviewed all active application support contracts and created:

• Unified service catalogue — five service types with a clear definition of scope, response times, and process
• Standardised SLA tiers (Bronze / Silver / Gold / Platinum)
• Contract revision plan — align each customer to the new framework at next renewal
• Transition rules — how to move customers from the old model to the new one without escalation

Defining the support manager role and outputs

The support manager received a defined role with concrete responsibilities:

• Capacity planning and team allocation
• Backlog prioritisation
• Management reporting (new metrics — see below)
• Communication with account managers and escalations
• Managing the service reporting cadence with customers

New metrics and KPIs for management reporting

I rebuilt the management reporting from scratch. Instead of development metrics (story points, velocity), we introduced operational indicators:

• SLA compliance by tier and customer
• Ticket volume (opened, resolved, waiting)
• Ticket typology (bug / change / consultation / incident)
• Straight-through rate and escalation rate
• Financial metrics — support costs, penalties, upsell opportunities

What the client received

• “How support works here” document — process, roles, SLA, handover, escalation
• Unified service catalogue with scope definition and SLA tiers
• Handover/takeover checklist and process documentation
• Support manager role description with responsibilities and outputs
• Management reporting templates with new operational metrics
• Customer service reporting system — structure, frequency, accountabilities
• Contract revision plan with transition rules
• Ongoing coaching for the support lead and support manager throughout the implementation

What the impact was

SLA breach penalties dropped to zero by the end of the quarter following implementation. Within 2–3 months of launch, the rate of SLA breaches fell by 90%. Once support started operating as a standalone discipline with its own rules and metrics, a range of follow-on opportunities opened up.

Upsell with existing clients — a support manager with visibility into tickets could identify opportunities for change requests and solution extensions. Proactive intervention — tracking trends in incidents made it possible to prevent outages rather than fix them. Release management — planned change deployments coordinated with customers instead of ad-hoc fixes. Better work distribution — unintended overlap between support and delivery teams stopped happening.

The company gained a functioning support division with its own process and metrics. Management had data to manage support by — both in terms of capacity and commercially.

A note from practice

The hardest part of this engagement was not the technical work but the culture and paradigm shift. In B2B integration firms, delivery teams are often treated as “the main act” — they create value, they deliver. Support is seen as a “secondary discipline” to be bolted on contractually. This perspective shows up in roles, career paths, compensation, and the mental model of management. If this cultural layer doesn’t change, technical process changes won’t hold on their own. A significant part of my work in this engagement was therefore about communication — with the support manager, the heads of delivery, and the company’s leadership — so that support would start to be seen as a discipline in its own right, not just “service after delivery.”

Related service

This engagement was a classic example of the business-IT bridge — setting up the organisation, processes, contracts, and communication so that support functions as a real discipline rather than a continuation of the delivery phase.