The job

Support here is debugging with a customer on the other end of it. A call was refused and the model reported nothing useful; your job is to find which of the seven admission checks turned it down — key, install, entitlement, version, allowance, rate, capability — and answer with the thing that fixes it. Some of those answers are a sentence. Some are a bug you have to write up so that the next hundred people never open the ticket at all, and that second kind is what this role is measured on.

Your first six months

Three things that are true by then

Not a list of duties. These are the outcomes we would judge the hire on, and they are the ones we would expect you to hold us to if they turn out to be impossible for reasons nobody mentioned in an interview.

1

Your window has its own clock

You want a European or Atlantic working day rather than a rotation onto unsocial hours. This is one window, not a follow-the-sun rota.

2

Ten tickets closed by editing the docs

Rather than by answering the question, which only closes it once.

3

The three questions your window asks

Written up, in the docs, with your name on the change.

The work

What you would actually work on

Installs

Across the clients buyers actually use, and the fact that the same server behaves differently in each of them.

Reading the call log

Which tool, which arguments, what came back and how long it took. It is in front of you before you reply.

Charges

We are the merchant of record, so an unexpected line on an invoice is ours to explain whoever’s server produced it.

Handing over what is not ours

A server that is simply wrong belongs to its publisher, and handing it over well — with the log attached — is a skill.

Writing the fix down

So the ticket does not come back next month wearing a different name.

Fit

What we are looking for, and what we are not

The right-hand column is not a formality. Each line is something a candidate has apologised for in an interview for this role, and none of it has ever decided one.

We are looking for

You have supported a technical product and can hold a terminal, a log and a customer at the same time.
You read a stack trace without flinching.
You write like a person rather than like a macro.
You want a European or Atlantic working day rather than a rotation onto unsocial hours. This is one window, not a follow-the-sun rota.

We are not asking for

Experience with any particular helpdesk product.
Night shifts. Your window is daytime where you are, and that is the point of the role.
Sales. Nobody here is measured on an upsell, and buyers pay nothing to use mcprush.

Interviews

The loop for this role

Four conversations, 3 h 15 m of them in total, scheduled inside your working hours rather than ours. Two to three weeks end to end if diaries cooperate. What we do not do is on the openings page and applies to every role here.

1

Intro call 30 min

With the person who runs support, scheduled in your morning rather than ours.

2

Ticket session 90 min, paid

Five real tickets, scrubbed. Your replies, plus what you would escalate and to whom.

3

The team 45 min

Two support engineers from the other two windows, on what they will and will not hand you.

4

Close 30 min

The offer, the rota, and your questions.

Applying

How to apply

Four fields. No cover letter, no portal account, no form that asks you to retype a CV it has already parsed. If the last field is the only one you fill in properly, that is the one we read first.

Apply

Your name Where to reply

One link optional The thing you have built that is closest to this

What happens next

This lands in hiring/support-apac and is read by the person who runs support — not by a screen, not by a keyword filter and not by anyone outside the team you would join. A reply either way inside 5 working days, and a no that says which part it was.