Some of the best work we do is boring on purpose. A reservation system already knows who is checking in. The Wi-Fi still wants a voucher typed by hand at the desk. ECOMX builds the piece in the middle: read the record, apply the rule, create the credential, print it.
That is the hotel voucher job we have already described in the news section. Incoming JSON, business rules, guest credentials, print-ready output. Reception touches the exceptions, not every arrival. We are not going to invent a percentage saving on top of that. The queue at the desk got shorter. That was the point.
That is the hotel voucher job we have already described in the news section.
RADIUS is how a wireless network asks 'is this user allowed on and onto which network?' It is the right tool when vouchers, staff logins or room credentials have to be issued and expire. We tie it to the Wi-Fi, usually UniFi on the sites we run, and to whatever system already holds the guest or the staff record.
It sits on the Linux or Windows box we already manage, and it is included in the backup conversation, not left as a side project.
We do not take on open-ended app rebuilds disguised as 'a quick API'. If the job is a clear workflow with a system we can test against, we will quote it. If it needs a product team, we will say that before the invoice starts. JSON in, a printed voucher or a provisioned account out, is the shape we are good at.
If it can export or send a record we can read, usually yes. We need a sample and a test system. We do not experiment on live check-in.
No. The same pattern fits a school, a clinic or an office that issues temporary Wi-Fi. Hotels are where we have done it at volume.
If we manage the site, it is part of that. If you have your own team, we hand over the runbook. A script with no owner becomes the next outage.
Only what the workflow needs, for as long as the voucher or the account needs to exist. The retention should match what the hotel already tells guests. Ask us to write that down in the scope.