When KBS is unavailable at check-in: keeping records the law requires without delaying the guest

We found no published outage procedure for KBS (Kimlik Bildirme Sistemi, the guest identity notification system). The duty does not pause: Article 2 of Law No. 1774 requires identity and arrival-departure records, kept day by day and ready for inspection at any time. Record each stay, send notifications when the connection returns, and ask the competent unit about your case.

It is 22:00, a group of forty is standing in the lobby, and the KBS screen returns an error. Nothing in the law changes at that moment, and nothing published tells you what to do either. This article does not invent a procedure. It separates what the law requires from what the system transmits, gives you a diagnostic that tells you which layer failed, a field list that keeps the fallback record usable, and a catch-up routine that closes the day before the night audit does. For the background on the system itself, see KBS explained: guest identity notification for hotels in Türkiye.

What does the law require when KBS is unavailable?#

The law sets a record duty, not an outage procedure. Article 2 of Law No. 1774 requires identity and arrival-departure records kept day by day and ready for inspection at any time, and no published text suspends that because a connection failed.

In plain words, the duty is this: the responsible operators of hotels and similar lodging places keep the identity and arrival-departure records of everyone, in the prescribed form, day by day, and hold them ready for inspection by the general law-enforcement bodies at any time (Cumhurbaşkanlığı Mevzuat Bilgi Sistemi, Kimlik Bildirme Kanunu No. 1774 (opens in a new tab), 11 November 2026).

Now read what the article does not contain. There is no description of an outage, no fallback document, no grace period, no deadline counted in hours. No published text sets out a KBS outage procedure, so where the rules stop, confirm your own case with the competent unit.

Separate the two objects in your head. The record is the entry you keep about the guest and the stay. The notification is the transmission of that entry to KBS. An outage blocks the second and leaves the first entirely in your hands.

Do not present a paper register to a guest or an inspector as an accepted replacement. It is your internal record of the day, and whether it satisfies the unit that inspects you is a question for that unit, not for a blog post. Do not photocopy identity documents as a workaround either: copying is a separate personal-data question with its own rules, and it does not create a notification.

Use one word for one thing across the whole shift: kayıt for the record you keep, bildirim for the notification you send. Mixed vocabulary is how a pending row gets lost.

Where is the fault: our network, our software, or KBS?#

Work outward from the front desk, because many "KBS is down" calls turn out to be a local network or session problem, and knowing which layer failed decides who you call and what you write down.

Layer one is the device. Does the terminal load any page at all, and does the KBS screen open but fail on submit, or not open at all? The two symptoms point to different owners. Layer two is the hotel network: wired against Wi-Fi, a captive portal on a guest network, a firewall or content filter changed that morning. Ask your software provider whether the connection depends on a fixed public address, rather than assuming it.

Layer three is the software. The guest is saved in the property system but the notification sits in a queue that is not draining. That is a credential, endpoint or provider-side problem, not a KBS problem. Layer four is KBS itself: if several hotels report the same failure at the same minute, it is upstream. You cannot fix it, and the only useful work left is the record.

Note the time and the exact symptom at every check, in one line each. That log is what you read to the software provider and to the unit, and it is what turns a vague complaint into a ticket.

Know your reporting route before the outage. Hotel software can notify KBS through a web service module, so a facility that enters data only in its own program reports at once without extra work (Jandarma Genel Komutanlığı, KBS Tesis 2 Uygulama Kılavuzu (opens in a new tab), 11 November 2026). If your hotel types into the web screen by hand, the outage costs you every arrival twice. The mechanics are covered in how KBS notification works through the web screen or your hotel software.

After each step, write the time and the result.

What do we write down during the outage?#

Write the same fields the notification needs, at the moment of check-in, so that the catch-up is a data entry job and not an investigation.

Take the data from the identity document in front of you, not from the reservation record, and take all of it at once. A missing document number discovered at 09:00 the next day means a phone call to a guest who has already gone out. Record companions and children the same way as the main guest: the law's wording covers everyone staying, and specific official rules on children and companions are not published in the material this article relies on, so record fully and ask the unit about your case.

