Platform and intelligence · Incidents & Continuity

Who's in charge when graduation goes off script

A radar with open issues from Event Production, Compliance, OHS, the field team, Support, Quality and Finance in a single list, read live and never copied. What matters becomes a coordinated incident with severity from SEV1 to SEV4, commander, on call, status updates on a deadline, a bell alert when the SLA is breached, costs, MTTA and MTTR. Before the problem, critical processes show RTO, RPO, dependencies and critical suppliers with backups, contingency plans start from ready made templates and the crisis kit gets printed for the venue. Event readiness brings the weather forecast and saves the go/no-go decision with the checks of that moment. Afterwards, the blameless postmortem, actions from every module, recurrence analysis and the maturity score close the loop.

Talk to a specialistSee plans

The problem and the solution

What changes when Incidents & Continuity works inside the platform

This is connected information about classes, graduates and events across 17 modules, replacing scattered spreadsheets and messages.

Without the platform

Information about Incidents & Continuity lives in separate spreadsheets, and nobody knows which version is current.

With Partiu Formatura

17 modules share the same class, graduate and event records.

Without the platform

A request for a number takes time because someone has to combine data from several places.

With Partiu Formatura

Issue Radar and Triage and Severity update together, with figures ready for the next meeting.

Without the platform

The process depends on who is working that day, and its history disappears.

With Partiu Formatura

Everyone follows the same workflow, with recorded actions and role-based permissions.

Without the platform

Connecting with other departments means exporting spreadsheets and entering data again.

With Partiu Formatura

Incidents & Continuity shares information directly with other areas of the platform.

How it works

How information moves through Incidents & Continuity

Each step is a real module in this area. Its output moves to the next step without anyone entering the same information again.

What is available in Incidents & Continuity

Featured

Who's in charge when graduation goes off script

The radar puts everything open in Event Production, Compliance, Occupational Safety, the field team, Support, Quality and failed bank payments into a single list. What matters becomes an incident with severity, a commander, on-time bulletins and a timeline, with a missed-SLA alert even when nobody is looking at the screen. Before that, critical processes show how fast each one must come back, who is on call and which plan to follow when it stops.

See this in action
  • Radar with open issues from seven modules, without copying a single record
  • SEV1 to SEV4 severity with written criteria, bulletin SLA and automatic alerts
  • Ready-made contingency plans, on-call roster and a printable crisis kit
  • Event go/no-go with weather forecast, blameless post-mortem and a maturity score

Issue Radar

Everything open in the other modules, in a single list and without copies.

  • Live reading of nine records from seven modules: Event Production, Compliance (incidents and serious alerts), OHS, Freelancers & Teams, Support, Quality (nonconformities and complaints) and Finance
  • Bank payment routine failures from the last 72 hours coming in as issues
  • High or critical Compliance monitoring alerts on the radar, with no ethics hotline finding at all
  • Severity normalized to low, medium, high and critical, so everything is ranked on the same scale
  • A source missing from the environment becomes a warning on that source, while the others keep showing
  • Support tickets only come in with high or urgent priority, so the radar does not get flooded
  • OHS accident descriptions show only the opening lines, with the details kept under OHS permissions
  • Promote to incident with the severity suggested by the source severity
  • An issue that is already resolved cannot be promoted
  • A promoted incident keeps only the source type and number, and the record stays in the module that owns it
  • Dashboard count of severe issues that still have no incident

Triage and Severity

A severity scale written into the code, not decided in a panic.

  • Four levels, SEV1 to SEV4, with criteria and expected response written next to each one
  • Seven triage questions: risk to life, personal data, event stopped, event affected, money, manual workaround and supplier
  • Number of affected classes weighing on the suggestion
  • Suggested severity calculated by the server and stored alongside the chosen one
  • Raising severity requires no justification
  • Recording or downgrading below the suggested level requires a written reason
  • Every downgrade recorded in the timeline with its reason
  • A warning in the description field so a personal data incident does not repeat the leaked data

Incident Room

Where the response happens and gets recorded.

  • INC-YYYY-NNNN code, sequential per company and year, generated on the server
  • Category, impact, affected people and classes, estimated loss and linked event or class
  • Exactly one commander per incident, with the server refusing any attempt to assign two
  • Responders with roles: communications, technical, operations, supplier and observer
  • Lifecycle of detected, responding, contained, resolved and closed, with canceled as a side exit
  • Time milestones recorded on the database clock, never on the browser time
  • Status, decision, containment or communication updates, with internal or external visibility
  • The first update on a newly detected incident marks the acknowledgment
  • Closed or canceled incidents no longer accept changes
  • Timeline with every change, author and time

