Baselines: the same project, executed exactly right, every time.
Most platforms hand every team the same checklist and call it standardization. That isn't standardization. That's a generic plan.
A new opening, a transition, a company-wide rollout: the project name repeats, but the work underneath inevitably has unique variations by location. The flagship resort has a full-service spa and specialty restaurant; the airport property doesn't. The franchise in a leased space skips the permitting steps for a greenfield construction.
Pacer's Baselines are built to command that variance, not ignore it.
One template. Every team gets only what's theirs.
A Baseline is the standard. Pacer decides which standards apply, and blends them into one list.
Every project starts with a core Baseline — the tasks every location owns, no exceptions. Every McDonald's needs a grill. But a project is never just the core. So you build Baselines for the scenarios layered on top of it: one for locations with a drive-thru, one for locations with a playground, one for whatever variation your business actually runs.
The PM decides which Baselines apply. Pacer builds the list.
When the project goes live, the PM doesn't reassign the standard — they select which Baselines apply to which locations. Pacer takes it from there, blending the core and every relevant scenario Baseline into a single task list, purpose-built for that location. Drive-thru tasks land on drive-thru locations. Playground tasks land where there's a playground. Nowhere else.
The standard doesn't bend. What changes is which standards are in play — and Pacer makes that call with precision, every time.
Generic templates can't tell the difference between "irrelevant" and "ignored."
A flat checklist treats every location like every other location. It can't see:
- Which tasks actually apply to a given location, role, or team — versus which ones are dead weight inherited from a template that was never built for them
- The dependency chain that determines whether a task can even start, regardless of what the calendar says
- When "Not Applicable" is being used correctly versus used to avoid a status update
- That the team doing onboarding for the fifth time needs a different sequence than the team doing it for the first
A pile of "Not Applicable" statuses isn't harmless. It's noise. It buries the work that matters, trains teams to stop reading their task list closely, and tells them, correctly, that no one in command built this for the rollout in front of them.
Pacer's Baselines were built for organizations running the same kind of project at scale, over and over, where the variance between locations isn't an exception to manage. It's the job.
Workflows hold the line on every task, automatically.
A Baseline isn't a static list. It's a set of rules that govern behavior. Configure triggers and actions once at the Baseline level, and they enforce themselves across every location: require a comment before a task closes, require a file before it's marked complete, force a real status when someone tries to wave a task off as "Not Applicable." Set the rule once. It holds everywhere, without you watching every location to make sure it does.
A Baseline names the job. Not the person.
Most tools force a task onto a person's calendar the moment it's created, which means someone has to already be hired, already be in the system, before the work can even be planned. Pacer doesn't make that assumption, because the standard was never about who. It's about what the location owes.
A Baseline task carries a Suggested Job Title (General Manager, Chief Engineer, Front Office Supervisor), not a name. The role the task belongs to, decided once, at the standard.
Responsible is who actually does it. That gets assigned at the location, in bulk, whenever the location is ready, whether that's the day the project launches or the day the position finally gets filled.
Corporate isn't managing headcount. Corporate is managing brand compliance. Pacer separates the two because you already do.
Dates that travel with the location, not the calendar.
A Baseline doesn't carry hard dates, because a standard that only works for the first location isn't a standard. It's a one-time plan. Every task carries a T-minus: how many days before or after that location's go-live, and Pacer calculates the actual due date the moment the Baseline is applied.
Run the same Baseline for your third opening this year, or your thirtieth. Nothing gets edited. Nothing gets rebuilt. The standard doesn't age. It just recalculates.
(See how T-minus and go-live scheduling work in Automated Scheduling.)
Give every team a list that looks like it was built for them. Because it was.
A Baseline isn't a template you hope people follow. It's the standard, applied with command.
Every team opens their task list and sees exactly what's theirs: no scrolling past work that belongs to another department, no second-guessing whether a task applies to them. Less noise. More ownership. A team that trusts its list moves faster than a team that has to interrogate it first.
This is what it looks like when one organization runs hundreds of versions of the same project, and every single one runs to standard.