Every customer request follows the same path, whoever picks it up.

Gully Sales designs how support actually runs in your business: where requests arrive, who owns each one, what counts as urgent, when it escalates, and what the customer hears at every step.

One intake path, so nothing is lost between phone, WhatsApp and email.
Written priority and escalation rules anyone on the team can apply.
A weekly queue review that catches ageing requests before the customer does.

Book a free audit Talk to us

Gully Sales Private Limited works with small and medium businesses across India, and the process is built with the people who will run it.

In one paragraph

What is Customer Support Process Design for Indian SMBs?

Customer support process design gives your business one written path for every customer request: how it arrives, how it is logged, who owns it, how quickly it is answered, when it is escalated and how it is closed. Gully Sales designs that path with your team, sets the priority rules and installs the weekly review that keeps it working.

The problem

Support depends on who answers, not on how your business works.

Most Indian SMBs do not have a support problem on paper. They have a team that cares and a founder who picks up the phone. The trouble is that every request takes a different route: one customer calls the owner, another messages a salesperson on WhatsApp, a third writes to a mailbox nobody owns. Each request is handled well by whoever catches it, and badly by nobody in particular. When volume rises, or one experienced person is on leave, the gaps show — and the customer notices them first.

You will recognise it as

Customers reach you on phone, WhatsApp, email and social messages, and no single list shows what is still open.
The same issue is answered differently by two people, because each one decides for themselves what a fair reply looks like.
Requests are chased by the customer rather than by you, and an apology for the delay has become a standard opening line.
One or two experienced people quietly hold everything together, and their leave day is visibly harder than every other day.
Nobody can say how many issues arrived last month, what they were about, or how long each one took to close.
Escalations reach the founder as angry calls rather than as a planned handover with a note attached.

What it costs the business

Small problems turn into lost renewals, because a customer who waited three days for an answer remembers that when the contract comes up.
Your senior people spend their day inside routine queries, and the work only they can do slips to evenings and weekends.
Repeat issues are never fixed at the source, since nothing counts how often the same complaint arrives.
New joiners take months to become useful, because there is no written way to handle a request, only watching someone who knows.
You cannot answer a customer or a tender that asks what response times you commit to, so you either guess or promise too much.

Why it persists. It persists because responsiveness looks like the fix. When a customer is unhappy, what works today is a capable person dropping everything and sorting it out. That is genuinely good service, and it hides the missing process for years. Designing the process, by contrast, produces nothing visible on the day it is finished. So the business keeps rewarding the rescue and never funds the design, until volume grows past what rescue can carry and the rescuers are tired.

If it stays unresolved. Left alone, the load moves upward. The owner and two or three senior people become the escalation route for everything, so their attention goes to yesterday's problems instead of next year's business. Capable staff leave, because unstructured pressure is exhausting. And churn arrives quietly: customers rarely announce that support was the reason they stopped buying, they simply do not come back.

What changes

What changes once support runs to a written process.

In the first weeks

Every request, from every channel, lands in one place with an owner and a due time against it.
Your team has written rules for what is urgent, what can wait, and who decides when the two collide.
You can state your response commitments to a customer, a dealer or a tender without inventing them.

In how the work runs

A new joiner handles common requests in their first week, using the process and the standard replies.
Ageing and stuck requests surface in a weekly review instead of surfacing as a customer's angry call.
Handovers between shifts, branches and people happen through the record rather than through memory.
The queue divides the day's work, so nobody is idle while a colleague is buried.

In sales and marketing

Senior people get their week back, because routine requests no longer need them to be involved.
Repeat issues get counted, so the top three causes can be fixed at the source instead of answered again.
Service standards become something you can put in a proposal, which matters in contracts and tenders.

In what management can see

You can see volume, type, response time and backlog for the month without asking anyone to reconstruct it.
Accounts collecting unresolved issues become visible before renewal, not after they have left.

Over the longer term

