The Request Tracker Template That Enforces SLAs Before Anyone Asks
Most intake systems don't fail because they're hard to use. They fail because nobody knows who owes a response, when it's due, or whether the SLA already breached. This template makes that visible before the requester has to chase you.
Internal request tracking has a quiet failure mode. Not the loud one where the system crashes or the form breaks — the invisible one where requests sit, unacknowledged, while the requester assumes someone is working on them.
That is the problem this template is built to catch: SLA visibility before the follow-up email arrives.
Get the Request Intake template ->
The invisible intake problem
Most teams already have some kind of intake. It might be a shared inbox, a Google Form connected to a spreadsheet, or the "general" channel in Slack where people drop requests at 4:55 PM on a Friday.
The problem isn't that these systems don't work. It's that they don't make response time visible. A request can sit for three days, and unless someone is manually tracking response windows, the first alert is the requester sending a follow-up that starts with "Just checking in…"
By that point, the SLA is already blown. The team just didn't know it yet.
What this template tracks
The Request Intake & Triage starter is built on three connected tables — Departments, Requesters, and Requests — with an SLA breach formula baked directly into the structure.
| What gets tracked | Why it matters |
|---|---|
| Who submitted the request and from which department | Makes ownership routing explicit |
| When it arrived and when it's due | SLA clock is visible from the moment the row is created |
| Current status with audit trail | Shows whether the request is open, assigned, or resolved |
| Breach flag driven by a formula | Highlights overdue items automatically — not manually |
| Department-level rollups | Shows intake volume and breach rate per team |
The core idea: if a request is sitting past its due date, the row should scream. Not politely. Visibly.
The rebuild logic: what we changed from the usual approach
We studied how intake systems break, and rebuilt around those breakpoints.
The spreadsheet model
Spreadsheets are how intake usually starts. One tab, some columns, a color-coding system that three people understand but nobody documented.
The strength is speed of setup. The weakness is that spreadsheets have no concept of a clock. A request that's been sitting for six days looks identical to one filed this morning, unless someone adds a conditional formatting rule — and maintains it.
This template keeps the clarity of columns but adds the thing spreadsheets can't do: a live SLA calculation that changes the row's visibility when time runs out.
The ticketing tool model
Ticketing systems expect structure: categories, priorities, assignees, SLAs. The benefit is that the system enforces process. The downside is that many lighter-weight teams don't need — or want — the overhead.
This template borrows the SLA enforcement but strips out the complexity. It's closer to "structured intake with a clock" than a full ITSM deployment.
What changed in this build
- Departments hold the routing metadata — who owns which kind of request
- Requesters store who is asking and their department affiliation
- Requests carry the intake payload: description, priority, due date, status, and the breach flag
- The SLA formula doesn't wait for a human to notice. When
Due_Datepasses and the request isn't closed, the breach flag turns on automatically. - Filtered views separate active work from the breach queue, so the triage view is always the right starting point.
The result: a team lead can open one view and see every request that needs intervention — without running a report, without asking for updates, without touching a formula.
What you get in the starter
The gated download includes:
- A ready-to-import Baserow export with three linked tables
- Sample data: 4 departments, 4 requesters, 15 requests (with 4 SLA breaches pre-configured for testing)
- An SLA breach formula that auto-flags overdue, unresolved requests
- Pre-built filtered views for active requests and the breach queue
- A 5-minute install guide for both baserow.io and self-hosted Baserow
Download the Request Intake starter ->
Why open source matters for intake
An intake system feels small when you set it up. It stops feeling small when it becomes the single source of truth for who asked for what and whether the team delivered.
At that point, a few things become important that closed tools don't optimize for:
- Data ownership. When requests contain internal context, names, and department structures, teams care about where that data lives.
- Extensibility. A good intake template should grow with the team — add an approval step, add a triage field, hook it to a dashboard — without hitting a vendor paywall.
- Cost per seat. Closed ticketing systems charge per agent. That works for IT help desks. It is harder to justify for an operations team that wants ten people to be able to log and track requests without buying ten licenses.
This is why we built the template as an open source request tracker template on Baserow. You control the data, the permissions, and the model.
Evaluating whether this fits your team
Ask five questions before you download:
1. Do you currently track requests through email or a shared inbox?
If yes, you already have an intake problem. The question is whether you want to keep solving it with search and follow-ups.
2. Can someone new see what's overdue in under ten seconds?
If the answer involves "let me check the spreadsheet," the visibility gap is real.
3. Is your SLA definition explicit?
"ASAP" is not an SLA. A due date that turns into a breach flag is.
4. Does the system scale past one person?
If intake works because one person holds the context in their head, the team has a bus-factor problem. The template replaces individual memory with system behavior.
5. Do you control the system once it's critical?
If intake becomes the spine of team operations, switching costs go way up. Starting with an open system gives you the option to extend without re-platforming later.
Where this starter fits
This template is right for teams that:
- Manage internal requests through email, chat, or a spreadsheet
- Need SLA visibility without deploying a full ticketing platform
- Want to prove an intake workflow before investing in a heavier system
- Prefer open-source infrastructure they control
It is not a replacement for Jira Service Management or ServiceNow. It is the thing you use before you need those — or instead of them, if your team's intake volume doesn't justify the overhead.
Bottom line
Request intake fails silently. The failures don't announce themselves — they accumulate in inboxes, in "just checking in" emails, in the gap between when something was asked for and when anyone acknowledged it.
The fix isn't a more complicated system. It's a system that makes response time visible and automatically flags what's overdue.
Grab the starter and run it against one real intake channel. The breach logic will tell you more in a week than a status meeting ever could.