SLA, MTTA and MTTR

Time as the core data point, measured without relying on anyone to write it down.

  • Default SLA per severity to acknowledge, update and resolve
  • SEV1 with acknowledgment in 15 minutes, updates every 30 minutes and resolution in 4 hours
  • SEV2 with acknowledgment in 1 hour, updates every 2 hours and resolution in 24 hours
  • Acknowledgment and update delays calculated in SQL, on the same clock as the milestones
  • Overdue status updates highlighted on the dashboard and in the list
  • MTTA and MTTR per severity over the last 90 days
  • A recorded communication counts as a status update for the SLA
  • Deadlines the company can adjust without rewriting the default rule

Critical Processes and Dependencies

An impact analysis for a graduation company, ready the first time you log in.

  • Twelve processes in the catalog: billing, event execution, tickets, photo delivery, customer service, personal data, app access, contracts, invoicing, studio, staff payment and transportation
  • Suggested RTO and RPO per process, with the impact of downtime written out
  • List filtered by the modules the company has active
  • The company stores only its RTO, RPO, owner and active adjustments, and inherits the rest from the catalog
  • Dependencies read from the platform: payment gateway enabled, WhatsApp connected, storage, unfilled staffing slots, expiring permits and active integrations
  • Dependency status as ok, attention, critical or unknown, without pretending everything is fine when data is missing
  • Linked contingency plan and last exercise performed per process
  • No manual dependency setup

Contingency Plans

What to do when a process stops, written before it stops.

  • Twelve ready made templates, including payment gateway down, photographer no show, rain at an outdoor event, power outage, catering failure, medical emergency, data leak, app down, WhatsApp disconnected, entrance check-in stopped, bus that never arrived and galleries unreachable
  • Each template with trigger, objective, minimum severity and linked process
  • Steps by phase: activation, containment, recovery, communication and normalization
  • Suggested owner and relative deadline in minutes for each step, with required or optional steps
  • Applying a template creates an editable draft copy, and the template stays untouched
  • An active plan needs at least one step
  • Plan version and review, with archiving

Plan Activation

The plan that becomes a checklist inside the incident, right when it is needed.

  • Plan activated from the incident room
  • Steps are copied at activation, so editing the plan later does not rewrite what was executed
  • Each step marked as done, pending or not applicable, with who marked it and when
  • Not applicable requires a written reason
  • The same plan cannot be activated twice in the same incident
  • Archived plans cannot be activated, and a resolved incident must be reopened first
  • Checklist frozen when the incident closes

Crisis Communications

The right message for each audience, with no improvising and no forgotten fields.

  • Seven templates: initial notice, update and resolution for graduates, graduation committee notice, staff callout, notice to data subjects and call to a backup supplier
  • Automatic drafting with incident data: code, severity, commander, subject and update interval
  • Placeholders the incident cannot fill stay visible, instead of an invented value
  • The record refuses text with leftover placeholders
  • Required audience and channel: graduates, graduation committee, staff, client, suppliers, press or internal
  • The module does not send anything: the message goes out through the usual channel and the send is recorded with author and time

Postmortems and Actions

What the company learned, written without looking for someone to blame.

  • Postmortem written only after the incident is resolved
  • Initial draft built from the incident itself, so nobody starts from scratch
  • Summary, impact, what worked, what failed, five whys and contributing factors
  • Publishing requires a summary, what failed, at least one why and a root cause written as a sentence
  • A person's name on its own is not accepted as a root cause
  • SEV1 only closes with a published postmortem, and the lock can also apply to SEV2
  • Corrective, preventive and improvement actions with owner, deadline and status
  • An action can point to a Compliance or Quality action instead of duplicating the list

Exercises and Readiness

Proof that the plan works, and a heads up on what could bring down the next event.

  • Tabletop exercises, drills and technical tests, linked to a plan and a process
  • A planned exercise requires a scheduled date; a completed one requires a date and a result
  • A result of passed with caveats or failed requires the gaps written out
  • Exercise gaps can become actions in the same operation
  • Readiness for events in the next 1 to 180 days
  • Staffing check for slots with no one assigned, critical two days before the event
  • Permits or inspection reports that expire before the event date
  • Open issues in Event Production and incidents linked to the event
  • An active plan for event execution and whether it was tested in the last 12 months
  • Matching by date when staffing is not linked to the event, stated on screen

