Skip to main content
GullySystem
Business Services · Technical Support Centre Management Software

Faults, tiers, clocks and fixes in one system.

Each ticket carries its product, serial, firmware build, diagnostic steps and owner from first contact to the closing note, with entitlement and severity clocks beside them. Tier hand-offs, remote session notes, vendor escalations and knowledge articles sit in the same record, so nothing lives in a personal inbox. Agents see what was tried. Leads see the queue. Clients see only their own tickets.

  • Products and plans entered from your contracts
  • Open tickets, customer lists and serial numbers migrated
  • Queue changes made by GullySystem staff on request

In-house and outsourced technical support centres handle fault intake, entitlement checks, tiered hand-offs, vendor escalations and fix articles in Technical Support Centre Management Software, which GullySystem configures. Each ticket holds the product and serial, the severity clock, every step tried and the vendor reference, while boards and reports all read one ticket store.

Where it breaks today

What goes wrong before the software.

Diagnostic steps are lost at hand-off

An agent runs the checks. The second-line engineer gets a one-line summary, so the customer repeats every single step again, from the power cycle to the firmware version. Trust drops.

Severity follows the caller’s tone

Everything is urgent. The queue follows whoever shouts loudest, so the engineer who should be fixing a dead core switch is stuck behind a forgotten password.

Warranty is checked after the work

The fault is solved after two hours of remote work, and only then does the agent find that the serial sits outside cover. The hours are lost.

Vendor tickets live in personal inboxes

The fault goes to the vendor. Its reply lands in one engineer’s inbox, and when the customer rings back, nobody can say what the vendor answered or when the next update was promised.

Recurring faults are solved again

A senior engineer traces an intermittent link drop to one firmware build and mentions it to two colleagues over lunch. A month later the same fault returns on another site, and the diagnosis starts from zero again, because nothing about the link drop was written down.

Contract hours are counted at month end

Clients buy support in hours, tickets or named users. Usage is added up from exports at month end, so a client learns that its hours ran out only from the invoice. That is late.

How it runs

How the work flows through it, step by step.

  1. 1

    Contact

    A caller phones, chats, emails or fills in a web form, and the contact is matched to a customer, a site and a product serial. Earlier tickets for that serial appear first.

  2. 2

    Entitlement and severity

    The agent sees the support plan, warranty date and covered hours, and severity is set from the product and the contract rules. Both clocks start together.

  3. 3

    First-line diagnosis

    The agent runs the scripted checks. The fault is either solved on the call or passed on with every step already tried, so nothing is asked twice.

  4. 4

    Second and third line

    An engineer takes the ticket, opens a remote session, reads the logs and reproduces the fault on a test unit. A code change or a part request goes out as an escalation with its own reference number, which the customer can quote.

  5. 5

    Resolution

    The fix is confirmed with the customer. A closing note records the cause, and the ticket closes with time spent set against the contract, whether it is counted in hours or in tickets.

  6. 6

    Learning

    A repeat fault becomes a draft article. Once a senior engineer has reviewed it, agents on that product line can search it from the very next contact.

Modules

What is inside.

Every module can be switched on, left out or changed to match how your team already works.

Contact intake and customer match

Phone, chat, email and form contacts are logged against the customer, site and product serial, with earlier tickets for that serial shown on arrival.

Entitlement and warranty check

Each customer’s support plan, serials, warranty dates and hours are held, so an expired contract is flagged before work starts, before an engineer spends a morning on the fault.

Severity and response clocks

Severity is set by product and contract. Clocks start at once, customer waits pause them, and the shift lead is warned before any clock breaches, naming the ticket and the agent holding it.

Tiered ticket hand-offs

A ticket passes from first line to second and third with the checks run, the logs attached and the session notes travelling beside it. No step is repeated.

Remote session log

The session reference, the machine, the engineer and the action taken are recorded against the ticket, leaving a trail that outlives the remote session. A later engineer sees exactly what was changed.

Vendor and field escalations

A fault goes to a manufacturer, a software vendor or a field engineer with a reference, and each reply and promised date is recorded on the same ticket. When the customer rings back, the agent reads the answer straight off the ticket history.

Fix notes and knowledge articles

A closed fault becomes a draft article with symptom, cause and steps, and a senior engineer reviews it before agents can find it by product. A half-checked workaround never reaches the floor.

Shift roster and queue board

Agents are planned by shift and product skill. The live queue shows waiting time and breaches by line, product and client, so the lead sees a pile-up forming before the phones fill.

Callbacks and customer surveys

A callback is scheduled for each promised update. A short survey goes out on closure, and replies are tied to the ticket and to the agent who handled it, which makes coaching specific.

Contract usage and service reports

Hours, tickets and named users are counted against each plan as they are used, and clients then receive a monthly summary of faults, breaches and repeat causes. No export or merge is needed first.

Solutions inside

The business modules it is built from.

Each one is also available on its own, or inside a system built for you.

  • Customer Support

    Every phone, chat, email and form contact is matched to a customer and product serial, with earlier tickets for that serial in front of the agent.

  • Asset AMC Tracking

    Serials are linked to support plans and warranty dates, so cover status shows before the agent spends hours on a fault.

  • Helpdesk Automation

    Severity is set from product and contract rules, clocks start and pause by ticket state, and the shift lead is warned ahead of a breach.

  • Ticket Management

    A fault moves between first, second and third line with checks, logs and session notes attached, so the customer repeats nothing.

  • Vendor Management

    Faults sent to manufacturers or software suppliers carry a vendor reference and each reply, and open escalations are listed by age.

  • Knowledge Base

    A closed repeat fault becomes a draft article with symptom and cause, reviewed by a senior engineer and searchable by product line.

  • WhatsApp, SMS and Email Notifications

    Promised callbacks are scheduled with a reminder to the agent, and a short survey goes out on closure, tied to the ticket.

  • Service Reports and Proof of Visit

    Hours, tickets and named users are counted against each plan, and a monthly summary of faults, breaches and repeat causes goes to the client.

