RAID Log for SaaS Implementations (2026 Template + Playbook)

A RAID log for a SaaS implementation is one shared list of the Risks, Actions, Issues and Decisions on a single customer engagement, where every line has an owner, a date and a status. It sits next to the project plan, and it does a different job: the plan says what should happen and when, the RAID log says what could stop it, what is already stopping it, what someone promised to do about it, and what was decided along the way. Kept to the items that can move go-live and reviewed weekly, it is the cheapest early-warning system an implementation team can run.

This playbook covers which RAID variant fits customer implementations, the fields each entry needs, the twelve risks that show up on almost every SaaS project, how to score and review them, what the customer should see, where the log should live, and a template you can copy. It is written for implementation managers, forward-deployed engineers and the leaders who read their status reports.

What is a RAID log in a SaaS implementation?

RAID is an acronym for the four categories of things that can affect a project outside the task list. Asana's guide notes that the A can stand for Assumptions or Actions and the D for Dependencies or Decisions, and that teams can use one or both. Smartsheet describes the classic Risks, Assumptions, Issues, Dependencies version, plus a RAIDO variant that adds Opportunities.

For customer implementations, use Risks, Actions, Issues and Decisions, and carry assumptions and dependencies as fields on the rows. The reason is practical: customer projects rarely die from an unexamined assumption. They die from an action nobody owned, an issue that sat for three weeks, and a decision made on a call that nobody wrote down. Assumptions ("customer IT can provision SSO in week two") and dependencies ("mapping cannot start until the export arrives") belong in the description and trigger fields of the risk they create.

Two boundaries keep the list useful: a risk becomes an issue the moment its trigger fires (move the row, do not duplicate it), and an action belongs in the log only when it is a promise made in a call or thread that is not already a task on the plan.

Why do SaaS implementations need a RAID log when they already have a project plan?

Because the plan tracks work that was scheduled, and implementations mostly slip on things that were never scheduled: a sign-off that stalls, a stakeholder who changes, a decision that gets relitigated. The last two years of industry surveys agree on this.

• OnRamp's 2026 State of Customer Onboarding report (161 CS, onboarding and implementation leaders, surveyed Q4 2025) found that 62% of CS leaders lack real-time visibility into customer progress during onboarding, and one in three do not know where customers stand at any given time. Its top three momentum killers are scattered tools, unclear next steps and ownership, and manual, disconnected communication.
• Rocketlane's 2025 State of Customer Onboarding survey (950+ leaders and practitioners) reports that 45% of teams still struggle with information scattered across tools, and names decision-makers changing post-sale, vague documentation and waiting on customer approvals as recurring friction.
• Panorama Consulting's 2026 ERP Report (170 organizations, median project timeline nine months) found almost a quarter of projects over schedule and more than a quarter over budget. The top cause of schedule overruns was organizational issues; in the report's words, technical execution often proceeds as planned while approvals, sign-offs and cross-functional alignment trail behind.
• Atlassian's State of Teams 2025 (12,000 knowledge workers and 200 Fortune 1000 executives) found that just 20% of knowledge workers are confident their team has an effective process for informing other teams of decisions that affect them, and one in two say teams unknowingly work on the same things.
• PMI's Pulse of the Profession 2026 reports that four out of five complex projects experience negative fallout such as delivery disruptions, that projects using a structured framework succeed at 72% versus 61% without one, and that 35% of professionals used no framework on their most recent complex project.

That is one finding: most of what goes wrong is coordination, and coordination failures are invisible in a Gantt chart until they have cost you weeks. A RAID log is where "the data owner has not answered in nine days" becomes a line with an owner and an escalation date instead of a feeling in the implementer's stomach.

What fields does every RAID entry need?

Twelve fields is the practical ceiling; more and nobody fills them in. Asana's baseline (ID, description, category, date identified, owner, priority, status, action plan) covers the core; the additions below matter on customer projects, where two organizations share every risk.

The source link is the field most templates omit and the one that saves you in month three. When a stakeholder says "we never agreed to phase the third region," a decision row linking to the March 4 call at 41:20 ends the conversation. If you run customer channels in Slack, the decision-tracking pattern for customer Slack channels feeds this column directly.

Which risks show up in almost every SaaS implementation?

Most engagement risks are variations on the same twelve. Seed the log with these at kickoff and delete what does not apply. The early signal column is what to watch; the response column is the default play.

Ten of the twelve are people and process risks, which matches Panorama's finding that fewer than a quarter of organizations put intense focus on change management, with resistance showing up as delayed sign-offs and repeated design revisits. Your RAID log will be mostly about humans, and that is correct.

How do you score risks without turning the log into theater?

Use a 3 by 3 grid, review only the top five risks each week, and measure impact in days of go-live slip. Five-by-five matrices look rigorous and get abandoned by week three because nobody can defend the difference between a 3 and a 4.

• Probability: 1 = unlikely before go-live, 2 = could plausibly happen, 3 = the early signal is already showing.
• Impact: 1 = absorbed inside the current phase, 2 = slips a milestone by a week or more, 3 = moves go-live or removes committed scope.
• Score: probability times impact. A 6 or 9 goes on the customer status call; a 9 also gets an escalation owner on your side, usually the implementation lead.

Add one number most templates skip: exposure days, how long an action or issue has been open past its due date. It is the most predictive figure on the sheet. A risk scored 4 whose mitigating action is 12 days overdue is more dangerous than a fresh 6.

The discipline pays off in outcomes. PMI's 2025 Pulse of the Profession measured professionals partly by how many roadblock-mitigation tactics they actually applied; those with high business acumen reported an 8% project failure rate against 11% for everyone else, with better schedule adherence (63% vs 59%) and budget adherence (73% vs 68%). The differentiator was acting on known roadblocks early, which is the point of a scored, reviewed log.

How often should you review a RAID log during an implementation?

Update it the moment something changes, review it internally every week, review the shared rows on every status call, and do a full pass at each milestone gate. Asana and Smartsheet both recommend the weekly status meeting as the minimum, with Smartsheet adding milestone reviews. For enterprise engagements, add a monthly steering committee, which Rocketlane's 2025 report describes as where out-of-scope requests get approved or refused.

The milestone gate is where sponsor alignment gets rebuilt. PMI's 2026 research found sponsor alignment at initiation used by 39% of high-performing complex projects versus 30% of low performers, and scenario planning used by only one in five practitioners despite marking high performance. A twenty-minute RAID pass at every gate is a lightweight version of both. If you run five to ten engagements at once, the weekly internal review is the one you cannot skip; the playbook for managing multiple customer onboardings covers how to batch it.

Should the customer see the RAID log?

Yes for issues, actions and decisions; selectively for risks. Run two layers: a shared log both project leads edit, and an internal view for rows you would not put in front of the customer.

The shared layer is the accountability mechanism. A customer action ("confirm the SFTP allowlist by Thursday") that sits in a list the customer's project lead sees weekly with their own name on it gets done at a rate a buried email never achieves. Read decisions back on every call: "Last Tuesday you decided to phase region three; still correct?" Confirming in the moment is cheap; discovering a misremembered decision at UAT is expensive.

The internal layer holds what is true but unsayable: "champion is job hunting," "customer admin is not technical enough for the data work." GitLab's professional services team runs exactly this pattern; its public delivery handbook describes an internal RAID board as the single source of truth for project risk and resolution, which gets linked into the top-customer report whenever a project turns yellow or red. That link gives leaders risk visibility without a separate reporting exercise, and it is the model behind the onboarding health score most CS leaders are trying to build.

Where should the RAID log live: spreadsheet, onboarding platform, or Slack?

Anywhere both sides will actually look at it. Storage matters less than capture: OnRamp's 2026 report found 60% of companies use four to six tools for customer onboarding, and Atlassian's 2025 data found 56% of workers say the only way to get the information they need is to ask someone or book a meeting. A log in a sixth tool nobody opens is a risk in itself.

The last row is where the category is heading. OnRamp found 70% of CS leaders expect AI to handle half of all onboarding tasks by 2027, with early risk detection and status summaries near the top of the list. Stipulate takes that approach: it reads customer Slack channels and call transcripts and builds a record of every decision, risk, blocker and action item, each linked to its source message, so the RAID log is assembled from the conversation instead of reconstructed from memory on Friday afternoon. Whichever home you choose, the test is the same: can a new person on the account read the log and know in five minutes what is at risk, who owes what, and why?

Why do RAID logs die, and how do you keep yours alive?

They die from clutter, missing owners and no closure, in that order. Smartsheet's guide lists outdated data, false security and identification bias as the main failure modes, and a 2025 PMP newsletter described the typical risk register as a dusty spreadsheet nobody looks at until something goes wrong. Both describe the same log: filled in at kickoff, never touched again.

1. Cap open risks at ten. Asana's advice to log only high-priority, cross-functional or recurring items is right. If a row cannot move go-live or scope, it belongs in your notes.
2. No row without a named owner on both sides. "Customer" is not an owner. "Marisa, Ops Director" is.
3. Close rows out loud. Read closed items on the status call. Visible closure is what makes people willing to add new rows.
4. Write the source link first. A decision without a source gets relitigated; an action without a source gets denied.
5. Retire risks that can no longer happen. Once migration is signed off, the data-readiness risk is closed, not "monitoring." A log where everything stays open teaches people to stop reading it.

One more habit from teams whose logs survive: capture at the point of promise. When someone says "I'll get you that by Thursday," the action is logged with the timestamp before the call ends. If that depends on remembering later, it happens for three weeks and then stops. The AI meeting notes workflow for customer onboarding covers how to make that capture automatic.

A RAID log template you can copy for a SaaS implementation

A starting log for a mid-market engagement in week two, columns compressed for reading. Copy the structure, replace the rows, and keep the ID scheme so Slack messages and status reports can point at specific lines.

Past thirty open rows by week six, the log has become a task list; move routine work back to the plan and keep the RAID log for what threatens it.

Next steps

1. Seed the log at kickoff. Copy the twelve common risks, delete what does not apply, and write the early signal for each.
2. Name two owners per row, one on your team and one at the customer, read back on the call.
3. Add the source link column today. Decisions and actions without a link to the call or thread are the ones that get relitigated.
4. Book fifteen minutes a week per engagement for the top five risks, every overdue action and exposure days. Put it on the calendar.
5. Run the two-layer model: shared log for issues, actions and decisions; internal view for the risks you would not say out loud, linked into your leader's health report when a project goes yellow.
6. Capture at the point of promise, whether by habit or with a tool that reads your calls and Slack channels.