SLA Alerts Off Screen

The deadline breach reaching the people who need it, even with the dashboard closed.

  • A routine every ten minutes for open SEV1 and SEV2 incidents
  • Overdue acknowledgment alert, once per incident
  • Overdue status update alert, once per window: each new update opens a new window
  • Bell notification for administrators and for the incident commander
  • Repeat control recorded in the timeline itself, with the alert type and window
  • Alert link opening the incident room directly

On Call and Emergency Contacts

Who answers right now, and who that person calls.

  • Schedule by period with start and end, person, primary or secondary role and phone
  • Who is on call now on the dashboard and in the incident room, with the next shifts
  • Gaps in the primary schedule for the next 30 days flagged before they happen
  • Emergency contacts by type: public agency, insurer, supplier, internal and other
  • Contact linked to a critical process or an event, or general for all
  • General and specific contacts together in the crisis kit for the process or event

Go/No-Go Decision and Weather Forecast

The event risk seen in time, and the decision saved with what was known at the moment.

  • Go, go with caveats or no-go decision per event, with an owner
  • Checks recalculated on the server at the moment of the decision and frozen with it
  • Caveats and no-go require a justification, and so does go with a critical check
  • Decision history for the event and the latest decision shown on the readiness card
  • Weather forecast on demand for events within seven days, with no service key
  • Chance of rain, high and low temperature and wind for the event day
  • City taken from the record or from the venue text, shown on screen to double check
  • Likely rain from 60% points to the rain plan template and says whether an active plan exists
  • A forecast service outage becomes a warning on the card, without blocking the list

Incident Cost

How much the incident cost, entered on the spot and added up without a spreadsheet.

  • Entry by type: refund, fine, overtime, replacement supplier, lost revenue and other
  • Amount, description and date for each cost, with author
  • Total in the incident room
  • Cost for the last 90 days on the dashboard

Critical Suppliers

Who keeps each process running, who steps in and whether both passed due diligence.

  • Supplier from the registry or a free text name when there is no record yet
  • Backup per supplier, also from the registry or free text
  • Due diligence status read live from Compliance, by the supplier link or by name
  • View per process on the critical processes screen and an overall view across all processes
  • Without Compliance installed, the status shows as unknown, not as approved

Crisis Kit

The plan on paper, for the venue with no signal.

  • Kit per critical process, per plan or per event
  • Active plan with steps by phase, owner and deadline
  • Typical responders, on call channel and contact and who is scheduled
  • Emergency contacts for the process or event
  • Crisis communication templates ready to copy
  • Event readiness checks at the time of printing
  • Dedicated print layout

Analysis, Maturity and Actions Across Modules

Whether the response is improving, what keeps repeating and where preparedness is still weak.

  • MTTA and MTTR by month, with median, for the chosen period
  • Percentage of SLA met per severity, judged by the current SLA scale and stated on screen
  • Recurrence by category, radar source, event and supplier
  • Day of week by hour map of incidents
  • Maturity score from 0 to 100 across seven pillars: impact analysis, plans, exercises, response, postmortem and improvement, communication and on call, event readiness
  • Criteria with no basis are left out of the score, counting neither as zero nor as a hundred
  • Next steps that raise the score the most, with a link to the screen that fixes them
  • Actions from Continuity, Compliance and Quality in a single list, read live
  • Filter by status, module, owner and overdue, with a link to each action's source screen

Checklist

Everything included in Incidents & Continuity

