How to Write a Vendor Ticket That Actually Gets Fixed

Hotel technology runs on other people's systems. The PMS, the payment gateway, the channel manager, the door locks, the booking engine - at some point every one of them will do something you cannot fix yourself, and your only lever is a support ticket.

Most hotels are bad at this, and it costs them weeks. Not because the vendors are bad, but because the average ticket makes the vendor do the work of figuring out what the ticket is about.

The difference between a symptom and a task

Compare two versions of the same problem.

Version one: Digital check-in is not working. Guests cannot complete it. Please advise urgently.

Version two: Attaching a signed PDF to a reservation fails at property 4021 with the error "Directory that configured in optima not exists on the server. HotelID = 4021". The identical call succeeds at three other properties on the same platform. Please create the attachment directory configured for HotelID 4021, or correct the path. We will re-test on reservation 88214/1 and confirm.

The first is a symptom. Somebody has to investigate before anyone can act, and investigation gets scheduled.

The second is a task. The person who opens it can do it, and then it is done. It also happens to contain everything a second-line engineer would have asked for, which means it does not bounce back with a request for more information.

The gap between these two tickets is often several days of a go-live slipping.

The six things worth including

1. The exact error string. Copy it, do not paraphrase it. Error codes are searchable in the vendor's own systems, and the difference between directory not found and the precise text can be the difference between a known issue and a fresh investigation.

2. The identifier the vendor uses. Your hotel has a name to you and a number to them. Property IDs, terminal numbers, account codes, merchant IDs - lead with whichever one their system is organised around. Support teams cannot look you up by the name on your front door.

3. A record they can reproduce. A specific reservation, a specific transaction, a specific booking. It fails every time is less actionable than it fails on this one, try it.

4. Evidence it works elsewhere. This is the strongest single element you can include and the one most often missing. If the same operation succeeds at another property on the same platform, say so. It removes an entire branch of investigation and quietly establishes where the problem is not.

5. The explicit ask. End with the change you want made, phrased as an action. Create this directory. Correct this path. Enable this parameter on this terminal. A ticket that ends in a description ends in a queue; a ticket that ends in a request ends in a change.

6. What you will do next. Once this is done we will re-test and confirm. This gives the vendor a definition of done and signals that the loop closes without them chasing you.

Ask what you actually need to know

There is a second kind of vendor conversation, and it deserves a different technique: the one where you need information rather than a fix.

Documentation is written per feature, at different times, by different people. It is routinely inconsistent. A parameter table might list four possible values for one field while an adjacent field documents five - and the missing one may be supported, undocumented, or genuinely unavailable. You cannot tell from the page.

So ask a narrow, checkable question. Not how do I configure this, but:

The manual lists these four values for this field. Another field on the same form documents a fifth option. Is that fifth option supported here, or should we use the documented one?

Specific questions get specific answers. And they often produce something better - the person answering knows things the manual does not say. In one exchange about removing a field from a payment form, the genuinely valuable answer was unprompted: a completely different field turned out to be the one that gated 3D Secure, and setting it wrong would have silently changed how every transaction was processed. That was not in the documentation and would not have surfaced in testing, because nothing visibly breaks.

Ask what depends on the thing you are changing, not just how to change it.

Escalating without burning the relationship

Tickets go quiet. The instinct is to open a new one, which is exactly wrong - you lose the history and rejoin the back of the queue.

Escalate by widening the existing thread instead. Add the implementation team, add the account manager, keep the original evidence visible, keep the property contact copied. A one-word bump on a thread that already contains the full diagnosis is more effective than a fresh, well-written ticket, because the reader can see the age of the problem at a glance.

Keep the tone flat throughout. The person reading did not cause the problem and is more likely to prioritise a clear request from someone who has been easy to work with. Frustration is legitimate and is best expressed as specifics - this has been open eleven days and is blocking a go-live - rather than as adjectives.

Why this is an operations skill, not an IT one

The reflex is to treat vendor escalation as technical work belonging to whoever is most technical. In practice, it moves at the speed of whoever is willing to keep the thread alive, keep the evidence in front of people, and keep the property's contact copied so the urgency stays visible.

That is an operations skill. It is worth naming an owner for it before the next integration, because the moment you need it, you will need it quickly.