Support capacity grows with volume, because adding a person means training them on a process that exists.
The way your business serves customers becomes something you own, not something a few people carry.

Gully Sales controls the process design, the rules, the templates, the tool setup, the reporting and the training we build with your team. Whether resolution times and satisfaction improve also depends on your staffing, your product and how consistently the process is followed after we leave.

Who it is for

Support process design suits these situations.

The businesses it suits

Service, subscription and relationship-led businesses whose customers contact them regularly after the sale.
Companies where two to twenty people handle requests, and the load is now beyond what memory can hold.
Businesses whose customers reach them on WhatsApp, phone and email at once, with no shared record of any of it.
Founders and directors who are still the final escalation point for routine issues and want that to stop.
Teams that already own a helpdesk tool but use it as a mailbox, because no process was designed around it.
Businesses adding branches, dealers or a second shift, where asking the person who knows no longer works.
Companies being asked by customers or tenders to commit to response times they cannot currently measure.

What usually prompts the call

A customer you valued left, and the reason was how a service issue was handled rather than what you charge.
The person who quietly held support together has resigned, and nobody can describe what they used to do.
Support volume has risen sharply after a new product, a new region or one large customer joining.
A contract or tender asks for response and resolution commitments you cannot honestly state today.
The team has grown and the same question now gets three different answers depending on who replies.
You have bought a helpdesk tool, and six months later most requests still arrive outside it.

What Gully Sales does

The work, component by component.

Service standards your team can actually meet

We write what a customer can expect from you: which channels are covered, what hours you genuinely work, how quickly a first response goes out, how long resolution should take at each priority, and what happens when a fix will take longer. Targets are set from your real staffing and volume rather than from what sounds impressive, because a published standard you miss is worse than none.

Why it matters:: A promise nobody on the team believes is quietly ignored, and the customer learns to expect nothing.
You receive:: Written service standards per channel and priority, with hours of cover and the exceptions stated plainly.
Business value:: Your team knows what good looks like, and your customer stops guessing when they will hear back.

Intake map across every channel

We list every way a customer currently reaches you — the landline, a mobile number printed on an old invoice, WhatsApp to a salesperson, the website form, email, social messages, walk-ins — and design one path that brings all of them into a single queue. Channels you cannot serve properly are either closed or given an honest automatic reply that says where to go instead.

Why it matters:: A request that never enters a list cannot be measured, chased or fairly divided between people.
You receive:: Channel inventory, intake routes, and the rule for how each channel becomes one logged request.
Business value:: Nothing falls between a phone call and a message, and the day's real workload becomes visible.

Categories, priority and routing rules

We build a short list of issue categories that match how your business actually breaks, and a priority rule that separates a stopped operation from an inconvenience. Routing follows from it: which requests the front line closes, which need a technical person, which belong with accounts, and who decides when two urgent things arrive in the same hour.

Why it matters:: Without a written priority rule, urgency is decided by whoever sounds angriest, not by what costs most.
You receive:: Category list, priority matrix with worked examples, and routing rules by category and priority.
Business value:: Attention goes to the issues that hurt the customer and the business most, on a rule everyone can see.

The request lifecycle, end to end

We design the path a request travels: logged, acknowledged, diagnosed, worked, resolved, confirmed and closed, with the conditions for moving between stages and a clear definition of what waiting on the customer or waiting on a supplier means. We also settle the small things that cause arguments later: what is recorded at each step, and who is allowed to close a request.

Why it matters:: Most disputes inside a support team are really disagreements about whether something was finished or still open.
You receive:: Documented lifecycle with stage definitions, entry and exit conditions, and the closure rule.
Business value:: Everyone reads the same status the same way, including the customer receiving the update.

Ownership, escalation ladder and cover

We name who answers, who resolves, who approves an exception and who owns each category. Then we agree the ladder: who is contacted when a request breaches its target or turns serious, at what interval, what information must travel with the handover, and who covers leave, weekends, holidays and festival weeks when half the team is away.

