Let's get started!
We recognise how critical fast, effective Customer Support is to resolving issues quickly and ensuring you get maximum value from Service Geeni.
This article explains:
When and how to contact Support.
What information to provide.
How tickets are managed.
When requests are escalated to Development.
How to escalate effectively when business impact increases.
Support Hours & Contact Details
Support Hours: 08:45 – 17:15, Monday to Friday
Contact:
Phone: 0330 088 0802 (Option 1).
Email: [email protected]
Support Portal: https://service-geeni.atlassian.ne
When Should I Contact Support?
Contact Support when you require assistance with:
1. Troubleshooting Problems
The system is not behaving as expected.
You need help identifying a solution.
2. Resolving Issues
Performance issues.
Errors or bugs within the platform.
3. Guidance & Assistance
Product best-practice advice.
System setup or configuration.
Data changes.
General questions on using functionality.
Support SLAs
Here is how the Support SLAs are broken down:
Metric | Average |
Response Time | 30 minutes |
Time to Resolution | 50 hours |
Severity Levels
Severity | Description | Example Impact |
Severity 1 – Critical Incident | No system access or the system is completely down. Requires immediate escalation to Development Triage. | Users cannot log in, and core services are unavailable. |
Severity 2 – Major / High Impact Incident | Global issue or significant business impact, e.g. inability to invoice or transact. | Invoicing is blocked across the business. |
Severity 3 – Moderate Incident | Tasks or functionality within a specific module are impaired; however, a workaround is available. | One workflow is broken, but an alternative process exists. |
Severity 4 – Minor / Low Impact Incident | Minor functionality issues or non-critical data impacted. Typically, cosmetic concerns or discrepancies. | UI display issues, small data inconsistencies. |
Support Stages & Resolutions
Below is a breakdown of the various stages and resolutions within the Support journey.
Stage | Description |
Triage | New requests are reviewed, categorised and given a Severity. The agent confirms all required information and attempts to resolve. |
Further Investigation | The issue could not be resolved during triage and requires deeper investigation. |
In Progress | The ticket is actively being progressed by an agent. |
Development Escalation | The issue requires a software release, code change, bug fix, performance investigation or complex data corrections. |
Quote Required | Chargeable work is required (e.g. data sweeps, branding/document changes, training). |
Close / On Customer Test | The agent believes the ticket is resolved and is awaiting customer confirmation before closure. |
Working Effectively with the Support Portal
You can use the Support Portal to:
General (Technical Support): You can log a support request by contacting the team.
Feedback: Provide feedback on how the system is performing, for example.
Help Tickets: Monitor support requests: Review the status of current Support Requests and update or respond to agent feedback.
Status Page: View Uptime data and availability of Service Geeni servers and services.
How to Raise a Support Request
Well-defined requests avoid unnecessary delays and requests for further information.
To raise a support request (ticket):
Access the Support Portal and raise a new ticket via the General section.
Complete the Form: Provide as much detail as possible. Clear, concise information ensures quicker resolution.
Best Practices
Best Practices to follow when raising a request:
Area | Why It Matters |
Clarity of Request | Enables the agent to progress without needing further clarification. |
Communicate Business Impact | Ensures correct Severity and Priority are applied. |
Monitor the Support Portal | Allows you to respond quickly to agent queries and prevent delays. |
Correct Use of Escalation | Ensures changing impact is recorded correctly, and appropriate action is taken. |
Example:
Escalating a Request to Development
Support will escalate your request when:
Code Change / Bug Fix: Fix requires a software release. Releases are fortnightly and subject to QA.
Performance & Infrastructure: Monitoring identifies platform-wide performance issues.
Complex Data Corrections: Specialist data sweeps or corrections are required.
Change Requests / New Features: Suggestions are passed to Product for roadmap review.
The Development Process
Development work is typically triggered through one of four routes:
Change/feature requests.
Performance & infrastructure.
Complex data issues/corrections.
Code change/bug fix (requires a software release).
Each route follows a slightly different path, but they all align to the same principles:
Capture impact
Assess Severity
Triage appropriately
Schedule work (based on priority and release planning).
1) Change/feature requests
Change requests are suggestions or improvements to functionality (rather than a fault that needs fixing).
Process:
Collect details: We gather information to understand the requirement and the business impact.
Log for consideration: The request is recorded for review and future planning.
Review against the Product Roadmap: Requests are regularly reviewed alongside the current Roadmap to assess their suitability and value.
Added to Roadmap (where appropriate): If the request provides value to Customers and the Product, it is added to the Roadmap for future consideration and prioritisation.
2) Performance & infrastructure
Performance and infrastructure items relate to platform stability, reliability, and speed.
Process:
Raise the concern / identify the issue: Input may come from Support investigations, monitoring tools, or customer feedback.
Triage: The issue is reviewed to confirm symptoms, scope and impact.
Progress the work: Work is moved to In Progress for investigation and improvement actions.
Decision point – does it require a code change?
If no, it proceeds as a data correction task and is progressed to resolved.
If yes, it moves to the Requires code change route (see section 4).
Resolved: Once improvements have been applied and verified, the work is marked as resolved.
3) Complex data issues/corrections
These relate to specialist data changes, corrections, or updates that require more in-depth technical handling.
Process:
Raise the data issue: Support gathers the required information (what needs changing, where, and why).
Triage: The request is reviewed to confirm the required correction and the impact.
Decision point – does it require a code change?
If no, it proceeds as a data correction task and is progressed to resolved.
If yes, it moves to the Requires code change route (see section 4).
Resolved: Once the data correction is completed (and validated), the request is closed.
4) Code change/bug fix (requires a software release)
This route applies when a fix or change cannot be completed without a software release.
Process:
Triage: Findings from Support investigations are reviewed, along with Severity and business impact.
Schedule: The work is reviewed in line with release planning and allocated to a release cycle based on:
Current workloads.
Severity
Business impact.
In Progress: The ticket is assigned to the appropriate team for further investigation (if required), and the fix/change is applied.
Review: The code change/fix is reviewed by a Team Lead before being passed to QA.
QA: The change is added to a QA release for full testing. Only with QA's approval can the release be scheduled.
Fix released: The release is scheduled to be made live, and release notes are communicated to confirm included fixes/improvements.
Feedback & CSAT
Your feedback is very important to us!
We'll ask for feedback after each Support request is resolved to identify improvement areas and monitor the impact of the changes made.
These stats are reviewed regularly.
All feedback is reviewed and discussed with the Team and Management. Concerns or complaints are addressed immediately. Where changes or improvements are made, this will also be communicated.
Customer Escalations
If the business impact increases or you believe the Severity or Priority should change, request a Customer Escalation.
This ensures all impact details are reviewed, and the correct resources are applied.
Example:
Escalation Pathway
When escalating, there are five levels:
Level | When to Escalate |
Customer | Issue unresolved, and the impact has increased. |
Team Lead / CSM | Ongoing concerns or deteriorating experience. |
Support Manager | Significant or persistent concerns. |
Head of Support & Customer Success | Escalating business impact. |
Chief Customer Officer (CCO) | Critical unresolved issues. |
Key Escalation Contacts
Team Lead: Mike Fox.
Support Manager: James Goulbourne.
Head of Support & Customer Success: Erika Goldman.
Chief Customer Officer: James Lawson.
Thank You!
Support Terminology
Support Term | Explanation |
Severity (Sev) | Key criteria used to determine internal prioritisation, SLA and resource. |
Priority | Impact on Customer. |
Support Request (SR) | Support required to troubleshoot, ask for advice/assistance or to report an issue/bug. Each request is assigned an individual ticket number. |
Request Types | Categorisation of support requests for reporting and to ensure the correct workflow and resource is applied to resolve. |
Support Resolution | The ticket has been progressed through the Support process to a conclusion. |
Bug | An error, flaw, or fault in a software program that causes it to produce incorrect or unexpected results or to behave in unintended ways. |
UI/UX | The “user interface” of the Product/how it looks and the “user experience” – ease of use/workflows. |
Config | Specific functionality that can be enabled/disabled, if required. |
SLA | Service Level Agreement – measures and targets for service. |
Patch | A software update is designed to fix bugs, improve performance, or add new features to an existing program. Patches are essential for maintaining software security and functionality. |
Cache | A storage layer that saves copies of frequently accessed data to speed up subsequent requests. Clearing the cache can sometimes resolve performance issues. |
Error Log | A file that records events and messages generated by software applications or the operating system. Log files are often used for troubleshooting and analysing software behaviour. |
Audit Log | A chronological record of system activities. Includes records of system accesses and operations performed in a given period. |
Support Portal | Where all support resources can be accessed, and requests raised and viewed. |
WebApp or Tenant | Individual Customers’ instance of the software application. |
Support Ticket Statuses
Status | Explanation |
New | A new request and ticket number have been raised. |
Triage | The ticket is being reviewed, categorised and severity assigned. Initial investigations were carried out and resolved, if possible. |
Under Review | Further investigation is required and will be assigned to an agent based on Severity & Priority. |
Customer Responded | Customer update on ticket needs reviewing. |
Waiting for Customer | Additional information or action has been requested. Waiting for the Customer to respond. |
Work in Progress | The ticket is assigned and being worked on by an Agent. |
Quote Required | The request relates to chargeable works and has been passed to Professional Services to quote. |
Escalated to Dev | Further assistance is required from the Development team. |
On Customer Test | Agent believes ticket resolved and has requested confirmation from the Customer. |
Pending Closure | Ticket is resolved and will be closed in 7 days. |
Closed | Ticket is closed and can no longer be updated. |
Planned | Issue is ready to be worked on when a Developer has capacity. |
Dev in Progress | Ticket is being reviewed, categorised and severity assigned. Initial investigations carried out and resolved, if possible. |
Dev Done / Waiting for Review | Code change/fix has been done and waiting for signoff by Dev Lead. |
Dev Done / Waiting QA Deployment | Team Lead has signed off and is waiting to be deployed into next QA release. |
QA in Progress | Currently in Test on the latest QA release. |
Ready for Release | Resolution has passed QA testing and will be released with next Software Release. |
Released | Latest release has been made “Live”. |