Saved Successfully.

webcore serviceDesk

NDC Partner Support & Ticket Management

Partner support that currently lives in a shared mailbox. serviceDesk gives it queues, owners, SLA targets and a history, so an integration problem raised on Tuesday is still findable, still assigned, and still answerable in three months' time.

Book a Demo

A shared mailbox is not a support channel

Built for the queue behind an NDC programme

Every airline running an NDC programme ends up answering the same kinds of question from the same partners: why did this offer expire, why is this order state wrong, which schema version am I supposed to be on. In a mailbox those threads have no owner, no due time and no history you can search. serviceDesk gives them all three, without asking your partners to learn a new product.

  • Ticket queues
  • SLA targets
  • Rules & automation
  • Partner portal
  • Email ingestion
  • Reply templates
  • Custom fields
  • Known issues
  • Multi-tenant
webcore servicedesk NDC Partner Support & Ticket Management

Who it is for

The team that answers when a partner is blocked

serviceDesk is company-scoped throughout, so an airline supporting many travel sellers keeps each of them properly separated — a partner only ever sees their own tickets, and an agent only sees the queues they have been given access to.

  • Airline NDC support teams fielding partner integration issues
  • Distribution teams who need an audit trail per partner
  • Integration engineers triaging schema and order-state problems
  • Service managers reporting against an SLA they committed to
  • Travel sellers who want to know where their ticket got to

Two sides of the same ticket

The desk your team works, the portal your partner sees

The same ticket carries the partner's original message, everything your team said internally, the SLA clock, the rule that routed it and the reply that closed it. Nothing is re-keyed between the two sides.

Queues you can actually work

Filter down to what is yours

Tickets group into queues by team or subject, and filter by status, priority, company, assignee or age, so an agent starts the day looking at their own overdue work rather than at everything.

One thread per ticket

Partner replies and internal notes

The partner conversation and your team's internal notes live on the same ticket, kept visually distinct, so context does not have to be reconstructed from forwarded email.

Reply templates

Answer the common one quickly

Canned responses for the questions that come round every week, so the tenth partner asking about a schema version gets the same accurate answer as the first.

Custom fields

Capture what NDC needs

Add the fields your triage actually turns on — order id, message type, environment, schema version, and filter and report on them like any other field.

Raise and track

Without emailing anyone

Partners log a ticket against the right category, attach evidence, and watch its status change, instead of sending a message into a mailbox and waiting to see whether it landed.

Their whole history

Scoped to their company

A partner sees every ticket their organisation has raised and nothing belonging to anyone else. The separation is enforced by company scoping, not by a filter someone remembered to set.

Known issues

Answer it before it is asked

Publish the problems you already know about. The partner who was about to raise the eleventh ticket on a known defect reads the entry instead.

On your own domain

Part of the portal, not a bolt-on

The support area sits inside the developer portal your partners already use, sharing its branding and its sign-in rather than being a separate product with a separate password.

SLA targets

Response and resolution

Response and resolution targets by priority, with the clock visible on the ticket. Breach is something you can see coming rather than something you discover in a review.

Per-company overrides

Because the contracts differ

A tier-one partner on a tighter commitment gets their own targets, overriding the defaults, without you having to run a second desk for them.

Rules engine

Routing and escalation

Conditions on a ticket drive what happens to it: route to a queue, set a priority, assign an owner, escalate on age. The rules are configuration, not a change request.

Automation

The housekeeping nobody does

Scheduled jobs handle chasing, auto-closing stale tickets and the routine tidying that otherwise depends on somebody remembering to do it.

Mailboxes with OAuth2

Email in, ticket out

Connect the support mailbox your partners already write to over modern OAuth2 authentication. Incoming mail becomes a ticket, replies thread back onto it, and the mailbox stops being the system of record.

Mail logs

Prove what was sent

Every message in and out is logged, so “we never received that” is a question with an answer rather than the start of an argument.

Access and notification groups

Who sees it, who hears about it

Queue access groups decide which agents can work which queues; notification groups decide who gets told. The two are set separately, because they are genuinely different questions.

Code sets

Your statuses, your categories

Statuses, priorities, categories and resolution codes are all editable, including custom types, so the desk reflects how your team actually triages rather than a vendor's default list.

Why NDC-aware matters

A generic helpdesk does not know what an order state is

Most support tools treat every ticket as an undifferentiated request. The questions an NDC programme actually receives are about offers, orders, schema versions and environments, and triaging them well means capturing those on the ticket and routing on them.

Because serviceDesk sits alongside the rest of the toolchain, a support conversation can reference the sandbox run or the certification evidence it relates to, instead of asking the partner to describe it again from memory.

That is the difference between a ticket system your NDC team tolerates and one they actually work from.

Works with

Part of the Webcore product family

serviceDesk is one of six Webcore products. These are the ones it connects to directly.

webcore cmx

The developer portal your partners already read. serviceDesk sits inside it, so raising a ticket happens where the documentation is.

Content & Portals Platform

webcore latitude

A partner reporting a problem can point at the sandbox run that produced it, so triage starts from captured messages rather than a description.

NDC Sandbox

webcore nucleus

A ticket that turns out to be a defect becomes tracked delivery work, instead of staying open on the desk waiting for a fix nobody has scheduled.

Project & Delivery Management

See serviceDesk on your own partner queue

We will set it up against the support mailbox you run today and show you what the first week of tickets would have looked like.
Trusted by Virgin Atlantic, LATAM Airlines and TAP Air Portugal.