Why it matters:: An escalation with no ladder becomes a direct call to the owner, which teaches customers to skip your team entirely.
You receive:: Ownership map, escalation ladder with triggers and timings, handover note format and a cover plan.
Business value:: Serious issues reach the right person early, and the founder stops being the default helpline.

Standard replies and diagnostic checklists

We write the replies your team sends most often — acknowledgement, holding update, request for missing information, resolution, and an apology where the mistake was yours — in your tone and in the languages your customers actually write in. Alongside them sit short diagnostic checklists for your most frequent issues, so the first questions asked are always the useful ones.

Why it matters:: Consistency and speed come from having the words ready, not from asking tired people to write well at speed.
You receive:: Reply templates by scenario and channel, plus diagnostic checklists for your highest-volume issues.
Business value:: Replies go out faster, sound like one company, and stop making commitments the team cannot keep.

Setting the process up in the tools you have

We configure the process inside whatever you use now: a helpdesk tool, a shared mailbox, your CRM, a WhatsApp Business number or a well-built spreadsheet. That means queues, statuses, tags, assignment rules, due times and a few simple automations. Where the current tool genuinely cannot carry the design, we say so and describe what would, without selling you software.

Why it matters:: A good process fails when it lives somewhere nobody opens during a busy morning.
You receive:: Configured queues, statuses, tags, assignment rules and reports in your existing system, with a how-to.
Business value:: The process sits where your team already works, so following it is easier than working around it.

Quality review, reporting and the improvement loop

We set up a light quality check — a small sample of closed requests read each week against agreed criteria — and the report your manager reads: volume by category, first response and resolution against standard, backlog and ageing, reopened requests and the recurring causes. Then we install the weekly meeting where those numbers change something specific.

Why it matters:: A process that is not inspected drifts back to old habits within a quarter, usually without anyone noticing.
You receive:: Quality checklist and sampling rhythm, a weekly report pack, and the review agenda with its decisions.
Business value:: Support stops being a black box, and recurring problems get fixed at the source instead of answered again.

What you will have at the end.

Written service standards per channel and priority: hours of cover, response and resolution targets, and the exceptions.
Channel inventory and intake routes showing how every call, message and mail becomes one logged request.
Issue category list built from your last few months of real requests, not from a generic template.
Priority matrix with worked examples, so two people classify the same issue the same way.
Routing rules by category and priority, including what happens when two urgent requests arrive together.
Ownership map naming who answers, who resolves, who approves exceptions and who owns each category.
Documented request lifecycle with stage definitions, entry and exit conditions and the rule for closure.
Escalation ladder with triggers, timings, handover note format and cover for leave, weekends and holidays.
Reply templates by scenario and channel, in the languages your customers actually write to you in.
Diagnostic checklists for your most frequent issues, written so a new joiner can follow them unaided.
Configured queues, statuses, tags, assignment rules and reports inside your existing tool, with a how-to.
Weekly report pack, quality sampling checklist and review agenda, with an anonymised sample you can see first.

How it runs

The engagement, step by step.

