Operations manager SGEN onboarding guide
| Field | Value ||---|---|| Audience | sgen-admins || Page type | guide || Area | _workflows/role-onboarding || Updated | 2026-05-25 |How to onboard as an Operations Manager in SGEN
This guide is your operating playbook as an operations manager on a SGEN-hosted site. It covers the four areas you own — Audit Log, Backups, Integration health, and Status + Notifications — and shows you what to review weekly (30-45 min), verify monthly (1-2 hours), and action during an incident (as needed). The cadence is grounded in real operational workflows: weekly site-health sweeps, monthly stakeholder reports, and an escalation drill to confirm your runbook is live before you need it. It also names the areas you should never need to enter, so you can push back confidently when someone routes the wrong ticket to you.
Before you start
Before your first session, confirm the following with your site owner or platform administrator:
- Your account is assigned a role with read access to Audit Log, Backups, and Integrations. Standard Editor access does not include these panels — your administrator may need to assign you a higher role. Confirm in the admin → Users that your account entry shows the correct role.
- At least one backup schedule is active. If the admin → Backups shows no scheduled backups, your administrator needs to configure one before your first verification run. Share Activate and verify backups with them.
- Your integration list is documented. Before your first integration-health sweep, gather the names of every active integration your site depends on — payment gateway, CRM, email service provider, analytics connector, and any webhook endpoints. Keep this list somewhere the whole team can access it.
- Escalation contacts are confirmed. Your escalation runbook is only useful if the contacts in it are current. Before going live, collect name, channel (email or phone), and backup contact for every integration vendor and your internal technical lead.
- You are subscribed to SGEN platform status alerts. Go to the admin → Settings → Notifications and confirm a delivery address is set for platform-level alerts. This ensures you receive notice of planned maintenance and outages before your users do.
If any of the above is missing, share this guide and Manage users list with your site owner so they can correct your access before your first solo session.
Where to go
Your primary areas inside the SGEN admin panel:
| Area | What you do there |
|---|---|
| the admin → Audit Log | Row-by-row record of every admin action — who changed what, and when |
| the admin → Backups | Verify backup schedule, confirm last successful run, trigger manual backup if needed |
| the admin → Integrations | Review connection status for every active integration, check last-sync timestamps |
| the admin → Settings → Notifications | Subscribe to platform-status alerts and configure operational notification routing |
| the admin → Users | Assign and revoke roles during onboarding, offboarding, or permission escalation events |
You do not need to visit Theme Editor, Custom Codes, Blog, Popups, or Forms in your operational capacity. Those areas belong to your content, marketing, and developer counterparts. If a content team hits a blocker you cannot resolve from your five areas, your job is to escalate it — not to reach into their tooling and fix it directly.
What is this for?
This guide is a role-scoped operating cadence for an operations manager at a SGEN-hosted site. It answers "what should I do in SGEN every week and every month?" and "what do I do when something breaks?" rather than teaching individual features from scratch. Each section links to the relevant reference doc for the feature it covers — follow those links when you need field-level detail.
The cadence covers the full scope of an operations manager's regular work: reading who did what on the site (Audit Log), confirming the site can recover from a loss event (Backups), verifying that connected systems are still talking to SGEN (Integration health), and subscribing to platform-level signals before they become user-facing incidents (Status). It also covers the monthly stakeholder report — compiling operational data from these four surfaces into a summary your leadership team can read in two minutes.
This guide does not teach you how to build pages, manage blog content, configure ad campaigns, or write code. Those tasks belong to other roles. Use the role table at the end of this guide to identify who to route each type of request to.
Good use cases
- You are newly assigned as operations manager for a SGEN site and need a clear starting scope.
- Your team is onboarding a new operations manager and wants a single, complete handoff doc.
- You are auditing your own practice and want to confirm you are reviewing the right signals on the right cadence.
- Your leadership team wants a monthly operational health report and you need to know which SGEN screens supply the data.
- A content team reports a blocker (a form stopped sending, an integration returned errors, a backup did not run) and you need to know whether it falls inside your scope or requires escalation to a developer or vendor.
- You are running an escalation drill to confirm your runbook is current before an actual incident occurs.
What NOT to use this for
- Do not use this guide to author or publish content. Blog posts, page edits, popups, and form design are owned by your content and marketing counterparts. See Content editor onboarding and Marketing manager onboarding for those workflows.
- Do not use this guide to diagnose or fix code-level issues. If an integration is failing because of a misconfigured API key, a webhook endpoint returning server errors, or a broken theme script, route that to your developer. Your role is to detect the failure and escalate it — not to fix the code.
- Do not use this guide to make brand or design decisions. Creative direction, typography, and visual design belong to your designer. Custom CSS and Custom Codes belong to your developer.
- Do not use this guide to manage billing or site provisioning. Those tasks belong to your platform admin. See Platform admin onboarding.
How this connects to other features
- Read the Audit Log — your operational evidence trail. Every admin action — content edits, user role changes, integration toggles, settings changes — writes a row here. Weekly review keeps you ahead of unauthorized changes.
- Activate and verify backups — your recovery confidence. A backup schedule you cannot verify is not a backup strategy. Monthly verification confirms the last run completed and that the restore point is current.
- Integration health overview — your dependency map. Every external system connected to your SGEN site has a status indicator and a last-sync timestamp. A silently failing integration is the most common operational blind spot.
- Platform status and notifications — your early-warning system. Subscribe here to receive platform-level alerts before your users report an outage.
- Manage users list — your access-control surface. Role assignment and revocation are operational events — new starters need the right access from day one, and departures need it removed on the day they leave.
- Add or edit a user — the individual account edit form. Use this during onboarding, role changes, and offboarding events.
What success looks like
After one month on this cadence, a healthy operations manager practice in SGEN looks like:
Weekly: You can open the admin → Audit Log and confirm no unauthorized admin actions occurred in the past seven days — in under five minutes. Any anomaly (unexpected role change, settings edit from an unrecognized session, bulk content action) surfaces immediately rather than weeks later. Your integration list shows green status indicators across the board, or you have an active escalation ticket for any that are not.
Monthly: You produce a one-page stakeholder report in under two hours, pulling data you already collected during the four weekly cadence sessions. The report covers: last-backup timestamp, integration uptime summary, audit-log anomaly count, and user-access delta (accounts added and removed). Your escalation runbook has been drilled — every contact reached, every response path confirmed — within the past 30 days.
Incident response: When a content team reports a blocker, you can classify it as operational (yours), technical (developer), or vendor (escalate externally) within 15 minutes. You do not fix things outside your scope — you route them, with enough context for the resolver to act without a follow-up call.
Permissions: You have never needed to access Theme Editor, Custom Codes, or Blog to resolve an operational issue. If you have, a scope boundary needs clarifying with your administrator.
A representative monthly health snapshot — all backups verified, integrations stable, no unresolved audit anomalies, and user access current — looks like this:
What to do if it does not work
Audit log shows a gap — records are missing for a date range. Audit log entries are written at the point of each admin action and are not retroactive. If a range shows no entries, it may mean no admin actions occurred during that period — which is normal over weekends or low-activity periods. If you expected activity (a content team was publishing, an integration was toggled) and the log is empty, ask your administrator to confirm your account has read access to all audit-log categories. Some enterprise configurations scope audit access by role. See Read the Audit Log for filter and category instructions.
A backup did not run on its scheduled date. Go to the admin → Backups. Check the Last run column for the affected schedule — a failed or skipped run shows a warning indicator. First, confirm the schedule is still active (status shows On). If the schedule is active and the run still failed, your administrator needs to check storage quota and SMTP alert configuration. A failed backup with no alert means your notification routing is also broken — resolve both together. See Activate and verify backups for the manual trigger and schedule-edit workflow.
An integration shows a red status indicator but no error message. Go to the admin → Integrations, find the affected integration, and check the last-sync timestamp. A red status with a stale timestamp (more than 24 hours for a daily-sync integration) indicates the connection was lost without a recovery alert. Your first action is to log the timestamp and integration name, then check whether the vendor's own status page reports an outage. If the vendor is healthy, the problem is in your SGEN credentials or webhook configuration — route to your developer with the integration name, last-sync time, and any error text visible in the detail panel. Do not attempt to reconfigure the integration yourself without developer guidance. See Integration health overview for the detail panel and error-log access.
Your escalation contact is unreachable. During a live incident, an unreachable escalation contact is a runbook failure, not a new problem. Your escalation runbook should include at least two contacts per vendor and one internal fallback (platform admin or site owner). For SGEN-platform issues specifically, open a support ticket at the admin → Support with the incident description and the timestamp of first detection. For vendor-side issues, escalate using the vendor's support portal — most enterprise connectors have a status-based SLA path you can invoke. See Platform status and notifications for how to access the SGEN support channel from inside the admin panel.
The operational dashboard is slow or shows stale data. Go to the admin → Backups or Integrations and attempt a manual refresh using the reload control at the top of the list. If the screen continues to show stale data after a reload, it may indicate a platform-level performance event. Check the admin → Settings → Notifications to confirm you are subscribed to platform alerts — if a maintenance window is in progress, a banner should be visible. If no maintenance notice is shown and the slowness persists for more than 15 minutes, open a support ticket with a screenshot of the affected screen and the current timestamp.
Weekly cadence — site-health sweep
Once a week — Monday mornings work well for most operations managers — complete a four-part site-health sweep. Budget 30-45 minutes. The goal is to detect anomalies, verify dependencies, and confirm the operational baseline before the content team's week begins.
Steps — weekly site-health sweep
1. Review the audit log for the past seven days
Go to the admin → Audit Log. Set the date filter to the past seven days. Scan for any of the following signals: a role change you did not initiate, a settings edit outside your change-window, a bulk delete action, or an admin session from an unrecognized IP address.
Most weeks the audit log is quiet — a handful of content-publish events, a form-settings edit, a user login. A healthy Monday-morning snapshot — seven days of routine editorial activity with no anomalies — reads like this:
If you spot an anomaly — a settings change from an unrecognized user, a role escalation you did not approve, a bulk-delete action — note the row details (user, timestamp, area, action) and escalate to your platform admin immediately. Do not attempt to reverse the change yourself without confirming the intent with the responsible user first. See Read the Audit Log for category-filter and export instructions.
2. Check integration status across all active connections
Go to the admin → Integrations. Scan the status column for every row. A green indicator means the integration completed its last scheduled sync. A yellow indicator means the last sync completed with warnings — click the row to read the warning detail. A red indicator means the integration failed its last sync and requires action.
Record the last-sync timestamp for every integration flagged yellow or red. This timestamp is your primary evidence when opening a vendor support ticket or briefing your developer.
A healthy integration panel — six active connections, all green, last synced within the expected window — reads like this:
If any integration is in error state, follow the troubleshooting path in the What to do if it does not work section above. See Integration health overview for the detail panel and error-log access.
3. Verify backup status
Go to the admin → Backups. Confirm the most recent backup run completed successfully. Check the Last run timestamp — for a daily schedule, the most recent run should be less than 24 hours ago. For a weekly schedule, the most recent run should fall within the past seven days.
If a run is overdue or shows a failed status, log it immediately and escalate to your platform admin. Do not wait for the next scheduled run to confirm whether the failure was a one-time event.
See Activate and verify backups for the manual trigger and schedule-verification workflow.
4. Confirm notification subscriptions are active
Go to the admin → Settings → Notifications. Confirm your operational email address is still listed as a recipient for platform-status alerts and backup-failure alerts. Notification settings are occasionally reset after a platform update or settings migration. Catching a missing subscription during a routine sweep is far better than discovering it after an outage you were not notified about.
See Platform status and notifications for the notification-settings path and alert category descriptions.
Monthly cadence — stakeholder report and escalation drill
At the start of each month, block two hours. This is the session where you look back at the full prior month of operational data, compile a stakeholder report, and run a lightweight escalation drill.
Steps — monthly deep review
1. Compile the audit-log summary for the prior month
Go to the admin → Audit Log. Set the date filter to the full prior month. Export the log as CSV. Tally the following counts from the export: total events, events by category (Content / Settings / Users / System), and any rows you flagged as anomalies during the four weekly sweeps.
Your monthly stakeholder report needs four numbers from this tally: total events, settings-change count, user-role-change count, and anomaly count. If anomaly count is greater than zero, include a one-sentence description of each and its resolution.
A clean April — 152 total events, four settings changes, two role changes, zero anomalies — reads as a pass.
2. Verify backup history for the prior month
Go to the admin → Backups. Review the run history for the full prior month. Count the number of scheduled runs, successful runs, and failed runs. For a daily backup schedule, a clean month shows 28-31 successful runs and zero failures.
Your monthly report needs three numbers: scheduled count, successful count, and failure count. Any failure requires a one-line explanation and the remediation action taken (for example, "Run failed 2026-04-14 due to storage quota; quota increased same day; confirmed clean run 2026-04-15").
A clean April backup record — 30 scheduled runs, 30 successful, zero failures — reads like this:
3. Review integration uptime for the prior month
Go to the admin → Integrations. For each active integration, check whether any red or yellow status indicators were recorded during your four weekly sweeps. Compile a table: integration name, status for the month (Healthy / Warning / Error), and resolution note if applicable.
Your monthly report needs this table. A stakeholder reading the report needs to see at a glance that all integrations are operational — or that a specific one experienced an issue and it was resolved within your SLA window.
4. Compile user-access delta for the prior month
Go to the admin → Users. Review the Users list and cross-reference against your prior-month baseline. Note any accounts added, any accounts deactivated or moved to Trash, and any role changes.
Your monthly report needs three numbers: accounts added, accounts removed, and role changes. This delta is your operational evidence that access is tightly controlled — no stale accounts, no unintended escalations.
If you discover accounts that should have been removed but were not, escalate to your platform admin immediately and include the finding in your report. See Manage users list for the bulk-action controls and Add or edit a user for individual role changes.
5. Run the monthly escalation drill
An escalation drill takes 15 minutes and prevents a 15-hour incident. Once per month, go through your escalation runbook contact by contact. You do not need to simulate a real incident — a quick message or email confirming that the contact is current and reachable is sufficient.
For each contact in your runbook, confirm:
- Name and role are still current.
- Primary channel (email or phone) reaches a live inbox or line.
- Backup contact is also reachable.
- The scope of escalation they own is still accurate (for example, if your CRM vendor changed their support tier, your runbook escalation path may have changed too).
If any contact is stale, update the runbook immediately. Log the drill completion date in your monthly report.
6. Assemble and distribute the stakeholder report
Your monthly stakeholder report draws entirely from the five steps above. A complete monthly report covers six items in approximately one page:
- Backup status: scheduled vs. successful runs, any failures and resolutions.
- Integration health: uptime table for all active connections.
- Audit log summary: total events, settings changes, role changes, anomaly count.
- User access: accounts added, removed, role changes.
- Escalation drill: completed or skipped, contacts current or stale.
- Outstanding items: anything escalated during the month that is still open.
Distribute the report to your site owner, your technical lead, and any leadership stakeholders who have requested operational visibility. Keep a copy in your operations folder for the following month's comparison.
Things you should NOT need access to
The cadences above cover your complete operational scope in SGEN. The following areas are explicitly out of your lane — if someone routes a ticket to you that requires access to these surfaces, it belongs to a different role.
You should NOT need access to:
- Theme Editor — visual design, typography, layout. Route to your developer or designer.
- Custom Codes — injecting HTML, CSS, or tracking scripts. Code-level changes require developer access.
- Blog and Content areas — editorial publishing, page editing, media library. Route to your content editor or marketing manager.
- Popups and Forms (authoring) — creating or editing popup overlays and lead forms. Route to your marketing manager. Note: you may review form notification settings in Settings → Email as part of an escalation — that is within scope.
- Billing and site provisioning — subscription management, domain setup, plan changes. Route to your platform admin.
You DO need access to:
| Feature | What you do | Reference |
|---|---|---|
| the admin → Audit Log | Weekly review, anomaly detection, monthly export | Read the Audit Log |
| the admin → Backups | Weekly status check, monthly history review, manual trigger on failure | Activate and verify backups |
| the admin → Integrations | Weekly health sweep, escalation on error | Integration health overview |
| the admin → Settings → Notifications | Confirm subscription, update routing on role change | Platform status and notifications |
| the admin → Users | Role assignment on onboarding, revocation on offboarding | Manage users list |
If you find yourself needing access to something not in the table above, flag it to your administrator before acting. Scope creep in admin access is the most common source of accidental site-wide changes.
Examples
Example 1: Weekly audit-log sweep reveals an unexpected settings change. Alan opens Audit Log on Monday morning and spots a row from Friday 15:44 — "Settings edited · SMTP host updated · by admin@yourteam.com." He does not recognize this as a planned change. He checks with the platform admin and confirms it was a legitimate credential rotation after the email provider updated their outgoing server. Alan logs the event as Explained in his weekly notes and updates the escalation runbook to include a heads-up protocol for settings changes so they are pre-announced before they appear in the audit log. No action required — but the detection happened within 72 hours instead of weeks. See Read the Audit Log for category-filter and user-search instructions.
Example 2: Monthly drill reveals a stale integration-support contact. During the May escalation drill, Alan sends a test message to his Mailchimp support contact and receives an automated bounce — the contact left the vendor six months ago. He finds the current escalation path in the Mailchimp support portal, updates his runbook, and notes the correction in the monthly stakeholder report as a runbook hygiene finding. The drill took 15 minutes. A future Mailchimp outage — now routed correctly — resolves in hours rather than days.
Example 3: Content team reports a form integration that stopped sending to CRM. Katherine, the marketing manager, reports that HubSpot stopped receiving form submissions three days ago. Alan opens Integrations, finds HubSpot in a yellow-warning state with a last-sync timestamp from three days prior. He captures the timestamp, the warning message ("API rate limit exceeded — 429 response"), and routes the ticket to his developer with all three data points. He does not attempt to reconfigure the API credentials himself. The developer updates the rate-limit handling in the integration settings within two hours. Alan logs the detection-to-resolution timeline in the monthly report as: detected Monday 09:15, escalated Monday 09:22, resolved Monday 11:44. See Integration health overview for the detail panel and error-log access.
Day-one and first-week path
Use this table on your first day to establish the operational baseline before running your first weekly cadence session.
| When | Action | Expected outcome |
|---|---|---|
| Day 1 — morning | Open the admin → Audit Log, set range to last 30 days | You have a baseline of admin activity before your tenure |
| Day 1 — morning | Open the admin → Backups, confirm a schedule exists and last run is current | You know the recovery posture before your first week |
| Day 1 — afternoon | Open the admin → Integrations, read the full list and status indicators | You have your integration inventory — note any yellow or red rows |
| Day 1 — afternoon | Open the admin → Settings → Notifications, confirm your address is subscribed | Platform alerts will reach you before users report an issue |
| Day 2 | Draft your escalation runbook — integration vendor contacts + internal technical lead | You have a written escalation path before you need one |
| Days 3-5 | Run the full weekly cadence solo — audit log, integrations, backups, notifications | You complete one full sweep within your first week |
| Week 2 | Brief your site owner on any findings from the first sweep | You establish the reporting relationship and confirm scope expectations |
| Week 4 | Run your first monthly deep review and escalation drill | You produce your first stakeholder report and confirm your runbook is live |
Other roles on this site
Each role on a SGEN site has its own onboarding guide. Use the table below to understand who owns adjacent surfaces — and who to route requests to when something falls outside your operational scope.
| Role | What they own |
|---|---|
| Content Editor | Blog posts, pages, media library, comment moderation |
| Marketing Manager | Analytics, lead forms, popup campaigns, blog publishing cadence |
| Ecommerce Manager | Orders, products, coupons, and fulfillment cadence |
| SEO Specialist | SEO audit grid, redirects, robots.txt, Search Console |
| Developer | Custom CSS, Custom Codes, tracking scripts, integration configuration |
| Support Agent | Read-only admin lookups, ticket triage, escalation paths |
| Platform Admin | Site provisioning, user management, billing, SMTP settings |
| Partner / Agency | Multi-client delivery, white-label, reseller billing |
Related reading
- Read the Audit Log
- Activate and verify backups
- Integration health overview
- Platform status and notifications
- Manage users list
- Add or edit a user