Why Campground PMS Config Belongs in Markdown

It is Tuesday morning. You raised the pet fee for holiday weekends. You closed Loop C for reseeding. You need site 14 marked “no fifth-wheels over 35 feet” before the Thursday rush. In most campground software that is three screens, two forgotten toggles, and a prayer that the booking widget, the office calendar, and whoever answers the phone all got the memo.

Campground PMS config belongs in markdown because park rules — sites, rates, pets, amps, closures — must live in one human-editable source of truth. The guest site, office tools, and AI voice agent should all read that same truth. Forms can help you edit. Forms must not own the only copy.

TL;DR - Parks sell heterogeneous inventory, not identical hotel rooms. Config is the product. - Click-only vendor UIs create drift: website says one thing, staff another, the phone a third. - Software teams already solved this class of problem with versioned, machine-readable definitions (Infrastructure as Code thinking) — parks can borrow the useful parts without becoming a DevOps shop. - Demo any PMS with your map and ugly rules (Firefly’s 2026 comparison says the same in different words). - Lunaria Booking’s model: property truth in plain markdown the engine reads, then booking surfaces and site-specific agents share it. - Related deep dive: why plain markdown beats locked databases.

What does “PMS config” mean at a campground?

PMS config is everything that defines what you sell and under what rules: site attributes, rate rules, policies, amenities, blackout dates, and the notes that stop a bad booking at the gate. If it changes how a guest is allowed to book a specific site, it is config.

For an independent park that usually means:

That is not a hotel “room type + BAR rate” problem. Small lodging writers keep pointing out that independents run with one person wearing many hats and need simplicity more than chain-level configurability (HotelFriend on small-hotel PMS fit). Translate carefully: a 40-site RV park is closer to that owner-operator reality than to a 200-room brand standard — and the inventory is more irregular, not less.

If your config model cannot express site 14’s weirdness, staff will invent a workaround. Workarounds become the real system.

Why do vendor form UIs fail independent parks?

Vendor form UIs fail independent parks when the only source of truth is a maze of screens built for specialist roles your park does not staff. The failure is not “forms exist.” The failure is forms as the only copy of the park.

Common failure modes:

1. Role theater. Chain-shaped software assumes a front desk, a revenue manager, and an IT person. You have one owner and a seasonal hire.
2. Incomplete models. Glamping pods, seasonal residents, and odd site attributes force weekly workarounds when the inventory model does not fit (RaftLabs on where off-the-shelf campground tools hit walls).
3. No honest history. Who changed the pet fee last Friday? The dashboard shrug is not an audit trail.
4. Export as afterthought. Leaving means a lossy CSV and a week of reconstruction.
5. Second brain for the phone. The website has one policy doc. The answering service has a PDF from 2023. The AI pilot has a pasted FAQ. Guests get three answers.

Ease of use for seasonal staff is not a nice-to-have in campground software comparisons — it is a top evaluation factor (Firefly 2026 comparison). A UI that only the owner can drive is a staffing tax.

What does markdown config actually look like (without the nerd cosplay)?

Markdown config means your property rules live in plain, structured text you can read, search, diff, and back up. It does not mean you must hand-write YAML under a headlamp every Saturday.

Practical shape:

```markdown ## Site 14 - type: back-in - max_length_ft: 35 - amps: 30 - sewer: false - pets: true - notes: Soft shoulder after heavy rain

## Holiday weekends - min_nights: 3 - pet_fee: 20 ```

You do not need to love angle brackets. You need:

• One place where site 14 is defined.
• Readable enough that a partner can spot a wrong amp rating.
• Copyable enough that a second property does not start from zero clicks.
• History when something changes (git or any versioned store).

This is the same idea software teams call Infrastructure as Code: describe the desired system in files, keep those files in version control, and make changes reviewable instead of tribal memory (GitHub on IaC). Parks can take the benefits — repeatability, history, fewer “works on my machine” surprises — without adopting every cloud tool in that article.

Lunaria Booking’s public stance is blunt: property sites, rates, and policies should live in plain markdown the engine reads, then become the guest site and agent brain (markdown vs locked databases).

How does shared config fix website, office, and phone drift?

Shared config fixes drift by making every channel a view of the same property truth instead of a separate pamphlet. One edit updates the facts the website, office, and phone are allowed to use.

That is why site-specific questions — pull-through, hookups, pet policy — are a config problem before they are a “smarter AI” problem (site-specific voice agent test). If it is not in the property truth, the agent should not freestyle it.

Demand pressure makes the cost of wrong answers real. Outdoor recreation is a large, measured slice of the U.S. economy — BEA data highlighted by RVIA put 2024 outdoor recreation at about $1.3 trillion in economic output, with RVing at $27.5 billion in value added (RVIA summary of BEA figures). You do not need those macro numbers to run a park, but they explain why peak-weekend mistakes are not abstract: people are out, booking, and calling.

What should you demand in a PMS demo (markdown or not)?

Demand a park-shaped demo with your real constraints. Logo tours lie. Your map does not.

### Bring this packet - Site list with the weird ones marked. - Pet, generator, and holiday rules in plain language. - One rate exception you always forget to explain. - The last policy change that caused a gate argument.

Force these proofs

1. Change a rule live. Pet fee or min-stay. Time how long until the guest path shows it.
2. Book a constrained rig on a phone. Length + amps + pets. No staff override heroics.
3. Show history. What changed this month, and can you roll back a bad edit?
4. Export. Reservations and property definition — not “we can get you a report.”
5. After-hours path. If they pitch AI, ask a site-specific question and make them show where the answer is stored (accuracy test).
6. Seasonal hire test. Could someone new survive Saturday with a one-page cheat sheet?

Score vendors on inventory fidelity and change speed, not on how many marketplace logos fit on a slide. The same fit-test mindset belongs in any ResNexus alternative search.

When is markdown the wrong lead story?

Markdown is the wrong lead story when your team will not touch structured text even with a guided editor, or when corporate IT already mandates another system of record you must follow.

Be honest:

The point is not “owners must become programmers.” The point is the system of record should be inspectable. A friendly UI that writes markdown (or another plain format) still beats a black-box schema you can only poke through support tickets.

Custom software houses will happily sell a $120K+ build when off-the-shelf models fail your site types (RaftLabs cost ranges). Sometimes that is right. Often the cheaper fix is a PMS whose config model matches parks — and does not trap the definition of your property inside five nested modals.

What should you do this week?

This week, write the park in plain language, find where those rules already disagree, and force your next vendor demo to change one rule live across every channel.

1. Write your property rules in one plain document: sites, pets, amps, holidays, the weird stuff.
2. Highlight every place those rules currently live (website CMS, PMS screens, binder, Google Doc, answering service script).
3. Pick the three conflicts that already caused a guest issue.
4. In your next vendor demo, change one rule live and watch every channel.
5. Ask for export of config, not only reservations.
6. If you use or plan AI on the phone, require the shared-truth accuracy test before go-live.
7. Keep a dated backup of the plain document even if you stay on your current PMS — that file is leverage.

FAQ

Is markdown really better than a good settings UI?

A good settings UI is fine. A good settings UI that is also the only copy of your property is not. Prefer an editor that writes an inspectable source of truth you can export and version.

Do I need GitHub to use markdown config?

No. Git is one way to get history and backups. The requirement is versioned, readable property truth — not a specific host. Some operators never open a terminal and still benefit when the platform handles versioning behind the scenes.

Will seasonal staff need to edit markdown?

Usually no. Staff need a simple workflow for day-to-day rates and blocks. Owners and managers need a clear place where hard rules live. If only one person on earth can change pet policy, that is a bus-factor problem regardless of file format.

How is this different from “we have an API”?

An API is how other software talks to your system. Markdown (or plain config files) is how humans read and own the definition of the park. You want both eventually. Start with human-readable truth; bolted-on APIs on a mushy core still drift.

Can locked-database PMS tools still work for my park?

Yes, if inventory fidelity is high, changes are fast, export is real, and you are not trying to run an accurate after-hours agent off a stale FAQ. Many parks run fine. The markdown argument matters most when drift, migration fear, or multi-channel answers are already costing you.

How does this relate to AI voice agents?

Agents amplify whatever truth you give them. Shared config makes accurate site answers possible. Separate brochure brains make confident wrong answers. Test before you trust the line.

Where does Lunaria Booking fit?

Lunaria Booking is built so owners describe the park in plain markdown the engine reads — guest booking surfaces and the AI voice/SMS path aim at that same truth. Judge it with the demo script above, not a slogan.

---

If your next software decision starts with a feature matrix, flip the order: write the park in plain language first, then ask each vendor to show you where that document lives inside their system. If they cannot point to it, you already know how the Thursday pet-fee fight ends.