1
Read what actually arrives today
We go through the last few months of real requests wherever they exist: the shared mailbox, WhatsApp threads, call registers, the complaint book, invoice disputes and whatever your team keeps privately. We count them, group them by type, and time a sample from first contact to resolution, so the design starts from your evidence instead of an assumption about what customers ask for.
You provide:
Access to mailboxes, message histories, call records or registers, and an hour each with two or three people who handle requests.
We produce:
A baseline note: volume, mix by type, current response and resolution times, and every channel in use.
Done when:
You agree the baseline is a fair picture of what customers ask for and how long they currently wait.
2
Agree the service standards
We work out what your business can honestly promise at current staffing: hours, first response, resolution targets by priority, and what a customer is told when a fix will take longer than that. Where the truthful answer is slower than you would like, we write the slower number and treat improving it as a separate piece of work with its own plan.
You provide:
Staffing and shift reality, commitments already made in contracts, and a decision on hours of cover.
We produce:
Written service standards per channel and priority, with exceptions and the points where they escalate.
Done when:
Your team reads the standards and believes they can be met on an ordinary week.
3
Design the flow, the priorities and the roles
We map the path from arrival to closure: intake, categorisation, priority, routing, ownership, work, resolution, confirmation and close. Roles are named at each step, the priority matrix is worked through against real past requests, and the escalation ladder is agreed with the people whose names appear on it rather than decided above them.
You provide:
Time with the support team and their supervisor, and a decision on who may approve exceptions.
We produce:
Draft process flow, priority matrix, routing rules, ownership map and escalation ladder.
Done when:
Two people classify and route the same sample of past requests the same way.
4
Write the replies and the checklists
We draft the templates and diagnostic checklists for your most common issues, in the tone and languages your customers use. Your team edits them, because a reply they did not help shape gets rewritten by hand anyway, and the whole point is to give that time back.
You provide:
Examples of replies you were happy with, your tone preferences, and a working session with the team.
We produce:
Reply templates by scenario and channel, and checklists for the highest-volume issue types.
Done when:
A team member handles a live request end to end using only the templates and checklists.
5
Set it up inside your tools
We configure queues, statuses, tags, assignment rules, due times and reports in whatever system you already use, so following the process is the path of least resistance rather than an extra document to remember. Where the tool cannot support the design, we say so plainly and describe what would, so you can decide separately.
You provide:
Administrator access to the helpdesk, mailbox, CRM or WhatsApp Business account, and IT help if needed.
We produce:
A configured system with queues, statuses, assignment rules and reports, plus a short written how-to.
Done when:
A request logged in the morning appears in the right queue with the right owner and a due time.
6
Run it in with the team and correct it
We work alongside your team on live requests for an agreed period: watching where the process is awkward, changing the rules that do not fit, and coaching the habits that decide whether it survives. Almost every design needs adjustment in the first weeks, and this is the stage where that happens instead of being quietly abandoned.
You provide:
Live requests, team time each week, and permission to change rules that turn out to be wrong.
We produce:
A corrected process, updated templates, and written feedback for each person handling requests.
Done when:
A full week runs with requests logged, routed and closed under the new process without our help.
7
Install the review and hand over
We start the weekly review: reading the report, sampling closed requests for quality, looking at ageing and reopened items, and choosing one recurring cause to fix that week. We chair it until your manager can run it alone, then hand over the pack, the documents and the rules behind every decision we made.
You provide:
A named owner for the process, and that person's attendance at the reviews from the first week.
We produce:
Report pack, quality checklist, review agenda and a handover file with every document and rule.
Done when:
Your manager has run two reviews without us and changed something in the process as a result.

Ways to work with us

You can start with a short review or design the whole process.

Support process review

A short engagement that reads your current requests, times a sample and reports where the process breaks, with the things we would fix first. Useful when you want a clear view before committing the team to a rebuild.

Support process design and build

The full design: service standards, intake, categories, priority, routing, ownership, lifecycle, escalation, templates, tool configuration and the reporting pack, built with the people who will have to run it.

Run-in support on live requests

We work beside your team on live requests for an agreed period, correcting the rules that do not survive contact with a busy morning and coaching the habits that keep the process alive after we leave.

Ongoing service review facilitation

A recurring engagement in which we chair the weekly or monthly service review, sample closed requests for quality, and work through the recurring causes with your manager each quarter.

Why Gully Sales

What you are actually choosing when you choose us.

The process is designed with the people who will run it.

A flow written by outsiders alone survives until the first busy morning. Your team helps set the priorities, the routing and the replies, so what they receive belongs to them and is still in use months after we have gone.

We design for how Indian customers actually reach you.

A WhatsApp message to a salesperson, a call to the owner's mobile and a message on Instagram are all normal here. The process is built around those channels, not around a support model that assumes email and a web portal.

