Pylon vs Plain: A Runbook for RFI and Warranty Support

An RFI has a clock on it that the rest of your inbox doesn't. A sub is often blocked from continuing work until the architect or engineer answers, so an RFI buried in a general project inbox costs real schedule days, not just an annoyed email. Set up a distinct RFI category from day one, whether that's a dedicated Slack channel per project that Pylon can turn into a tracked queue, or a ticket type in Plain that tags the discipline and the day it was logged. Either way, the goal is the same: an RFI should never be indistinguishable from a routine question in your reporting.

A change order request that lands with the wrong person just sits there, because nobody wants to make a pricing decision above their authority. Before configuring either tool, write down who can approve a change order under what dollar threshold, and build routing rules around that list instead of around job title. A superintendent fielding a change order question should see instantly whether they can answer it or need to escalate, rather than guessing and getting it wrong in either direction.

This step is worth doing on paper before you touch either platform's settings, because the approval chain rarely maps cleanly onto default role labels like 'admin' or 'agent.' A project executive who only gets involved above a certain threshold still needs to show up correctly in the routing logic, or change orders will keep landing on a superintendent's desk regardless of which tool you bought.

On a job running a dozen subcontractors at once, a sub's question can get buried fast if everyone's messaging into the same group thread. Pylon's approach, turning a shared Slack or Teams channel per sub or per trade into its own tracked queue, matches how many GCs already coordinate day to day, especially with subs used to Teams from other owners. If your subs mostly call or email instead, Plain's ticket structure keeps each request distinct without pushing every trade partner into a new messaging habit.

Punch list items generated in a walkthrough tend to live in a spreadsheet that goes stale within a week, because nobody's updating it as items close. Whichever tool you use, treat each punch item as its own trackable request with an owner and a status, not a line in a document. This matters most in the weeks right after substantial completion, when the owner's attention on outstanding items is highest and a slow-looking process does real reputational damage even when the actual work is moving at a normal pace.

A warranty claim that arrives after your project team has moved on to the next job is the easiest kind of request to lose, because nobody currently on staff remembers the project specifics. Set up warranty claims as their own category with a clear owner, likely someone in a dedicated service or closeout role rather than whichever super happens to be available, and make sure that person can pull up the original submittal and RFI history for context. This is where Plain's searchable, ticket-per-request record tends to hold up better over a multi-year gap than a Slack channel that got archived when the project wrapped.

A GC running both a design-build hospital job and a tenant improvement job at the same time shouldn't necessarily run the same support setup on both. The hospital job likely has more subs, more RFIs, and a longer warranty tail worth a heavier structure. The tenant improvement job might move fast enough that a lightweight shared channel per sub is all it needs. Treat the runbook above as something your project team configures per job kickoff, not a single company-wide default, and revisit it again at substantial completion when the mix of request types shifts from construction questions toward closeout and warranty items.

The runbook in short:

1. Create a distinct RFI category from day one, since RFIs carry a clock that the rest of the inbox does not.
2. Write down who can approve change orders at each dollar threshold, and route by that list instead of by job title.
3. Give each sub or trade a channel or email path that feeds one queue your project team can see.
4. Track every punch list item as its own request with an owner and a status.
5. Set up warranty claims as their own category with a clear owner, so they survive after the project team moves on.
6. Decide the setup per project instead of once for the whole company.