Services

How we would put it in.

Setup, data migration, integrations and anything built on top.

Who uses it

One system, each person sees their part.

For first-line agents

Match the caller and check cover. Follow the scripted checks and hand off with every step noted, and watch your own queue and open callbacks while the phone keeps ringing in the background.

For second and third-line engineers

Take escalated tickets with logs attached. Record session actions, send faults to vendors, and when you find a cause, draft the article before the next shift starts, while the details are fresh.

For shift leads

Watch clocks, queues and the roster. Move tickets between agents before a response time is missed, so overtime rests on the board and not on a guess about who is free.

For account and contract managers

Read usage against each plan, breaches by client and repeat faults, and prepare the monthly service review from recorded tickets instead of exports from three different tools.

For knowledge owners

Review draft articles and retire outdated ones. See which faults still have no article, and read the search terms that returned nothing, which show where the next article is needed.

Reports

The numbers the owner asks for.

  • Tickets by product, severity and client
  • First-response and fix time against each plan’s clock
  • Tickets handed between tiers, with repeat hand-offs
  • Vendor escalations open, with age and last reply
  • Repeat faults by product and serial range
  • Contract hours and tickets used against each support plan
  • Articles published, searched and linked to closed tickets
Good fit

Who this is built for.

  • Outsourced technical support centres serving several manufacturers or software vendors from one floor, each with its own scripts, clocks and client reports
  • In-house support desks for one product line
  • Managed service teams running first and second line for the estates of many small clients, with engineers rostered across morning and evening shifts
  • Warranty support teams that triage faults before a repair or replacement is authorised, checking serial, purchase date and cover status first of all
  • Telecom and broadband support teams with tiered engineers, escalations to equipment vendors, field visits and severity targets written into carrier contracts
Honest answer

When it is not the right choice.

  • A lone agent answering a shared inbox can manage.
  • Centres whose work is mostly sales calls and general customer questions, with few serials and no vendor escalations, will find Customer Support Centre Management Software closer.
Made to fit

Adapted to your business before it goes live.

You are not handed a login and left to it. The product is set up around your records, your people and the tools you already use.

Products and diagnostic scripts

Product lines, serial formats and the scripted checks for each are entered as your agents use them today, so the first week on the new screens feels familiar. The scripts stay in the agents’ own words.

Severity and clock rules

Severity levels, response and fix targets and the conditions that pause a clock follow each client’s service agreement, so two clients on one product can carry different clocks.

Support plans

Each plan’s type, covered hours, named users and warranty period are entered as your signed contracts word them, and out-of-cover serials can be routed for approval before work begins.

Queues and tiers

Lines and shifts follow your team structure. A centre with two lines and a centre with four can both be set up without bending the screens, and escalation paths follow your own names for each line.

Existing tickets and serials

Open tickets, customer lists and serial records come across from your current tool or spreadsheet before go-live, and shift leads check a sample against the old queue.

Hosted by GullySystem

GullySystem hosts the system. Agents, engineers and account managers read one record, and data handling terms in client contracts are reviewed with you at set-up, settled well before any client data is loaded.

Works alongside

  • Email
  • Web chat
  • SMS
  • WhatsApp
  • Telephony call log
  • Remote-access session links
  • Accounting export
Common questions

Questions owners ask before a demo.

Does it replace our telephone system?

No. Calls stay on your existing platform. The ticket is created in this system, and a call log or recording link can be attached when your phone provider supplies it.

Can clocks pause while we wait?

Yes. A ticket can be set to waiting on customer or waiting on vendor, and the clock stops for those states. That choice is made plan by plan.

How does the entitlement check work?

Each serial links to a plan. When an agent opens a ticket the cover status shows first, and an out-of-cover serial can be routed for approval.

Can we support several client brands from one team?

Yes. Each brand has its own products, clocks, scripts and articles, agents see the brands they are skilled in, and a client reads only its own tickets and reports.

How are vendor escalations tracked?

An escalation is a record on the ticket holding the vendor’s reference, the date sent and each reply, and open ones are listed by age so none waits unnoticed.

Can knowledge articles be limited to certain agents?

Yes. Articles are tied to a product and a client, so only agents on that line can search them, and a reviewer approves each one. Nothing goes live unreviewed.

Is remote access software included?

No. You keep your own remote tool. The engineer notes the session reference and action on the ticket, and a session link can be added where the tool offers one.

Can tickets from our current tool be moved over?

Yes. Open tickets, customers and serial records are imported from a file, and the shift leads check a sample of tickets before agents switch over.

What decides the cost?

Agent seats, client accounts, product lines and the number of contract rules decide the quote. You see a working demo first, and the proposal follows in writing.

Wondering what it would cost? Share your requirements and an engineer will come back with a scope.

Book a demo

See Technical Support Centre Management Software with your own data.

Tell us how you run things today. We’ll show you the parts that matter to you and say plainly what would need changing.

  • No obligation
  • A reply within one business day
  • Your details stay private

Start with your requirements

Seven short steps that tell us what you need. An engineer reads them before getting in touch.

Share your requirements