We start from your real volume, not a template.

Categories, priorities and targets come from reading your last few months of requests. That is why the standards are ones your team can meet on an ordinary week rather than numbers copied from a larger company.

Support is connected to the rest of your revenue system.

Gully Sales works across marketing, sales, customer success and revenue operations. Recurring issues can be traced back to what was promised during the sale or how onboarding was run, instead of only being answered faster.

Everything we build can be inspected.

Response time, backlog, ageing, reopened requests and recurring causes are reportable from the week the process starts. Improvement becomes a matter of evidence rather than an opinion expressed in a monthly meeting.

We will tell you when the process is not your problem.

If your requests are mostly caused by a product fault, a delivery failure or too few people, we will say so. Designing a faster route for the same complaints would take your money and leave the customer no happier.

Where it applies

The same service, in different businesses.

Industry	The situation	How it applies	Likely benefit
Equipment and machinery service	A machinery supplier's customers call the service engineer directly when a machine stops, so the office hears about a breakdown only when the customer rings to complain about the wait.	Breakdown calls are logged at intake, priority is set by whether production has stopped, and the engineer's day is planned from one queue rather than from whoever called first.	The office can tell a customer when help is coming, and repeat faults on the same machine become visible.
Software and technology services	A small software company answers customers from a shared mailbox, and two support staff sometimes reply to the same person with different answers on the same day.	Requests are assigned on arrival, statuses show who is working on what, and standard replies settle the common answers so the same explanation is not written twice.	Duplicate replies stop, and the team can show a prospect what its response standards actually are.
Healthcare and clinics	A clinic handles appointment changes, report queries and billing questions on the same phone line, so time-sensitive clinical follow-ups wait behind routine calls.	Categories separate clinical, scheduling and billing requests, and the priority rule routes anything clinical to a named person immediately.	Patients with urgent needs are reached first, and routine queries stop interrupting clinical staff.
Building materials and dealer networks	Dealers raise stock, damage and warranty issues with whichever salesperson they know personally, and very little of it reaches the branch that has to act.	One intake route logs dealer issues by category and branch, with an escalation ladder when a claim ages past its target.	Dealers stop chasing individuals, and head office can see which branches carry the most unresolved claims.
Facility and maintenance services	A services company works across many client sites, and each site manager has a different idea of what counts as an emergency.	A priority matrix with worked examples is agreed with clients, and response targets are set per priority rather than per caller's tone of voice.	Contract reviews are held against agreed standards, and the loudest client no longer sets the day's order.
Education and training institutes	Parent and student queries arrive on WhatsApp, phone and email through admission season, and the counselling team loses track of who is still waiting.	All channels feed one queue with owners and due times, and holding replies go out automatically when the volume spikes.	Fewer families give up while waiting, and next season can be staffed from counted volume rather than guesswork.

Equipment and machinery service

The situation:: A machinery supplier's customers call the service engineer directly when a machine stops, so the office hears about a breakdown only when the customer rings to complain about the wait.
How it applies:: Breakdown calls are logged at intake, priority is set by whether production has stopped, and the engineer's day is planned from one queue rather than from whoever called first.
Likely benefit:: The office can tell a customer when help is coming, and repeat faults on the same machine become visible.

Software and technology services

The situation:: A small software company answers customers from a shared mailbox, and two support staff sometimes reply to the same person with different answers on the same day.
How it applies:: Requests are assigned on arrival, statuses show who is working on what, and standard replies settle the common answers so the same explanation is not written twice.
Likely benefit:: Duplicate replies stop, and the team can show a prospect what its response standards actually are.

Healthcare and clinics

The situation:: A clinic handles appointment changes, report queries and billing questions on the same phone line, so time-sensitive clinical follow-ups wait behind routine calls.
How it applies:: Categories separate clinical, scheduling and billing requests, and the priority rule routes anything clinical to a named person immediately.
Likely benefit:: Patients with urgent needs are reached first, and routine queries stop interrupting clinical staff.

