Support Innovation Group (SIG)

Support Innovation Group

SIG connects the Support team with IT and Product teams, to make sure we have the right tools and improvements to do our jobs well. We identify opportunities, define what we need, validate solutions, and help the team adopt what gets built.

SIG and Support Ops (IT) work in close partnership —

• SIG vets and approves all requests before anything moves forward
• Support Ops will not take requests directly from individuals in Support — all requests go through SIG first.
• SIG and Support Ops will align on a shared roadmap and objectives each cycle.

The Intake Process

This section has been created to help simplify the process, help to understand the Role of the SIG team Lead, as well as the SIG Team members:

Intake Request is made (through the SIG Intake Request Form)

1. Change Request (if it’s a change to existing processes)
2. Project Request (if it’s a big ask that needs to be started, not currently existing, requires subtasks)
3. AI Tooling Request (creating agents, aligning tools)

The SIG Team Lead works with Support Leadership around prioritization of SIG Requests. The Priority is based on What’s in Process, and What’s up Next. The Slack Channel #spt_leadership_internal will be used to request the prioritization. We will set priority based on R.I.C.E Scoring on a weekly list, and ask if changes need to be made.

SIG Team Members will:

• Self-select Requests to work on based on the SIG Issue Board (Rather than being Assigned).
• SIG Team members will only own up to a max of 3 items at one period of time.
• Managers will engage with direct reports (SIG Team Members) to make sure projects move forward.
• Will work the issue with Managers across Leadership to find a solution
• Act as a Reviewer (not the solver). The SIG Team members’ job is to make sure the right questions are asked, and send anything unclear back to the Requestor (who is the DRI) for clarification. It is NOT the SIG Team members’ job to fully flesh out the idea or drive the solution themselves.
• Get Leadership approval for the item they are assigned to.
• If a Solution is required, Open a Feature Request (FR) with CSS (Customer Support Systems).
• Once Leadership approves, (if they approve ) move the item to “Approved (Ready for Release) Label status.

From there, the SIG Team Lead will get involved, and work with CSS on the Roadmap/Capacity Planning.

The SIG Team Lead is responsible for Messaging, and Communications.

What Counts as a Valid SIG Request?

A valid SIG request addresses a digital or tooling challenge that is strategic in scope, scalable in impact, and requires cross-functional delivery. It should relate to systems, automations, AI, workflows, reporting, or integrations that power Support’s work — and demonstrate meaningful impact on core KPIs such as handle time, CSAT, deflection, or backlog.

Valid requests align to one or more of SIG’s strategic epics, including automation & AI adoption, self-service expansion, engineer efficiency, customer experience, management reporting, cross-organizational collaboration, or third-party integrations. They require involvement from IT, Engineering, Product, or external vendors to design, build, and ship.

Critically, a valid SIG request is framed as a problem to solve — not a pre-defined solution — with clear articulation of impact and measurable success criteria. Requests that are narrowly scoped to a single team, lack strategic alignment, or can be resolved without cross-functional effort are out of scope for SIG.

What would be an Invalid SIG Request?

A request is out of scope for SIG if it is purely local, operational, or people-focused with no digital or tooling component. This includes staffing and scheduling asks, training and enablement items covered by existing programs, one-off configuration fixes, or standard feature and bug requests that belong in Product or Infra backlogs.

Requests that are too vague to define impact or success criteria — or that benefit only a single individual or small team — are equally out of scope. If it can be solved with a SOP, a training module, or a routine ticket, it’s not a SIG request.

EXAMPLE

This is a valid SIG request if:

• It is about digital tools, automation, AI, reporting, or integrations used by Support.
• It impacts many engineers or customers, not just one person or case.
• It is framed as a problem with clear impact and success criteria, not just a vague idea.
• It aligns with at least one SIG strategic epic (automation, self-service, portal, efficiency, CX, reporting, integrations).

This is Not a valid SIG request if:

• It is about staffing, scheduling, or people management.
• It is a training/enablement ask without a tooling change.
• It is a one-off bug or configuration issue that should be fixed through normal operational channels.
• It lacks a clear problem statement, impact, or alignment to SIG epics.

Project Links and Resources

• Technical Requests
• SIG Projects
• Support Team Meta Work Items
• NOVA - Next Gen Operations & Virtual Agents

SIG Support Team Members

SIG Support team members will:

• Be the voice of Support. SIG members aren’t just helpers — they are the people who spot what’s broken, what’s slow, and what’s missing from the day-to-day support experience. Their input shapes what gets built and prioritized.
• Validate solutions before we roll out to the wider team. You will be the ones who get to say “this works” or “this needs to change” before everyone else is affected.
• Build visibility. Working in SIG puts SIG members in front of cross-functional stakeholders — IT, Support Ops, leadership. For support engineers who want to grow, this is a meaningful way to contribute beyond tickets.

SIG Resources

• Support Innovation Group Slack Channel

View page source - Edit this page - please contribute.