'Services' Pipeline Stages Overview
This article outlines the stages within the 'Services' pipeline of HubSpot and their intended use cases.
High-Level ‘Service Request’ Pipeline Workflow at a glance
The following is a high-level summary of the stages in the typical ‘Service Request’ pipeline workflow:
New (TSCS round-robin, assumed ownership)
Tickets created manually from zoom calls will automatically be set to ‘New’ at Ticket Creation unless the stage/status is updated otherwise.
Emails will autogenerate tickets to appear in this stage/status in the ‘Service Request’ pipeline, and the round robin will kick off for all ‘Available’ TSCSs, assigning a ‘Ticket Owner’ automatically.
Triage (TSCS initial intake/troubleshooting)
TSCSs will move tickets from the ‘New’ stage/status to this stage/status to conduct initial intake/troubleshooting.
Service Authorization (TSCS confirming customer service authorization before moving a ticket to ‘TSA Required’)
TSCSs will move tickets from the ‘Triage’ stage/status to this stage/status after initial intake/troubleshooting/monitoring has been conducted and there is a need for TSA intervention and potential dispatch.
Quote Pending (TSAs requesting quotes from contractors, TSCSs communicating with customers for approval)
TSAs will move a ticket to this stage/status and remain in ownership of the ticket while communicating with contractors when requesting quotes.
TSCSs will move a ticket to this stage/status and remain in ownership of the ticket while communicating with customers on pending quotes to gain approval.
TSA Required
If ‘Yes,’ TSCS moves ticket to this stage/status and TSA assumes ownership, replacing their name as ‘Ticket Owner.’
If ‘No,’ TSCS moves the ticket to ‘Final Review,’ re-reviewing before resolving the ticket.
TSA Triage (TSA initial intake/troubleshooting)
If ‘TSA Required’ = ‘Yes,’ the TSA moves the ticket to this stage/status from ‘TSA Required’ after setting themselves as ‘Ticket Owner.’TSA will then either proceed with dispatch or move the ticket to the ‘Final Review’ stage/status after remote adjustments/troubleshooting has been conducted to resolve the reported issue, putting the TSCS back as the ‘Ticket Owner.’
Contractor Sourcing (TSA owns contractor comms, TSCS owns customer comms)
TSA moves ticket into this status from ‘TSA Triage’ if it is determined that a dispatch will be required. Tickets should remain in this stage while sourcing a contractor, creating a WO, and remain in this stage up until the contractor accepts the WO. Once accepted, the TSA moves the ticket to the ‘Dispatch In Progress’ stage/status.
Dispatch Pending (TSA owns contractor comms, TSCS owns customer comms)
TSA moves ticket into this status from ‘Contractor Sourcing’ once the contractor accepts the WO, but the dispatch is not in progress yet. This stage is used when communicating back/forth with a contractor to confirm an ETA to provide to the customer. Once a contractor confirms ETA and the dispatch is in progress, the ticket should be moved out of this stage to ‘Dispatch In Progress.’
Dispatch In Progress (TSA owns contractor comms, TSCS owns customer comms)
TSA moves ticket into this status from ‘Contractor Sourcing’ once the contractor accepts the WO. The ticket should remain in this status/stage until the contractor has left the site. The TSA should then add a note in the ticket including the summary of work, move the ticket to the ‘Final Review’ stage/status and change the ‘Ticket Owner’ field back to the TSCS.
Ordering Parts (TSA owns contractor comms, TSCS owns customer comms)
TSA moves ticket into this status if at any point before/during an ongoing dispatch parts need to be ordered/acquired to proceed with work. The ticket should remain in this status/stage until the parts have arrived onsite.
TSAs will be required to add an ‘On Hold Reason’ when moving tickets to this stage.
Final Review (TSCS assumes/re-assumes ownership)
All tickets should be moved into this stage/status prior to ‘Resolved’ as a best practice to ensure quality assurance/due diligence before communicating the solution to the customer.
Tickets can be moved to this stage/status from any other, but the TSCS should be set as ‘Ticket Owner.’
If a TSA is the ‘Ticket Owner’ when moving tickets to this stage, the TSA is responsible for changing the ‘Ticket Owner’ back to the related TSCS, leaving an internal note with a summary of updates for the TSCS to provide to the customer in resolution.
Closed (TSCS assumes ownership)
Once a ticket has been through ‘Final Review,’ the TSCS will move the ticket to ‘Closed.’
If an inbound response is received on a ticket, the ticket will automatically update to ‘Reopened’ stage/status.
Reopened (TSCS assumes ownership)
‘Closed’ tickets will automatically be updated to this status if an inbound response is received via email on the tickets.
TSCSs are responsible for re-reviewing/re-triaging tickets in this stage/status, moving the ticket to any pipeline stage other than ‘New.’
On Hold (All users)
Tickets can be moved into this status/stage from any other status/stage by any user.
Tickets require an ‘On Hold Reason’ to be saved to put a ticket into this stage.
Tickets exceeding x days in this status will automatically notify the ‘Ticket Owner,’ prompting necessary updates.
High-Level ‘Service Request’ Pipeline Statuses/Stages in detail
Starting in 2025, incoming emails to Technical Services will auto-create HubSpot tickets, routing them to the ‘Service Request’ pipeline. These tickets will show up in the pipeline ‘New’ stage/status and go through a round-robin, auto-assigning a TCSC as ‘Ticket Owner.’
TSCS’s will be responsible for assuming ownership of tickets in the ‘New’ stage timely according to team SLAs, resulting in subsequent triage.
*Known Validations/Requirements
- Manually created tickets will default to this stage unless updated.
- Once a ticket is moved from this stage, it cannot be moved back.
2. Triage
TSCS’s will be responsible for moving tickets into this stage after assuming ownership. This stage should be used for customer intake and initial troubleshooting.
Moving a ticket to this stage will represent TSCS “First Touch.”
*Known Validations/Requirements
- This stage is meant to be used by TSCSs only as TSAs will have their own stage (i.e., ‘TSA Triage’) when/if their involvement is required.
TSCS’s will be responsible for moving tickets into this stage after initial intake, troubleshooting and/or performance monitoring has taken place, and the reported issue has not been resolved. Before any TSA intervention/dispatch can take place, the service authorization from the customer must be confirmed, and it is the TSCS’s responsibility to confirm this with the authorized contact on behalf of the Budderfly site (see FSG for authorized contacts).
Moving a ticket to this stage represents the process of the TSCS gaining service authorization with the customer before transferring a ticket to ‘TSA Required’ for TSA intervention/potential dispatch.
*Known Validations/Requirements
- This stage is meant to be used by TSCSs to confirm service authorization with the authorized contact for the Budderfly site before moving a ticket to ‘TSA Required’ for TSA intervention.
4. Quote Pending
This stage can be owned by TSCSs and TSAs depending on the stage in the typical quote workflow.
TSAS: A TSA will be responsible for moving tickets into this stage when a contractor states that a quote will be provided. The TSA will remain the owner of the quote during this time until the quote is received and converted on Budderfly letterhead, including margins. Once that is completed, the TSA will reassign the ticket back to the corresponding TSCS to begin communication with the customer.
TSCS: A TSCS will be responsible for moving tickets into this stage when a quote has been received and converted on Budderfly letterhead, including margins. The TSCS will own the ticket during this time and begin communication with the customer to gain quote approval.
Please Note: The workflow for quote follow-up with contractors is 5 business days, and the valid period for a quote is 5 business days from the date/time it is sent to the customer.
*Known Validations/Requirements
- This stage is meant to be used by both TSAs and TSCSs to confirm manage quotes with contractors and customers. Quote approval has to be reached with a customer in order to proceed further in the quoting process.
5. TSA Required
TSCSs will be responsible for moving tickets into this stage if TSA involvement is required. L1 Troubleshooting measures outlined in this document should be followed prior to involving a TSA, with the intent of deescalating reported issues, avoiding unnecessary dispatching.
TSAs will be responsible for monitoring tickets in this stage, assuming responsibility by adding themselves as the ‘Ticket Owner.’
*Known Validations/Requirements
- Tickets moved to this stage should not be moved out of this stage until a TSA has been assigned as ‘Ticket Owner’.
6. TSA Triage
TSA’s will be responsible for moving tickets into this stage after assuming ownership. This stage should be used for additional internal intake from TSCS’s and initial technical troubleshooting measures.
Moving a ticket to this stage will represent TSA “First Touch.”
*Known Validations/Requirements
- This stage is meant to be used by TSAs only as TSCSs will have their own stage (i.e., ‘Triage’).
TSA’s will be responsible for moving tickets into this stage after confirming initial technical troubleshooting supports that a dispatch is needed to resolve the reported issue. Tickets should be moved to this stage while sourcing a contractor and should remain in this stage until the contractor has accepted the WO.
*Known Validations/Requirements
- This stage is meant to be used by TSAs only. TSAs will be responsible for all contractor communications during this stage and TSCSs for all customer communications.
8. Dispatch Pending
TSAs will be responsible to move tickets to this stage from ‘Contractor Sourcing’ once the contractor has accepted the WO. This stage is used to confirm contractor ETA to provide to the customer. Once ETA has been confirmed, the TSA adds an internal note on the ticket, providing the TSCS with the information to relay to the customer. Once a contractor confirms ETA and the dispatch is in progress, the ticket should be moved out of this stage to ‘Dispatch In Progress.’
*Known Validations/Requirements
- This stage is meant to be used by TSAs only. TSAs will be responsible for all contractor communications during this stage and TSCSs for all customer communications.
9. Dispatch In Progress
TSA’s will be responsible for moving tickets to this stage once the contractor has accepted the WO and confirmed ETA. Tickets should remain in this stage during dispatch until the contractor has left the site.
*Known Validations/Requirements
- This stage is meant to be used by TSAs only. TSAs will be responsible for all contractor communications during this stage and TSCSs for all customer communications.
TSA moves ticket into this status if at any point before/during an ongoing dispatch parts need to be ordered/acquired to proceed with work. The ticket should remain in this status/stage until the parts have arrived onsite.
In order to place a ticket into this stage, the user will be prompted to select an ‘On Hold Reason’ applicable to parts and select ‘Apply to store changes:
Additionally, TSAs are expected to set a task reminder on each ticket moved into this stage corresponding to the ETA provided pertaining to parts arrival:
*Known Validations/Requirements
- 1. Tickets cannot be moved into this stage without setting an ‘On Hold Reason’.
- TSAs are expected to set a task reminder corresponding to the ETA provided for each ticket put into this stage
- 3. This stage is meant to be used by TSAs TSAs will be responsible for all contractor communications during this stage and TSCSs for all customer communications.
The purpose of this stage is for TSCSs to conduct a” final review” to ensure all measures have been taken to resolve a customer’s reported issue prior to informing the customer and ’Resolving’ the ticket.
Tickets can be moved to this stage from any pipeline stage. In situations where a TSA has been involved and assumed ownership during the ticket lifecycle, the TSA is to update the ’Ticket Owner’ back to the initial TSCS upon moving tickets to this stage, leaving an internal note for the @ mentioned TSCS with a summary of work completed/actions taken.
TSCSs will be responsible for assuming ownership of tickets in this stage, ensuring they are assigned as the ‘Ticket Owner,’ and updating the customer accordingly before moving the ticket out of this stage to ‘Closed.’
*Known Validations/Requirements
- All tickets should be moved into this stage prior to ‘Closed’
- Tickets moved to this stage should not be moved out of this stage until a TSCS has been assigned back as ‘Ticket Owner’.
Tickets should be moved to this stage by a TSCS once a final review has been conducted, assuring that the reported issue has been resolved.
It is best practice for tickets to be moved to the ‘Final Review’ stage and vetted by a TSCS to ensure quality assurance prior to tickets being moved to this stage.
TSCSs will be responsible for assuming ownership of tickets in this stage, ensuring they are assigned as the ‘Ticket Owner,’ and updating the customer accordingly before moving the ticket to ‘Closed.
*Known Validations/Requirements
- Tickets should not be moved into this stage without an assigned ‘Ticket Owner’
- Tickets should not be moved to this stage without being in ‘Final Review’ first
13. Reopened
Tickets in the ’Closed’ stage that receive an inbound response from a customer on a ticket will automatically” reopen” and appear in the ’Reopened’ pipeline stage. Tickets can then be moved out of this stage into any subsequent pipeline stage, other than ’New.’
TSCSs will be responsible for re-assessing tickets in this stage and re-triaging them accordingly.
*Known Validations/Requirements
- Tickets should not be moved to this stage manually.
14. On Hold
"On Hold” is a stage that can be used for a variety of reasons to represent tickets that are blocked or awaiting further support to resolve. A ticket can be moved to this status by any user from any pipeline stage.
In order to place a ticket into this stage, the user will be prompted to select an ‘On Hold Reason’ and ‘Save’:
Ticket durations will be monitored closely in this stage and still require frequent updates to the customer by TSCSs. If a TSA is involved, they will be expected to provide frequent internal updates to support the holding reason/cause for delays.
*Known Validations/Requirements
- Tickets cannot be moved into this stage without setting an ‘On Hold Reason’.
- Tickets exceeding x days in this status will automatically notify the ‘Ticket Owner’, prompting necessary updates.