Building materials and dealer networks

The situation:: Dealers raise stock, damage and warranty issues with whichever salesperson they know personally, and very little of it reaches the branch that has to act.
How it applies:: One intake route logs dealer issues by category and branch, with an escalation ladder when a claim ages past its target.
Likely benefit:: Dealers stop chasing individuals, and head office can see which branches carry the most unresolved claims.

Facility and maintenance services

The situation:: A services company works across many client sites, and each site manager has a different idea of what counts as an emergency.
How it applies:: A priority matrix with worked examples is agreed with clients, and response targets are set per priority rather than per caller's tone of voice.
Likely benefit:: Contract reviews are held against agreed standards, and the loudest client no longer sets the day's order.

Education and training institutes

The situation:: Parent and student queries arrive on WhatsApp, phone and email through admission season, and the counselling team loses track of who is still waiting.
How it applies:: All channels feed one queue with owners and due times, and holding replies go out automatically when the volume spikes.
Likely benefit:: Fewer families give up while waiting, and next season can be staffed from counted volume rather than guesswork.

Proof

Work we can point to.

Vijaya Hospital

The problem:: The hospital needed a stronger presence and better handling of the enquiries and day-to-day operations that come with it.
What we did:: Gully Sales worked on the hospital's digital presence, its patient enquiries and its operational efficiency.
Over:
The result:: The case study reports a strengthened digital presence, increased patient enquiries and improved operational efficiency.

Read the case study

Natural Gases, an industrial and medical gases business

The problem:: The business needed to be found by its buyers and needed sales operations that could handle the demand consistently.
What we did:: Gully Sales worked on visibility, on sales operations and on demand for its industrial and medical gases, using smarter workflows.
Over:
The result:: The case study describes improved visibility, better sales operations and growing demand, with smarter workflows behind them.

Read the case study

How it is measured

Baseline: Before anything changes we count what happens today: requests received each week by channel and type, how long a first response takes, how long resolution takes, how many are reopened, how many stay open beyond a week, and how many reach you personally. Where no records exist we log manually for two or three weeks first, and say plainly that the baseline starts there.
Reporting: Volume, response and resolution times, backlog and ageing are read weekly, with a quality sample. Satisfaction and recurring causes are reviewed monthly, and the standards themselves each quarter.
Measurement period: Response times and backlog usually move within the first month. Satisfaction, repeat contact and renewal effects need two to three quarters, since they follow customers served under the new process.

The metrics that matter here

First response time and resolution time against your published standard, by priority and by channel.
Support resolution: requests closed within target, first-contact resolution, and reopened requests.
Backlog and ageing: requests open past their target, and the oldest item in the queue each week.
Adoption of the process: the share of requests logged at intake rather than handled off the record.
Time to value on a new customer's first request, from arrival to a usable answer.
Customer satisfaction on closed requests, and NPS where you already run it, read over the same period.
Renewal rate and churn among accounts carrying open or repeated service issues, against the rest.
Expansion revenue from accounts served under the process, tracked apart from new business.
Lifetime value by cohort, once at least two renewal cycles have passed under the new process.
Escalations reaching an owner or director each month, and how many of those skipped the ladder.

Questions buyers ask

Before you enquire, the answers you will want.

Which service standards matter most to customers?

Two, mostly. The first is a quick acknowledgement that a real person has the request, with a name and a time attached to it. The second is being told the truth when a fix will take longer, before the customer has to ask. Speed of final resolution matters less than most teams assume. Customers accept that some problems take days; what they do not accept is silence, or a promise that quietly passes without anyone mentioning it.

How long does the engagement take?

It depends on how many channels you serve, how many people handle requests and how complex the issues are. Reading the baseline and agreeing standards moves quickly. Designing the flow, writing the templates and configuring your tools takes longer, because your team builds them with us rather than receiving them. Running it in and installing the review takes longer still. We agree the sequence and the checkpoints in writing before starting, and we do not commit to dates we cannot control.

