When a guest gets stuck filling in the check-in, the phone call comes to you. Not to the form, not to us. To you, at eleven at night, while that person stands at the door with a suitcase.
These past weeks we went after those snags one by one. None of them was a new feature. Each one was a place where somebody stopped and could not tell why.
The link now arrives with the dates in it
Let’s start where the guest starts, because that is where most of this is won.
When you copy the check-in link from a reservation, the link carries three things from it: the check-in date, the check-out date and the number of guests. The guest opens the link and they are already there.
Both dates arrive locked, with a line underneath saying where they came from. The guest cannot change them, so the guest cannot get them wrong. The guest count is different: it arrives filled in, but stays editable, so if four people turn up instead of three, they fix it themselves.
One thing worth knowing: this happens when you copy the link from the reservation. You will find it in the reservation row’s menu, in the calendar’s detail panel, and on the pending-task card on Home. A lodging’s general link is still the general link. It is for everybody, which is exactly why it carries nobody’s dates.
The payment question was broken
This is the worst one, so here it is plainly.
The form asks whether the guest paid through the booking platform. If they answer no, the field for how they did pay is supposed to open below. It did not. The answer froze at its starting value and the gap stayed empty.
The guest saw a question they had answered and nothing else. There was no way forward. It is fixed: answering “no” opens the payment method, and choosing card opens the expiry date under it.
While we are here, let’s be clear about what that field is, because it confuses people:
Regi never charges the guest. Not here, not on any screen. What the guest states is how they paid, because that goes on the traveller report. The yes-or-no answer does not even leave their browser. All it does is decide which options they are shown.
Card expiry, the way it is printed
This used to be a month picker and a year picker. You had a date in front of you, raised in the plastic, and you had to go hunting for it in a dropdown.
Now it is two boxes: MM and YY. Four digits and you are done.
- Browser autofill works. If the card is saved, it fills itself.
- Pasting works however it is written:
05/28,0528and05/2028all end up the same. - An expiry date already in the past is refused. If the card had expired, it could not have paid, and that should not reach the report.
The calendar’s years stopped at 2007
This one was hard to spot and easy to suffer.
The calendar showed a sliding window of twenty years around wherever you were. On a date of birth that looked like a list that stopped at 2007. Pick 2007 and the window slid down another decade, so it felt like you would never arrive.
Now, when a field knows the two years it has to move between, it lists every one of them. On a date of birth that is 121 years, all at once, in the list.
Two more things from the same fix:
- Stay dates are accepted up to three years back and three years forward from today. It used to be one. That is enough to record an old stay without fighting the calendar.
- The guest counter is wider. The plus and minus buttons can be hit with a thumb.
A distant draft is no longer born expired
If a guest does not finish in one sitting, the check-in stays as a draft and can be picked up later. That already worked.
What did not work: if the stay was more than about 17 days away, the draft said “expired” the instant it opened. It was not expired. The internal clock could not count that far ahead and fired straight away.
Now the draft stays open and closes when it genuinely should. And what it genuinely should is this: a draft lives until seven days past the legal reporting deadline for its check-in, with a floor of 24 hours from when it was created. A draft for a stay two months out lives those two months.
For anyone using a screen reader
Regi’s dates are not one box, they are three pieces: day, month and year. A screen reader read out the piece without saying which field it belonged to.
Now the group carries the field’s own label. You hear “Check-in date”, then “Day”, in that order. Same on the card expiry.
What this does not do
None of this changes the substance, so let’s say it out loud:
- It does not change what is sent to SES.Hospedajes, not the data and not the deadline. It is the same traveller report, filled in with fewer trips. What the form asks and why is covered in the online check-in post.
- Regi does not charge the guest. The card expiry is a declared detail for the report, not a payment.
- The draft link is one link, and it is shared. There is no personal link per guest. Anyone holding it can work on the draft. Whoever started it picks it up again in the same browser, but their part does not follow them to another phone.
- The stay-date range is a calendar bound, not a rule. The server only warns about check-ins that have already passed.
- The link with dates comes from the reservation. Copy it from the lodging and it goes out without dates, as before.