7. Getting Help & Escalations 

Available Tools & Resources

Before logging a support request, please consult these primary resources to confirm expected behaviour:

• Workstreams Documents: Navigate to your Workstream/Project/Success job and click the Documents tab: Review the latest functional specifications and approved design documentation. Note this links to the files within your Project/Job Google Drive Folder.
• Avidly APAC Knowledge Base: Access project-specific guides and FAQs created by our team.
• HubSpot Knowledge Base: Refer to HubSpot’s official documentation for standard platform functionality queries. Also check out the HubSpot Help Centre for access to the HubSpot Academy, Community and advanced resources.
• Your Internal Team: Cross-reference data discrepancies or process questions with your internal stakeholders.

How to get help or escalate

For standard functional defects or questions, please log a ticket within our Project Management platform. Ensure you include specific steps to reproduce the issue, relevant screenshots, and details of the user account being used

If you encounter a 'blocker' issue that completely halts or significantly slows down the testing progress, please log the ticket in the Workstreams platform and immediately contact your Avidly Project Manager ideally via phone to escalate.

‘Blocker’ Examples

• Testing is blocked.
• Multiple testers are impacted.
• Critical business processes are impacted.
• Security or legal risk.
• UAT timelines or go-live are at risk.
• Critical defects remain unresolved.

Escalating Blocker Items

An important thing to note when Escalating a Blocker is this will remove key delivery people from resolving other items - slowing down the resolution process.

Before escalation please confirm that you have validated the issue:

• Reconfirm test steps and expected results
• Check UAT guidance, knowledge base, and project documentation
• Confirm access, roles, and test data are correct
  
  

---

UAT Triage Process with SLAs

Priority Levels

Status	Description
P1 Critical	Core functionality is blocked with no workaround, preventing essential testing or usage. Any delay in resolving this issue directly places the scheduled go-live.
P2 High	Major functionality is impaired or difficult to use, but a workaround exists. These must be resolved before launch to ensure a viable solution.
P3 Medium	Noticeable functional or visual issues that do not stop the user from completing their task. These can be fixed if budget permits otherwise it can be competed in future enhancements.
P4 Low	Minor cosmetic inconsistencies, typos, or small layout glitches. These can be deferred post-launch.

UAT SLAs by Priority Level

All times are calculated in NZT working hours.

Priority	Assigned (Client Triaged > Assigned)	Resolution (Assigned → Resolved)	Verification (Resolved → Verified)
P1 Critical	1 Hour	4 Hours	2 Hours
P2 High	4 Hours	2 Business Days	4 Hours
P3 Medium	2 Business Days	5 Business Days	2 Business Day
P4 Low	3 Business Days	Best Effort	3 Business Days

Service Terms & Conditions

• Resolution Targets
   
  The times listed for resolution are performance targets rather than strict guarantees. Complex issues or those with external dependencies may require longer to address. We will communicate revised timelines immediately if a fix is expected to exceed the standard allowance.
• UAT Period Applicability
   
  These SLAs apply exclusively during the agreed UAT period when a dedicated support team is active. Issues raised before or after this window are not subject to these response times.
• Escalation Outside UAT
   
  For any P1 or P2 items identified outside the dedicated UAT period, please telephone the Avidly Project Manager directly to ensure immediate visibility and action.

---

Warranty Period

Triage Process with SLAs

During the 30-day warranty, priorities shift to focus on live commercial impact and stability.

Priority Levels

The live site is unavailable, or a core commercial function (e.g., payment, lead capture) has failed. Immediate action is required to prevent data loss or reputational damage.

Warranty Triage SLAs by Priority Level

All times are calculated in NZT working hours.

Service Terms & Conditions

• Scope of Warranty
  This period covers the repair of defects existing within the agreed scope of the original project. Requests for new features, design changes, or functionality not previously specified will be classified as 'Change Requests' and estimated separately.
• Deployment Schedule
  To maintain stability, Low and Medium priority fixes may be grouped into a single weekly patch release rather than deployed immediately upon resolution.
• Emergency Escalation
  For P1 Critical issues occurring outside standard NZT business hours, please follow the dedicated major incident process provided in your handover pack.

---

Change prioritisation

UAT and testing will surface:

• Defects that must be resolved
• Enhancements or new ideas that are optional
• Scope clarifications that may require a change request

Only approved changes may be included in the current release. The primary objective during UAT is MVP not to introduce new features or enhancements.

Change Capture & Classification

Defects will be recorded and managed the defect management process

All non-defect items must be logged as a Change Request (CR) and classified as one of the following:

• Regulatory or Compliance: Required to meet a legal, regulatory or compliance obligation
• Business Critical: Required to support core business operations or prevent a material operational failure
• Quality Improvement: Improves usability, performance or reliability without changing the core functionality
• Enhancement: Introduces new or expanded functionality beyond the agreed requirements

Each Change Request must include:

• A clear description of the requested change
• The business justification
• The users or processes affected
• The urgency of the change, including whether it is required now or can be delivered later

Impact Assessment (Required)

Each Change Request must be assessed across four areas, with the impact rated as Low, Medium or High.

Budget Considerations:

• Development effort
• Testing and rework
• Project management and solution-design effort
• External vendor, technology or licensing costs

Timeline Considerations:

• Impact on UAT completion
• Risk of delaying go-live
• Impact on downstream activities and dependencies
• Additional time required for testing and approval

Quality and Risk Considerations:

• Risk of regression
• System stability and performance
• Security or data-integrity risks
• Complexity introduced into the solution

Scope Considerations:

• Whether the change is included in the agreed requirements
• Whether it expands or changes the agreed MVP
• Whether other requirements, processes or deliverables will also need to change

Impact should be rated Low / Medium / High.

---

Pre-Launch vs Post-Launch Decision

Pre-Launch Inclusions

A change should only be considered for inclusion before launch when it:

• Is required for regulatory or compliance purposes
• Is critical to core business operations
• Removes a genuine blocker to go-live
• Prevents a material operational, security, financial or reputational risk
• Cannot be managed through an acceptable temporary workaround

Including a change before launch may require an adjustment to the project budget, timeline or scope.

Post-Launch Deferral

Changes should generally be deferred to a post-launch improvement release or Phase 2 when they relate to:

• Usability improvements
• Nice-to-have enhancements
• New or expanded functionality
• Non-blocking process changes
• Items for which an acceptable workaround is available

Changes will be prioritised based on:

• Business impact and the consequences of not delivering the change
• Regulatory, operational, security or reputational risk
• Availability and suitability of a workaround
• Delivery effort compared with expected value
• Alignment with the agreed scope and project outcomes
• Impact on the approved budget and go-live date

Rule of thumb: If the change is not required for compliance, does not prevent core business operations and does not block go-live, it should be deferred.

Project Manager Recommendation

The Project Manager will provide a documented recommendation for each Change Request:

• Approve for the current release
• Defer to a post-launch release or Phase 2
• Reject

The recommendation must include:

• A summary of the business need
• The budget, timeline, quality and scope impacts
• The risks of approving or deferring the change
• Any available workaround
• The required trade-offs across time, cost, quality and scope

The final decision must be made by the authorised project stakeholders and formally recorded before the change is scheduled or implemented.

---

Daily summary

During the UAT period a Daily Summary of UAT Feedback item progress is sent to client project stakeholders.

Note that reports are only provided during UAT periods.

The summary includes the following information: