Once a week, someone asks us: "can I just get MarianaTek data into Google Sheets?"
Yes — technically, three ways. Each one works for a while before it doesn't. Here's the reality check.
Path 1: Manual CSV + paste
The baseline. Export a CSV from MarianaTek admin, open Google Sheets, paste, update formulas, refresh charts.
Where it works
- Your dataset is small (a few hundred rows per report).
- You only need the answer once, or once a month.
- You only care about one report at a time.
Where it breaks
- You want automation. There isn't any — it's a manual Tuesday-night job forever.
- You want to join two reports. You have to paste both and manually cross-reference.
- Someone else maintains the sheet. Every time they update a formula or hide a column, the analysis drifts.
- Row counts grow. Copy-pasting thousands of rows of reservations into Sheets is slow and fragile.
Most studios outgrow this inside twelve months.
Path 2: Zapier / Make / Apps Script middleware
You set up a zap or script that pulls from MT (or watches a new row in some MT-triggered event) and appends rows to a Sheets document.
Where it works
- Light, ongoing operational needs. "Every time a new reservation happens, log it."
- Simple transformations — filter, map, flatten.
- You have someone on your team comfortable with low-code tools.
Where it breaks
- Historical data. Most middleware only fires on new events. Your Sheet starts empty and backfills nothing.
- Volume. Middleware tools price by "operation count." A busy studio can easily blow through a mid-tier plan's monthly allowance just on reservation events.
- Rich joins. Middleware can pipe data into Sheets. It can't structure it the way an analyst would. You end up with several tabs of raw feeds and have to build the analysis in Sheets anyway.
- Reliability. These pipelines fail silently. We've seen studios discover their zap stopped firing six weeks ago — which means six weeks of decisions were made on an incomplete dataset.
Path 3: Apps Script talking directly to the MT API
You (or a developer) write Google Apps Script that hits MarianaTek's API on a schedule and writes the results to Sheets.
Where it works
- You have real engineering help available.
- The data volumes fit inside Apps Script's execution-time limits.
- You know exactly which queries you want and they don't change often.
Where it breaks
- Pagination. MT's API returns paginated results; a full sync of reservations for a mid-size studio can involve hundreds of API calls. Apps Script's execution-time ceiling starts to bite.
- Rate limits. The MT API has them. Hitting them means your sync fails partway through and you get incomplete data without knowing.
- Maintenance. The Apps Script you wrote in January needs updates every time you want a new metric. Your developer cost becomes ongoing.
When a Sheets layer is actually fine
The honest answer for most small studios: a lightly maintained CSV-to-Sheets workflow, refreshed weekly, is a reasonable first analytics layer. If your studio is running at a few hundred active clients and your weekly data needs fit on a single screen, this is probably enough.
You don't need Reserve, and you shouldn't pretend to.
When it stops being fine
Three signals the Sheets approach has run out of runway:
- Your manager is spending more than an hour a week maintaining the pipeline. That's the point where the human cost of the workflow exceeds the benefit.
- Two people on your team disagree about what a number means. Sheets let everyone invent their own definition of "active client." That's fine for one person; toxic for a team.
- You found out about a problem weeks after it started. Weekly snapshots miss the inflection points that matter most.
If any of those apply, it's time to either build a real pipeline (engineering cost) or move to a purpose-built tool (subscription cost). Reserve exists for the second case.
There's no shame in using Sheets. There's also no point in using it past the point where the spreadsheet is costing you more than it saves.