All 129 features in this area, grouped by module so you can compare systems item by item.

  • Live reading of nine records from seven modules: Event Production, Compliance (incidents and serious alerts), OHS, Freelancers & Teams, Support, Quality (nonconformities and complaints) and Finance
  • Bank payment routine failures from the last 72 hours coming in as issues
  • High or critical Compliance monitoring alerts on the radar, with no ethics hotline finding at all
  • Severity normalized to low, medium, high and critical, so everything is ranked on the same scale
  • A source missing from the environment becomes a warning on that source, while the others keep showing
  • Support tickets only come in with high or urgent priority, so the radar does not get flooded
  • OHS accident descriptions show only the opening lines, with the details kept under OHS permissions
  • Promote to incident with the severity suggested by the source severity
  • An issue that is already resolved cannot be promoted
  • A promoted incident keeps only the source type and number, and the record stays in the module that owns it
  • Dashboard count of severe issues that still have no incident
  • Four levels, SEV1 to SEV4, with criteria and expected response written next to each one
  • Seven triage questions: risk to life, personal data, event stopped, event affected, money, manual workaround and supplier
  • Number of affected classes weighing on the suggestion
  • Suggested severity calculated by the server and stored alongside the chosen one
  • Raising severity requires no justification
  • Recording or downgrading below the suggested level requires a written reason
  • Every downgrade recorded in the timeline with its reason
  • A warning in the description field so a personal data incident does not repeat the leaked data
  • INC-YYYY-NNNN code, sequential per company and year, generated on the server
  • Category, impact, affected people and classes, estimated loss and linked event or class
  • Exactly one commander per incident, with the server refusing any attempt to assign two
  • Responders with roles: communications, technical, operations, supplier and observer
  • Lifecycle of detected, responding, contained, resolved and closed, with canceled as a side exit
  • Time milestones recorded on the database clock, never on the browser time
  • Status, decision, containment or communication updates, with internal or external visibility
  • The first update on a newly detected incident marks the acknowledgment
  • Closed or canceled incidents no longer accept changes
  • Timeline with every change, author and time
  • Default SLA per severity to acknowledge, update and resolve
  • SEV1 with acknowledgment in 15 minutes, updates every 30 minutes and resolution in 4 hours
  • SEV2 with acknowledgment in 1 hour, updates every 2 hours and resolution in 24 hours
  • Acknowledgment and update delays calculated in SQL, on the same clock as the milestones
  • Overdue status updates highlighted on the dashboard and in the list
  • MTTA and MTTR per severity over the last 90 days
  • A recorded communication counts as a status update for the SLA
  • Deadlines the company can adjust without rewriting the default rule
  • Twelve processes in the catalog: billing, event execution, tickets, photo delivery, customer service, personal data, app access, contracts, invoicing, studio, staff payment and transportation
  • Suggested RTO and RPO per process, with the impact of downtime written out
  • List filtered by the modules the company has active
  • The company stores only its RTO, RPO, owner and active adjustments, and inherits the rest from the catalog
  • Dependencies read from the platform: payment gateway enabled, WhatsApp connected, storage, unfilled staffing slots, expiring permits and active integrations
  • Dependency status as ok, attention, critical or unknown, without pretending everything is fine when data is missing
  • Linked contingency plan and last exercise performed per process
  • No manual dependency setup
  • Twelve ready made templates, including payment gateway down, photographer no show, rain at an outdoor event, power outage, catering failure, medical emergency, data leak, app down, WhatsApp disconnected, entrance check-in stopped, bus that never arrived and galleries unreachable
  • Each template with trigger, objective, minimum severity and linked process
  • Steps by phase: activation, containment, recovery, communication and normalization
  • Suggested owner and relative deadline in minutes for each step, with required or optional steps
  • Applying a template creates an editable draft copy, and the template stays untouched
  • An active plan needs at least one step
  • Plan version and review, with archiving
  • Plan activated from the incident room
  • Steps are copied at activation, so editing the plan later does not rewrite what was executed
  • Each step marked as done, pending or not applicable, with who marked it and when
  • Not applicable requires a written reason
  • The same plan cannot be activated twice in the same incident
  • Archived plans cannot be activated, and a resolved incident must be reopened first
  • Checklist frozen when the incident closes
  • Seven templates: initial notice, update and resolution for graduates, graduation committee notice, staff callout, notice to data subjects and call to a backup supplier
  • Automatic drafting with incident data: code, severity, commander, subject and update interval
  • Placeholders the incident cannot fill stay visible, instead of an invented value
  • The record refuses text with leftover placeholders
  • Required audience and channel: graduates, graduation committee, staff, client, suppliers, press or internal
  • The module does not send anything: the message goes out through the usual channel and the send is recorded with author and time
  • Postmortem written only after the incident is resolved
  • Initial draft built from the incident itself, so nobody starts from scratch
  • Summary, impact, what worked, what failed, five whys and contributing factors
  • Publishing requires a summary, what failed, at least one why and a root cause written as a sentence
  • A person's name on its own is not accepted as a root cause
  • SEV1 only closes with a published postmortem, and the lock can also apply to SEV2
  • Corrective, preventive and improvement actions with owner, deadline and status
  • An action can point to a Compliance or Quality action instead of duplicating the list
  • Tabletop exercises, drills and technical tests, linked to a plan and a process
  • A planned exercise requires a scheduled date; a completed one requires a date and a result
  • A result of passed with caveats or failed requires the gaps written out
  • Exercise gaps can become actions in the same operation
  • Readiness for events in the next 1 to 180 days
  • Staffing check for slots with no one assigned, critical two days before the event
  • Permits or inspection reports that expire before the event date
  • Open issues in Event Production and incidents linked to the event
  • An active plan for event execution and whether it was tested in the last 12 months
  • Matching by date when staffing is not linked to the event, stated on screen
  • A routine every ten minutes for open SEV1 and SEV2 incidents
  • Overdue acknowledgment alert, once per incident
  • Overdue status update alert, once per window: each new update opens a new window
  • Bell notification for administrators and for the incident commander
  • Repeat control recorded in the timeline itself, with the alert type and window
  • Alert link opening the incident room directly
  • Schedule by period with start and end, person, primary or secondary role and phone
  • Who is on call now on the dashboard and in the incident room, with the next shifts
  • Gaps in the primary schedule for the next 30 days flagged before they happen
  • Emergency contacts by type: public agency, insurer, supplier, internal and other
  • Contact linked to a critical process or an event, or general for all
  • General and specific contacts together in the crisis kit for the process or event
  • Go, go with caveats or no-go decision per event, with an owner
  • Checks recalculated on the server at the moment of the decision and frozen with it
  • Caveats and no-go require a justification, and so does go with a critical check
  • Decision history for the event and the latest decision shown on the readiness card
  • Weather forecast on demand for events within seven days, with no service key
  • Chance of rain, high and low temperature and wind for the event day
  • City taken from the record or from the venue text, shown on screen to double check
  • Likely rain from 60% points to the rain plan template and says whether an active plan exists
  • A forecast service outage becomes a warning on the card, without blocking the list
  • Entry by type: refund, fine, overtime, replacement supplier, lost revenue and other
  • Amount, description and date for each cost, with author
  • Total in the incident room
  • Cost for the last 90 days on the dashboard
  • Supplier from the registry or a free text name when there is no record yet
  • Backup per supplier, also from the registry or free text
  • Due diligence status read live from Compliance, by the supplier link or by name
  • View per process on the critical processes screen and an overall view across all processes
  • Without Compliance installed, the status shows as unknown, not as approved
  • Kit per critical process, per plan or per event
  • Active plan with steps by phase, owner and deadline
  • Typical responders, on call channel and contact and who is scheduled
  • Emergency contacts for the process or event
  • Crisis communication templates ready to copy
  • Event readiness checks at the time of printing
  • Dedicated print layout
  • MTTA and MTTR by month, with median, for the chosen period
  • Percentage of SLA met per severity, judged by the current SLA scale and stated on screen
  • Recurrence by category, radar source, event and supplier
  • Day of week by hour map of incidents
  • Maturity score from 0 to 100 across seven pillars: impact analysis, plans, exercises, response, postmortem and improvement, communication and on call, event readiness
  • Criteria with no basis are left out of the score, counting neither as zero nor as a hundred
  • Next steps that raise the score the most, with a link to the screen that fixes them
  • Actions from Continuity, Compliance and Quality in a single list, read live
  • Filter by status, module, owner and overdue, with a link to each action's source screen
← Previous areaAntifraud & ChargebackNext area →Alumni & Post-Graduation

How Incidents & Continuity connects to the rest of the platform

These areas share the same records. Information entered here is available there without exporting spreadsheets or entering it again.

Workflow & Document Management

Partiu Fluxo is the corporate process engine: you draw the flow in a diagram, assemble the form that will be filled out, define who approves and in how long, and the system takes the request from start to finish.

Quality & Compliance

Inspection plan, conference with sampling, non-compliance with cause and action, cost of poor quality, audit, graduate complaint and indicators.

Artificial Intelligence

More than a system, an intelligent copilot.

Want to see Incidents & Continuity in your operation?

See a demonstration using your own numbers, with no obligation. A conversation will help you decide whether the module solves your needs.

See plansExplore other areas