Team lead SGEN onboarding guide
| Field | Value ||---|---|| Audience | public || Page type | guide || Area | _workflows/role-onboarding || Updated | 2026-05-25 |How to onboard as a team lead in SGEN
This guide is your operating playbook as a team lead using SGEN. Your role sits one rung below admin — you coordinate a team of authors, editors, and contributors, own the editorial cadence and the quality bar, and hand off to your admin for permission changes, billing decisions, and final publishes on plans that require it. You do not configure the platform. You configure the people using it.
The guide covers what you do before your first team member logs in (setup), what you do every week (cadence), and what you do when something breaks (troubleshoot). Each section links to the relevant reference doc for the feature it covers — follow those links when you need field-level detail.
Before you start
Before your first session as team lead, confirm the following with your site admin:
- Your account is assigned the Editor role at minimum.
Team leads typically hold Editor access — enough to review, edit, and publish content on behalf of the team. If you need to approve and publish content on behalf of authors, confirm with your admin that your role allows it.
- You can open Users and see your team members listed.
If the Users screen shows an access error, your admin needs to grant you read access to the user list.
- You can open Audit Log and see recent team activity.
If the log is blank or access is denied, your admin needs to confirm your role permissions.
- At least one Template exists for the content type your team produces — blog post, page, or both.
Templates are how consistency holds without your daily intervention. If none exists, create one before your team starts writing.
- Notification emails are routed to your address for every team submission.
Go to Settings → Notifications (or ask your admin to) and confirm your email is on the receive list for new content submissions.
If anything above is missing, share the relevant sections of this guide with your admin before you onboard your first team member.
Where to go
Your primary areas inside the SGEN admin panel:
| Area | What you do there |
|---|---|
| Users | See your team, confirm their roles, surface access issues to admin |
| Audit Log | Track who did what — edits, publishes, deletions, logins |
| Notifications | Confirm submission alerts are reaching you |
| Templates | Maintain the starting shapes your team writes into |
| Calendar | Hold the publish cadence — what goes out and when |
| Blog / Pages | Review drafts, QA before publish, co-publish with authors on training runs |
You do not need to visit Settings (beyond notification routing), Custom Codes, Theme Editor, or Billing. Those surfaces change how the platform works at a structural level — they are your admin's territory.
What is this for
This doc is a role-scoped operating guide for a team lead at a SGEN site. It answers three questions: how do you set your team up correctly, how do you hold the quality bar week to week, and how do you troubleshoot when the system breaks down.
The guide is grounded in a real team scenario — a content team at a mid-size business on SGEN with five contributors (two Authors, two Editors, one Contributor) and a weekly publishing cadence of three pieces. The team lead is Marcus. His job is to make sure content ships on schedule, meets the quality bar, and stays off the admin's desk for everything within the team's scope.
Good use cases
- You are taking over an existing team and need to understand which SGEN areas are yours to manage.
- You are building a team from scratch and need to know the right sequence — invite, assign, train, run.
- You want a single document to hand a new team lead in place of an ad-hoc walkthrough.
- You need to explain to your admin what you can action yourself versus what needs escalation.
- You are auditing your current team setup and want to confirm roles are correct and the audit log shows healthy distributed activity.
What NOT to use this for
- Do not use this guide to configure account-level settings. Billing, SMTP credentials, integrations, and site-wide Settings are your admin's territory. Escalate; don't improvise.
- Do not use this guide to make brand identity or design decisions. Typography, colour palette, logo — those decisions belong to your designer or founder. Your Templates should reflect the agreed design, but the design itself is not yours to change.
- Do not use this guide if you are the site admin. Admins have full access and a different scope. See the Platform Admin onboarding guide for the admin-level operating playbook.
- Do not use this guide to manage platform infrastructure. Server config, Custom Codes, and SG-Builder global settings are developer or admin territory. If a content problem seems to require a code change, escalate it.
How this connects to other features
- Add or edit a user — the form you use to invite team members and the form your admin uses to change their roles when you escalate.
- Manage users list — your team roster; use it to confirm active accounts, spot stale ones, and surface deactivation requests to your admin.
- Browse the Audit Log — your visibility into team activity; every edit, publish, deletion, and login leaves a row here.
- Configure notification emails — submission alerts that reach you without you polling the draft queue manually.
- Browse and use templates — the starting shapes your team writes into; consistent templates mean consistent output without your intervention on every piece.
- Editorial Calendar — the publish schedule your team runs against; a visible cadence reduces missed deadlines and coordination overhead.
What success looks like
After four weeks running this cadence, a healthy team-lead practice in SGEN looks like:
Week 1: Every team member is invited, has the right role, and has published at least one piece through the full invite → draft → review → publish loop.
Week 2: The audit log shows activity from every team member — no one is invisible, and no one is doing work in the wrong area. Notification emails are arriving and you are clearing them within 24 hours.
Week 4: You have not been the last person to touch every published piece. Authors are writing, Editors are reviewing, and you are catching structural problems (wrong template, missing section, off-brand claim) — not copy-editing individual sentences.
Monthly: You can walk your admin through a one-paragraph team-health summary — who shipped, who is stuck, what role changes are needed — without leaving SGEN.
A healthy team snapshot at the end of a four-week onboarding window looks like this:
What to do if it does not work
A team member cannot do their job — access error or missing action. Go to Users, find their account, and check the Role field. Authors cannot publish — they can only submit drafts. If an Author needs to publish, your admin needs to change their role to Editor. Share Add or edit a user with your admin when you escalate so they know exactly what needs to change.
Notification overload — too many emails, wrong emails, duplicates. Go to Settings → Notifications and review which events are routed to your address. If you are receiving submission alerts from areas outside your team's scope, ask your admin to scope the routing. Alternatively, set up a dedicated email filter to separate team submissions from platform-level alerts so your review queue stays clean.
Missed publishes — content is drafted but not going live. Open the Calendar and cross-reference against the Blog or Pages draft queue. A missed publish usually means one of three things: the author did not mark the draft ready, the Editor who was meant to review it did not act, or the publish date in the Calendar does not match the actual status in Blog. Run through the checklist in the Weekly cadence section below to reset the cadence.
Quality drift — content is shipping but the bar has dropped. Quality drift is a training problem, not a permissions problem. Go to Audit Log and look at which pieces were published without an Editor review step — content that went from Author → Published without an intermediate Edit event. Run a training pass with the relevant author using the onboarding loop in the First-week path section below.
The audit log shows no activity from a specific team member. No activity usually means one of three things: the account exists but the member has not logged in yet, the member is working in a different area than expected, or the account has been deactivated. Go to Users, find the account, confirm it is active, and follow up with the member directly. If the account shows active but still shows no audit log rows, ask your admin whether the account's role allows the actions you expect them to be taking.
Setup — build your team before the first deadline
Get this right before the first piece enters the queue. A team that starts without clear role assignments and a live cadence spends the first month firefighting structure instead of shipping content.
Steps — team setup
1. Invite each team member
Go to Users and use the Add New button for each team member. Fill in their name, email address, and role before sending the invite. Do not invite everyone at once and set roles later — the role determines what the member sees the moment they log in for the first time.
The team structure Marcus is building — two Authors, two Editors, and one Contributor — looks like this before anyone has logged in:
See Add or edit a user for the invite form fields and the role selector.
2. Assign the right role to each person
Roles in SGEN determine access at the action level — who can draft, who can edit, who can publish. Assign roles based on what each person does, not who they are seniority-wise.
| Role | Can do | Cannot do |
|---|---|---|
| Editor | Draft, edit, publish, review others' drafts | Manage users, change site settings |
| Author | Draft and submit their own content for review | Edit others' drafts, publish, access users |
| Contributor | Draft content in their own queue | Submit for review without team lead approval, publish |
If someone needs to publish on behalf of the team, they need Editor. If someone is primarily producing content for others to review and publish, Author is correct. If someone is a part-time contributor whose work always gets reviewed before it goes near the publish button, Contributor is appropriate.
Do not over-assign Editor because it is the most capable role. Every Editor can publish immediately — if your quality bar depends on a review step, give Authors the Author role, not Editor.
3. Set up notification routing
Go to Settings → Notifications and confirm submission alerts are configured to reach you. As team lead, you need to know when a draft is submitted for review before it sits in the queue unread for three days.
Notification routing at the team-lead level has two practical settings:
- Submission alerts — you receive an email when an Author submits a draft. Route these to your primary inbox, not a shared alias.
- Publish alerts — you receive an email when any piece is published. Use these for QA, not awareness. If a piece publishes that you did not review, that is a process gap, not a notification problem.
See Configure notification emails for the event types and routing fields.
4. Confirm your template library
Go to Templates and confirm the content types your team produces each have a starting template. A blog post template should contain the required sections (intro, body, summary, call to action), the correct formatting defaults, and placeholder text that signals where images and pull quotes go.
If no template exists, create one from a recent piece that met your quality bar. Strip it back to structure only — no client-specific copy, no campaign-specific headlines — and save it as the team default.
A well-structured template library covering the three content types the team produces:
See Browse and use templates for how to create, edit, and set team defaults.
How to run your first training pass
The training pass is the single most important step in the setup sequence. It is a guided run through the full workflow — draft → submit → review → publish — done together with a new team member before they work independently.
Skip it and the first production failure teaches the lesson instead.
Steps — training pass with a new hire
1. Assign a practice piece
Give the new team member a low-stakes brief — a short blog post, a simple page section, or a placeholder content update. The brief should be real work, not a "for training" exercise, but it should be short enough to complete in one session.
Marcus runs the training pass with Nadia (Author) on a brief to update the team blog intro post. The piece is real, already exists in draft form, and takes about 45 minutes end to end.
2. Walk through the draft-to-submit flow together
Watch the team member open the blog or pages editor, select the correct template, draft the content, and submit it for review. Do not touch the keyboard — ask them to narrate each step out loud so you can catch confusion before it becomes a pattern.
Common points of confusion for new Authors:
- Not selecting the template first and starting from blank
- Saving as Published when they mean to submit for review (Authors cannot publish, but if the role is set to Editor by mistake, they can)
- Uploading images before the alt text has been agreed
3. Run the review step yourself
When the draft lands in your notification email, open it, review it against the quality bar, and either return it with comments or advance it toward publish. Show the team member where your feedback appears and how they action it.
If you are using a QA checklist, run through it visibly so the team member sees the criteria. The checklist does not need to be long — four items covers most teams: correct template used, required sections present, images have alt text, no client names in placeholder copy.
4. Publish the practice piece together
If the piece clears the quality bar, publish it together. If you are an Editor, you can do this directly. If your plan requires admin approval for final publish, walk through the escalation path so the team member knows how that step works.
After publishing, open the Audit Log and show the team member their own activity — the draft creation, the submission, the review, the publish — as a single thread of events. Seeing their own work in the log is a useful anchor for understanding how team activity is tracked.
See Browse the Audit Log for filtering by user, action type, and date range.
5. Debrief and set the independent standard
After the training pass, run a 10-minute debrief. Ask the team member: what was unclear, where did you hesitate, what do you need before working independently. Capture any gaps and resolve them before the next piece enters the queue.
At the end of the debrief, confirm three things:
- They know which template to use for which content type.
- They know the difference between Save as Draft, Submit for Review, and Publish (and which applies to their role).
- They know how to reach you when a piece is ready to review — email notification, direct message, or a shared calendar entry on publish day.
Weekly cadence — hold the bar without touching every piece
Once the team is set up and through at least one training pass each, your job shifts from hands-on to supervisory. Budget 60-90 minutes per week for the cadence below.
Steps — weekly team review
1. Open the audit log and scan team activity
Go to Audit Log. Set the date filter to the last 7 days. Scan for two things: activity from every team member, and any action that looks out of place (a publish by someone who should not be publishing, a deletion without a matching replacement).
A healthy week — distributed activity across all five team members, no unexpected publishes or deletions:
If a team member shows no activity for the week, follow up before the next weekly check. See Browse the Audit Log for user and action filters.
2. Check notification email clearance
Open your inbox and confirm you have actioned every submission notification from the past week. A submission sitting unread for more than 48 hours is a missed deadline waiting to happen.
If notification volume is high enough that things are slipping through, route submission emails from each author into a dedicated folder and review that folder at a fixed time each day. The problem is almost never notification volume — it is notification routing.
3. Review the calendar against actual publishes
Go to Calendar and look at the current week's planned publish dates. Cross-reference each planned publish against the Blog or Pages draft queue. For each planned piece: is it drafted, has it been submitted for review, and has it been approved?
A piece planned to publish on Friday but still sitting in draft on Thursday morning needs immediate attention. Either the author is behind and needs a nudge, the piece needs to be rescheduled, or it needs an accelerated review turnaround. Do not let Friday come and go without a resolution.
4. Run a quality spot-check on one published piece
Pick one piece published this week — ideally one that went through review without your direct involvement — and read it against the quality bar. You are looking for three things: correct template structure, brand voice consistency, and no content that should have been escalated (off-brand claims, missing legal disclaimers, references to unreleased product features).
If the piece misses any of the three, note which author submitted it and which Editor approved it. Run a targeted feedback conversation with both before the next weekly check. Do not wait until the monthly review to surface quality drift — by then it has compounded.
5. Surface any escalations to admin
Collect anything from the week that requires admin action: role changes needed, a user account that should be deactivated, a template that needs a platform-level update, a notification routing change. Send one consolidated escalation per week rather than individual requests. Your admin gets a clearer picture and acts faster on a list than on a stream of single-item asks.
Monthly cadence — team health and cadence reset
At the start of each month, block 90 minutes. This is where you look at the prior month's output as a whole and make decisions about the team structure, the cadence, and the quality investment.
Steps — monthly team health review
1. Count output against the planned cadence
Pull the Blog and Pages published lists and filter to the prior month. Compare the actual publish count to the planned cadence.
If the planned cadence is three blog posts per week, a month with four publishing weeks should show 12 posts. If the actual count is 9, three deadlines were missed. Find the three pieces: are they published late, still in draft, or abandoned?
2. Review audit log distribution
Go to Audit Log, set the date range to the prior month, and filter by each team member in turn. You are checking for two things: balanced contribution across the team, and no team member who appears to be doing more than their share of the review and publish steps.
An imbalanced audit log — two members doing 80% of all actions — is a signal that the role assignments or the workload distribution needs adjustment. Raise it in the monthly escalation to admin if role changes are needed.
3. Assess template health
Go to Templates and check whether the team's templates have drifted from the current quality bar. Templates decay — a template built six months ago may no longer reflect the approved format. Update any template that would produce a piece you would not approve as written.
If a new content type has emerged this month that does not yet have a template, create one before the next month's content enters the queue.
4. Prepare the team health summary for admin
Produce a one-paragraph summary covering: team output versus cadence, role gaps identified, escalations pending, and any structural changes recommended for the next month. Share it with your admin before the next planning cycle.
This keeps your admin informed without pulling them into the day-to-day. It also builds a paper trail of the team's operating status — useful when making the case for additional headcount or a role upgrade.
Things you should NOT need access to
The cadences above are your complete scope in SGEN as a team lead. The following areas are explicitly out of scope — if someone asks you to make changes here, the request should go to your admin.
You should NOT need access to:
- Settings (beyond notifications) — billing, SMTP, integrations, and platform-wide defaults belong to your admin. If a Settings change is needed to unblock your team, escalate it.
- Custom Codes — injecting or editing HTML, CSS, or scripts has platform-wide consequences and requires admin access. Never be in this screen as a team lead.
- Theme Editor — typography, layout, and visual design are not team-lead territory. If a piece of content requires a design change, that is a separate workstream with your designer or admin.
- Billing and subscriptions — plan tier, seat counts, and invoice details are admin-only. If your team needs more seats, escalate the request; do not attempt to action it yourself.
You DO need access to:
| Feature | What you do | Reference |
|---|---|---|
| Users | View your team roster, surface role issues to admin | Manage users list |
| Audit Log | Track team activity, spot anomalies, verify training pass results | Browse the Audit Log |
| Notifications | Receive and action submission alerts from Authors | Configure notification emails |
| Templates | Maintain starting shapes for all team content types | Browse and use templates |
| Calendar | Hold the publish cadence and catch deadline slippage early | Editorial Calendar |
| Blog / Pages | Review drafts, QA after publish, co-publish on training runs | Create and manage blog posts |
If you find yourself needing something not in the table above, raise it with your admin before taking action. Scope creep in admin access is the most common source of accidental platform-wide changes.
Cross-area coordination — marketing, blog, and SEO
Team leads on a SGEN site often sit at the intersection of three distinct content streams: the editorial blog, the marketing surface (landing pages, campaign pages), and SEO-driven content (pillar pages, clusters, redirects). Your job is not to own all three — it is to keep the handoffs between them clean.
The table below maps the common coordination points and who owns the action on each side:
| Coordination point | You do | Adjacent role does |
|---|---|---|
| Campaign brief → content | Translate the brief into a structured template and assign to Author | Marketing manager provides brief, confirms messaging |
| SEO keyword brief → blog post | Assign keyword brief to Author with the correct template, set publish date in Calendar | SEO specialist provides keyword brief and target URL |
| Blog post → SEO | Confirm the post is published to the correct URL before the SEO specialist submits for indexing | SEO specialist submits URL and tracks indexing status |
| Content publish → landing page update | Notify marketing manager when a referenced post is live so landing page links stay current | Marketing manager updates the landing page link |
| Quality flag on published content | Note the flag, route the edit to the responsible Editor, log it in your weekly escalation | Admin or SEO specialist confirms when the correction is live |
The coordination points above are the places where content team work touches adjacent roles. When a handoff breaks — a campaign brief that never becomes a brief, a post that publishes to the wrong URL — the fix is almost always a clearer process at the coordination point, not a role change.
Examples
Example 1: Author submits a draft using the wrong template. Nadia submits a blog post, but the notification email shows the piece is formatted as a landing page — she selected the wrong template. Marcus opens the draft, sees the structure is off, and sends it back with one comment: "Wrong template — use Blog Post Standard, not Campaign Landing Page." Nadia re-drafts from the correct template and resubmits. On the second submission the piece is structurally correct and advances to review. Marcus notes in the monthly review that Nadia is the second Author to make this mistake — the template names are too similar and need disambiguation. He updates the template names before the next month's queue opens.
Example 2: An Editor publishes a piece without a team lead review. Marcus's Monday audit log scan shows a piece published by Leo (Editor) that was not on the calendar and did not appear in his notification inbox. The piece is live and correct — no content problem — but the process was skipped. Marcus has a direct conversation with Leo: pieces that are not on the calendar need team lead clearance before publish. Leo was not aware this was the rule. Marcus updates the team onboarding notes to make it explicit.
Example 3: A team member goes two weeks without audit log activity. Theo (Author) shows no audit log rows for two weeks. Marcus checks Users and confirms the account is active. He reaches out directly — Theo has been working in a shared Google Doc and did not know he was supposed to be drafting in SGEN. Marcus runs a short training session on the draft workflow, and Theo's first SGEN-authored piece lands in the review queue the following day. The audit log starts showing activity.
First-week and first-month path
Use this table to track progress through the team onboarding sequence.
| When | Action | Expected outcome |
|---|---|---|
| Day 1 — morning | Invite all team members with correct roles pre-assigned | Users list shows 5 Pending accounts |
| Day 1 — afternoon | Confirm notification routing reaches your inbox | Send a test submission and verify receipt within 5 minutes |
| Day 1 — afternoon | Confirm template library covers all three content types | Templates list shows Blog, Landing Page, Case Study |
| Day 2 | First training pass with one Author | One piece goes through full draft → submit → review → publish loop |
| Days 3-4 | Training pass with remaining team members in pairs | All 5 members have at least one Audit Log entry under their name |
| Day 5 | Run Week 1 audit log check | Every member shows activity; no anomalous publishes or deletions |
| Week 2 | Run full weekly cadence solo | Audit log scan, notification clearance, calendar cross-reference, quality spot-check, escalation list |
| Week 4 | Complete monthly team health review | Output count vs cadence, audit log distribution, template health, admin summary |
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 team's scope.
| Role | What they own |
|---|---|
| Marketing Manager | Analytics, forms, popups, and blog campaigns |
| Content Editor | Blog posts, pages, media library, comment moderation |
| SEO Specialist | SEO audit grid, redirects, robots.txt, Search Console |
| Ecommerce Manager | Orders, products, coupons, and fulfilment cadence |
| Developer | Custom CSS, Custom Codes, tracking scripts, SG-Builder Additional CSS |
| 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
- Add or edit a user
- Manage users list
- Browse the Audit Log
- Configure notification emails
- Browse and use templates
- Editorial Calendar
- Create and manage blog posts