What inputs are required from our side?

Access to wherever requests currently live: mailboxes, WhatsApp threads, call registers, complaint books or your helpdesk tool. Then people's time, which matters more: a few hours with those who handle requests, working sessions to agree priorities and templates, and weekly time during the run-in. Most importantly, a named owner for the process who will attend the review afterwards. Without that person the design holds for a month and then returns to how things were.

How is success measured?

Against the baseline we count before anything changes. In the first month we read response time, resolution time, backlog and ageing, plus how many requests are being logged at all rather than handled off the record. Over two to three quarters we look at satisfaction, repeat contact, escalations reaching you personally, and renewal and churn among accounts with service issues. The early numbers tell you the process is being used; the later ones tell you it was worth having.

What is excluded from the scope?

We do not staff or run your support desk for you, and we do not write a knowledge base or customer help centre here. Selecting and implementing a new helpdesk platform or contact centre is separate work, as are complaint policy and formal service recovery programmes. We also do not fix the product or delivery faults your requests reveal, though we will show you which of them are costing the most attention.

We already use a helpdesk tool. Do we still need this?

Often yes, because a tool is a container and not a process. Most businesses we meet have queues nobody owns, statuses used differently by each person, and priorities set by tone of voice. We usually configure the tool you already have rather than replace it: queues, statuses, tags, assignment and reports built around the flow we agree. The tool then starts producing numbers you can act on instead of a growing list.

Our customers use WhatsApp for everything. Can that be part of the process?

Yes, and pretending otherwise is why many support processes fail here. We design WhatsApp as a proper intake channel: a business number the company owns rather than a staff member's personal phone, a rule for how a message becomes a logged request, and standard replies for the common ones. The important shift is that the conversation leaves one person's handset and becomes something the business can see and count.

Will this add paperwork for a team that is already stretched?

It adds logging and removes rework, and for most teams that trade is worth making. Templates cut the time spent composing replies, routing rules end the daily argument about who takes what, and a visible queue stops the same request being worked twice by two people. We keep the record deliberately short: enough to route, resolve and count, and nothing that exists only to fill a report nobody reads.

4 more questions

How do we set response targets when we cannot control every fix?

By separating what you control from what you do not. First response, ownership, updates and the escalation step are all within your control, so they get firm targets. Resolution gets a target by priority where the work is yours, and an update rhythm where it depends on a supplier, a spare part or a third party. Customers accept that difference when it is stated in advance rather than discovered halfway through.

Can a team of two or three people justify this?

Sometimes, and sometimes not. If those two people are handling a rising number of requests across three channels, or if one of them is the owner, the process usually pays for itself in returned time. If your volume is genuinely low and steady, a shared inbox with a few simple rules may be all you need, and we will say so. The test is whether requests are being lost or repeated, not the size of the team.

How is this different from writing a customer service policy?

A policy states intent: how you want customers treated and what your business stands for. A process states mechanics: where a request lands, who owns it, what makes it urgent, when it escalates and what closes it. A policy without a process becomes a poster on the wall. We work at the level of mechanics, and where your service strategy is missing we will tell you which of the two to settle first.

What happens if the process is not followed after you leave?

That is the usual failure, so we build against it. The process lives inside the tool your team already opens, the named owner runs a weekly review with the report pack we hand over, and quality sampling makes drift visible within a fortnight. We also remove any rule the team works around during the run-in, because a step people avoid is nearly always a step that was designed wrongly in the first place.

Talk to us

Tell us how a customer request reaches you today.

Request a Customer Growth Assessment and we will look at how support actually runs in your business. It is a working conversation, not a pitch, and we will say plainly if your volume does not yet justify a designed process.

No obligation and no sales script
A reply from someone who does the work
Your details are never sold or shared

Get a free audit of how you sell, and a scored report of where the work is.

Book a free audit