Skip to content
EN

Services

Contact center platform support after launch: tier 1 and tier 2

After launch, the platform needs ongoing support: answering agents, troubleshooting failures, updating call flows. It helps to split the work into tier 1, tier 2, and ongoing development, and to agree on priorities and escalation before the first incident.

Pavel Ivanov, founder of CONTACT.WORK · · 7 min read

Contact center platform support after launch: tier 1 and tier 2

After launch, a contact center keeps changing: agents ask questions, new fields appear in the CRM, telephony components get updated. If no one owns support, small failures pile up, and every minute calls go unanswered means paid agent hours with no work and customers who go elsewhere. Here is what a failure costs, how to set up tier 1 and tier 2 support, escalation, and incident reviews, and how to tell whether support is working well.

What ongoing support includes

Support has three parts. Tier 1 takes requests and resolves routine questions right away. Tier 2 handles complex incidents in telephony, integrations, and servers. Development covers updates and custom work for new needs. At CONTACT.WORK, the same engineers who implemented the platform also support it, so they do not have to relearn your call flows.

The process is the same in the cloud, on your own servers, and in a hybrid deployment. The only difference is who is responsible for infrastructure: on your servers, tier 2 also looks after the servers, but access and areas of responsibility need to be agreed before the first incident, not during it.

What a failure costs

Take a line from the agent calculator: 120 calls an hour with 11 agents on the line. If no calls get through for an hour, the company pays for 11 agent hours with no work and loses 120 calls. Using the values from the missed calls calculator – half of calls are potential purchases, with a 10% conversion rate – that is up to 6 lost sales on top of the idle time. And every 15 minutes of downtime costs a quarter of that.

Small failures cost just as much – they are simply harder to see. If 30 agents lose 10 minutes a day to a recurring problem – a stuck status, a headset reconnect, searching the CRM for a call by hand – that is 5 paid hours a day, 110 hours over 22 business days, and 1,320 hours a year. One knowledge base article or one fixed setting removes that loss.

How these numbers turn into priorities. Cost of an incident = idle agents × hours × hourly cost + lost calls × share of calls that are potential purchases × conversion rate × average order value. A critical incident stops the whole line, and its cost grows every minute – it gets the fastest response time and round-the-clock contact. A high-priority incident affects some agents or one important queue. A normal one gets in the way but does not stop work. Plug your own line into the formula, and you will see what response times you need.

What you pay for

The CONTACT.WORK platform itself is free: no licenses and no platform fees. You pay for technical support under the support plan you choose, plus hosting if the platform runs in our cloud. The price does not depend on call volume. The only separate charges are speech recognition, speech synthesis, and the language model for AI agents – or you run them on your own GPU server or a Mac mini.

You can start small: tier 1, tier 2, development, and training can each be purchased separately, with the rest added later. If you have your own tier 1, it hands complex cases to our engineers under agreed rules.

Tier 1: answers right away and collects the details

Tier 1 takes requests by phone, email, and chat, around the clock if needed; channels and hours are agreed for each project. It resolves routine questions without escalating them:

  • working in the interface: statuses, transfers, call forms, reports;
  • the agent workstation: headset, microphone, browser, signing in;
  • user accounts and access permissions.

If a question is not routine, tier 1 logs an incident and collects everything the engineer needs: the time, phone number, queue, agent name, what happened, and whether it keeps happening. The more complete the details, the faster tier 2 finds the cause – and the fewer minutes of downtime from the calculation above.

Tier 2: fixes the root cause

Tier 2 engineers handle complex incidents:

  • telephony: call quality, routing, the IVR (phone menu), SIP trunks to carriers;
  • integrations: passing calls and recordings to the CRM, data exchange with internal systems;
  • servers and network: availability, load, storage for call recordings.

An incident is closed when the root cause is fixed and the call flow is confirmed to work for agents again. A symptom going away is not a reason to close the ticket. That is why the engineer also looks at similar tickets from previous weeks: if the problem repeats for different agents or at different times, the cause is systemic – in settings, an integration, or infrastructure.

Escalation process

  1. An agent or administrator reports a problem by phone, email, or chat.
  2. Tier 1 logs the ticket, collects the details, and sets the priority according to the agreed scheme.
  3. Routine questions are resolved on the spot; the rest go to tier 2 along with the collected details.
  4. A tier 2 engineer finds the cause, fixes it, and reports what changed.
  5. Together with the customer, they confirm everything works and close the ticket.
  6. The solution goes into the shared knowledge base.

There are usually four priorities: critical – no one can take calls; high – some agents or an important queue are affected; normal; and consultation. For each level, agree on response times, who gets notified and how, and who on the customer side makes decisions.

Two incident reviews

Some calls stopped showing up in CRM records, and sales reps call customers back without seeing the previous conversation. Tier 1 finds out when this started, for which agents, and on which calls, and passes the details to tier 2. The engineer compares the platform logs with the CRM responses and sees that someone made a new CRM field required or cut back the permissions of the service account, so the CRM started rejecting integration requests. The engineer fixes the cause, resends the missing data where possible, and adds a rule to the knowledge base: notify the support team before changing CRM fields.

Remote agents complain that customers cannot hear them. The cause is usually the network or router settings on the agent's end. The result of the review is a knowledge base article, and from then on tier 1 closes these tickets without passing them up.

Updates and custom work

The platform and its components are kept up to date, and call flows, reports, and integrations change along with your processes. Every change is tested on a staging environment first and only then released to agents on live calls.

  • Updates are planned in advance, and installs are scheduled around call volume.
  • A rollback plan is prepared before the release, not after a failure.
  • Changes to call flows, reports, and integrations follow the same path: specification, testing, release.
  • Reports for the first hours after a release get a separate review.

Changes on your side – new fields and permissions in the CRM, switching carriers, moving servers, rebuilding the network – should also be coordinated with the support team: many unexpected failures happen where systems meet. We cover how larger changes work in our article on custom platform development.

A shared knowledge base

Every solution goes into a knowledge base your team uses too: instructions for agents and administrators, descriptions of call flows and integrations, incident reviews. Articles are written right after the fix, following one template: symptom, cause, what to do, whom to contact if it does not help. Repeat tickets go down, and a new administrator does not have to piece together how the system works from colleagues' memories.

How to judge support quality

  • Time to first response and time to resolution – separately for each priority.
  • Share of tickets resolved at tier 1.
  • Share of repeat incidents with the same cause.
  • Number of incidents after updates.
  • Agents and administrators know where to go and what is happening with their request.

Where to start

  1. Name an administrator on your side who makes decisions and approves work.
  2. List your critical queues and call flows – what has to work first.
  3. Calculate what an hour of downtime costs your line using the formula above: priorities and response times depend on it.
  4. Agree on four priorities, contacts for urgent issues at night and on weekends, and access for tier 2 if the platform runs on your servers.
  5. Once a month, review ticket statistics with the support team: recurring questions show where you need an article, training, or custom work.

Need support for your contact center?

Tell us how your contact center works and what your agents ask about most – we will suggest how to set up tier 1 and tier 2.

Discuss your project

Newsletter

Get new articles by email

Articles on contact center operations, AI agents, and quality assurance.