The careers question nobody configured the widget for

A recruitment message sitting in a support inbox is a message nobody owns. It will be triaged behind order problems, answered late or not at all, and the applicant will read the silence as an answer about the organisation rather than about the inbox.

So the assistant's job here is routing before it is anything else: name the careers route, give the address that actually receives these, and if the person asks for a human, collect the enquiry and send it where you nominate. One correctly routed message resolves this. A polite reply that leaves it in the customer queue does not.

Whether somebody has applied, whether they were shortlisted, whether a role went to an internal candidate, why they never heard back. The assistant has no access to any of it, and improvising is worse here than in most intents, because recruitment decisions carry legal exposure in many places and an offhand sentence becomes evidence about how a candidate was treated.

Even sympathetic phrasing is dangerous. Speculating that they were probably unsuccessful, or that the role likely went to somebody with more experience, states a reason for a decision that nobody at your business made in that conversation. The safe reply is the published timescale plus the route to whoever owns the process.

Where roles are listed, whether you take speculative applications, whether you offer volunteering, what a work experience placement involves, whether previous applicants can apply again. All of this is stable, identical for everybody, and asked far more often than any individual case.

Answering it well is also cheap goodwill from a group that includes future customers. Somebody who gets a clear, quick answer about volunteering thinks better of the organisation whether or not they end up applying.

People will try to send a curriculum vitae through the chat, or type a paragraph of employment history and a date of birth into it. The widget takes a name, an email and a message and nothing else, and a chat transcript is the wrong place for any of that.

Write the refusal so it triggers on the attempt and points immediately at the real route. Treat it as a data handling control rather than as copy, because unlike most refusals in support this one is preventing personal information from ending up somewhere it was never meant to be.

A chase, a request for feedback, a question about why somebody was rejected, an adjustment needed for an interview. All of these belong with whoever runs the process, and several carry obligations a support widget has no business anywhere near.

Route them with the person's name and what they are asking, and be explicit that the reply comes from the recruitment side rather than from support, so nobody is watching the wrong inbox.

A complaint about a manager, a question about a reference, a pay query, somebody who has left asking for a document. These are employment matters and they can be serious ones. They should reach a named person quickly and should never receive an answer composed from published material, which in these cases will be marketing copy about what a good employer you are.

The assistant is asked whether you are hiring. It finds a careers page untouched since the last recruitment round, or finds nothing at all, and produces a confident negative. Somebody who would have been a good candidate stops looking, and often tells the people they know.

The mirror version is as bad and more common: it describes a role that closed months ago, and somebody spends a weekend on an application into a dead address. Neither of these is a support failure in any sense the support team would recognise, which is exactly why nobody catches it. Keep one current careers route in the indexed material, delete the stale pages rather than leaving the assistant to choose between them, and make sure the nominated address is one the recruitment side reads.