Connecting data in an airsoft business looks dull in practice, which is the point. On Friday evening you want to ask one question: how many players are booked for Saturday, how many complete rental sets are actually on the shelf, and what will not arrive in time. Today that takes three logins and half an hour. What follows is how it becomes one question and one answer.
The work nobody wants
On paper the operation is simple. The field has a calendar with bookings and deposits. The rental desk has a spreadsheet or a paper log recording who took which set and what condition it came back in. The gear shop has its own stock, which then shows up a second time in the accounting system. Three systems, three logins, none of them aware of the other two.
The real work starts when those three views have to meet. Someone opens the bookings on Friday night, counts the players, copies them into the rental sheet, subtracts the sets that are in repair, then checks whether the BBs, gas and batteries will last the weekend. It takes half an hour, it happens late, and the mistake shows up at ten on Saturday morning at the counter.
Saturday has eighty players booked, the rental desk has sixty complete sets, and three of them came back broken last week. You find out at the counter, mid-morning.
— A Friday night at the field, abridged
What connected data actually means
Connecting data does not mean a new system you retype everything into. It means Claude can look into the systems you already run and answer a question asked in plain language. Between Claude and each system sits a small bridge called an MCP server. One bridge to the bookings, one to the rental records, one to stock and accounting.
What matters is what the bridge carries. It carries your identity and your permissions. Claude is not asking as an anonymous service holding a master key, it is asking as you. The data stays where it is. Nothing is copied out, nothing is indexed into a vendor cache, and the whole thing runs on your own infrastructure.
Concretely: bookings, the rental desk and POHODA
Nothing you use disappears. The booking system stays the booking system, the rental sheet stays where it is, and POHODA keeps doing the accounting. All that gets added is the bridge, and with it one question on the evening before a game. For an operation with a few hundred bookings a month and eighty rental sets, that is the difference between half an hour of retyping and two minutes of reading. Treat those figures as an illustration, not a promise.
- Compares the players booked for Saturday against the sets genuinely available tonight, excluding anything in repair.
- Lists the items that came back damaged or incomplete, and what is missing to get back to a full shelf.
- Matches BB, gas and battery sales in the shop against stock in POHODA and flags what will not arrive before the weekend.
- Drafts the supplier order and the accompanying email, then leaves it sitting until you confirm it.
- Pulls first-time players out of the bookings and the mailbox so the longer safety briefing is planned in advance.
A rental desk run by one person on a part-time contract could replace the whole Friday round through three systems with a single question. This is a worked example, not a named client. It is assembled from the tasks that genuinely eat the hours in this kind of operation.
What Claude will not do at the field, and why that is good
Claude hands out no equipment, signs no handover form and decides nobody onto the field. It does not touch the records the law requires you to keep, and it does not edit the price list. When something needs to be written or sent, it waits for a person to confirm. That is not extra caution, it is the reason a bridge like this can go live during a single shift.
The limit is also why it can be trusted. A tool that reads your systems and prepares a brief can be tested over one weekend. A tool that changes stock and emails suppliers on its own needs months of discussion and still gets no trust at the counter. The judgement and the responsibility stay with the duty manager, who simply no longer has to assemble them from three spreadsheets.
What it would take
The first bridge takes days, not months. We need to know what holds your bookings, where the rental records live, and whether the shop or the accounting system is the truth for stock. The bridge runs on your cloud, under your identity, with one audit trail showing who asked what. If the first two weeks save what they should, a second system gets added. If not, one small server gets switched off and nothing is broken.
What is left
The model is not the bottleneck. Claude can count occupancy, reconcile stock and draft a supplier order better than a tired person at ten at night. The bottleneck is the distance between Claude and the data your field already holds. That distance is what we close.
Write to us with what you use for bookings and what you use for stock. A short call is enough for us to say which single bridge is worth building first. Nothing else needs deciding yet.