Write the arrival time and the room number as they happen. The duty covers arrival and departure, and a record that shows a guest in a room with no time against it is the first thing an inspector will question. Keep one list per shift in one place: a night-shift notebook that nobody transcribes into the system by morning is not a record, it is a note.

Mark every row "notification pending" so the catch-up has a work list with a visible end, and initial each row so the next shift knows whom to ask. Store the fields, not images. Photographing an identity document is a personal-data decision with its own obligations, and it is not what the notification needs. The full field-by-field routine is in KBS at check-in: a front desk checklist for guest identity, and the copying question is covered in ID photocopies at hotel check-in and what the KVKK principle decision changes.

Can we notify reserved guests before they arrive?#

Yes, in the case the Gendarmerie's facility guide describes: reserved customers can be notified up to five days in advance, which removes them from the arrival queue entirely.

The mechanism is simple. The reservation already carries the identity data, so the notification is sent ahead of arrival and the check-in becomes a confirmation instead of a creation. The guide gives the reason itself: avoiding delays on busy group arrival days (Jandarma Genel Komutanlığı, KBS Tesis 2 Uygulama Kılavuzu (opens in a new tab), 11 November 2026). That is exactly the night an outage hurts most. The best fit is tour series, corporate blocks, sports teams, and any arrival after 22:00 when the desk runs on one agent.

Two trade-offs come with it. The first is data quality: a pre-notification sent with a wrong document number creates a correction job that lands on the same busy morning. The second is the no-show: a guest notified in advance who never arrives still leaves an open arrival-departure record that someone must close.

Pre-notification does not replace the check-in record. The arrival time and the room are still written day by day, and the departure still has to be recorded. Confirm the practice with the unit that receives your notifications: the guide is the Gendarmerie's, and your facility may report to the police instead.

How do we catch up afterwards, and who do we call?#

Catch up in arrival order as soon as the connection returns, reconcile the day's list against the system before the night audit closes, and call the software provider first and the competent unit second.

Send the oldest pending record first. The day-by-day duty is easier to explain when the sequence is preserved, and the guest most likely to be inspected is the one who arrived first. Reconcile by counting: arrivals recorded against notifications accepted. Any row without an accepted notification stays on the list and does not get ticked off because the screen looks busy.

Check departures in the same pass. The record covers arrival and departure, and a missing exit is as visible in an inspection as a missing entry.

Call the software provider first when the queue is theirs to see, and the competent gendarmerie or police unit for your facility when you need to explain a gap. Which body receives your notifications is not something this article can tell you, and it is worth knowing before the night it matters.

Say four things on the phone: when the fault started, how many records are pending, what you have written down, and what you have already tried. Nothing else is needed and nothing else helps. Do not quote a deadline in hours or a penalty amount to anyone, including a guest. Neither is published in the material this article relies on, and current figures belong with your accountant or legal adviser.

How do we rehearse for a KBS outage?#

Run a drill in a quiet hour: cut the connection the KBS screen uses, check in one fictional guest, and time both the record and the catch-up.

Choose a quiet hour and tell the front office and the night auditor in advance. A drill nobody expects becomes an incident report. Use a test reservation with obviously fictional data, and never a real guest's document.

Run the full loop: disconnect, check in, fill the fallback record, reconnect, send the notification, reconcile the list. The catch-up is the part that fails in real outages, not the check-in. Measure two numbers: minutes to record one guest, and minutes to clear one pending record afterwards. Multiply by the size of your largest group arrival. Count the fields the agent had to guess: every guessed field is a training gap or a form that does not match the screen.

Repeat quarterly and after any change to the network, the property system or the provider. Keep the drill log with the printed field list so the next shift finds both in the same folder. The wider no-internet case is covered in when the internet goes down: a front desk checklist for cloud-based hotels.

What to do next#

Print the field list from this article, put it beside the check-in screen, and book a quiet-hour drill this week. The parts fit together as one loop: the law sets the record, the diagnostic tells you which layer failed, the field list keeps the record usable, pre-notification keeps the queue short, and the catch-up closes the day before the night audit does.