Support & escalation

GLBNXT provides structured support for every organisation running on the platform. Whether your team has a technical question during development, encounters unexpected behaviour in a production application, or needs to escalate a platform-level incident, knowing how support works and how to engage it effectively ensures that issues are resolved as quickly as possible with minimal impact on your team and your users.

This section explains how support is structured, what to expect from each level of support, how to raise and escalate issues, and the responsibilities that sit with your team in the support model.

Support Structure

GLBNXT Platform support operates across three tiers that reflect the nature and urgency of different issue types.

Onboarding Support

During the onboarding period, every new environment has a dedicated GLBNXT onboarding contact who is your primary point of support through the first thirty days. The onboarding contact supports environment orientation, initial configuration questions, first build guidance, and any issues that arise during the onboarding phases described in the Onboarding Overview section.

Onboarding support is the most hands-on level of engagement GLBNXT provides. Your onboarding contact is available for direct communication throughout the onboarding period and can coordinate with GLBNXT's technical and operations teams on your behalf for any issues that require deeper investigation.

After the onboarding period, ongoing support transitions to the standard support channels described below.

Standard Support

Standard support covers the ongoing technical and operational questions that arise during day-to-day development and operation on the platform. Standard support is available to all GLBNXT Platform customers through the designated support channels configured for your environment.

Standard support covers the following categories of request.

Technical questions about platform capabilities, component behaviour, configuration options, and integration patterns. If your team has a question about how a platform component works or how to approach a specific implementation challenge, standard support is the appropriate channel.

Configuration requests for changes to your environment that require GLBNXT involvement, such as adding a new model to your Model Hub, adjusting compute allocation, updating compliance configuration, or modifying identity provider integration settings.

Bug reports for unexpected platform behaviour that affects your applications or workflows. When your team identifies behaviour that appears to be a platform-level issue rather than an application-level issue, a bug report through standard support initiates the investigation and resolution process.

Documentation feedback on gaps, inaccuracies, or areas where the documentation does not adequately address your team's needs.

Incident Support

Incident support covers situations where a platform-level issue is actively affecting your production environment. Platform incidents include service unavailability, significant performance degradation, data access failures, security events, and any other condition that prevents your applications from functioning as expected due to a platform-layer issue.

Incident support is available outside standard business hours for production-affecting events. The contact method and response time commitments for incident support are defined in your service level agreement and communicated during onboarding. Ensure that your team has the incident support contact details available before your first production deployment, not at the moment an incident occurs.

Raising a Support Request

Support requests are raised through the channels configured for your environment during onboarding. Depending on your service tier, these may include a dedicated support portal, a direct email channel, a shared Slack or Teams workspace with your GLBNXT contact, or a combination of these.

When raising a support request, providing the following information at the outset reduces the time required for GLBNXT to investigate and respond.

Environment identifier: confirm which environment the issue affects, particularly for organisations operating multiple environments such as development, staging, and production.

Issue description: a clear description of what is happening, what you expected to happen, and how the two differ. Avoid describing symptoms only. If you have already investigated the issue and formed a hypothesis about its cause, include that hypothesis along with the evidence that supports it.

Reproduction steps: the specific sequence of actions or conditions that produce the issue. An issue that can be reproduced reliably is significantly easier to investigate than one that appears intermittently without a clear pattern.

Timing and frequency: when the issue first appeared, whether it is ongoing or intermittent, and whether anything changed in your environment around the time it appeared, such as a new deployment, a configuration change, or an increase in usage.

Impact assessment: the effect the issue is having on your team, your applications, and your users. An honest impact assessment helps GLBNXT prioritise your request appropriately relative to other open requests.

Relevant logs or error output: any error messages, stack traces, or log excerpts from the platform console or your application that are relevant to the issue. Including this information with the initial request avoids the round-trip of GLBNXT asking for it before investigation can begin.

Escalation

When a support request is not progressing at the pace required by the impact of the issue, escalation is the mechanism for increasing priority and engaging additional GLBNXT resources. Escalation is appropriate when a production-affecting issue has not been acknowledged within the response time committed in your service level agreement, when an issue is taking longer to resolve than the impact justifies, or when you have information suggesting that the issue is more serious than its current priority reflects.

Escalation contacts and the escalation process are defined in your service agreement and communicated during onboarding. The escalation path typically moves from the standard support channel to a named GLBNXT account or operations contact with the authority to prioritise the issue and coordinate the appropriate internal resources.

When escalating, clearly state that you are escalating, why you are escalating, and what outcome you need within what timeframe. An escalation that explains the business impact driving the urgency is more effective than one that simply expresses frustration with the pace of progress.

Incident Communication

For platform-level incidents affecting your environment, GLBNXT communicates through the incident notification channels agreed during onboarding. Incident communication follows a defined pattern.

Initial notification is sent when GLBNXT confirms that a platform-level incident is occurring and affecting your environment. The initial notification confirms that the issue is known and under active investigation.

Progress updates are sent at defined intervals while the incident is open, confirming the current status of the investigation and any actions being taken. Update frequency during active incidents is defined in your service agreement.

Resolution notification is sent when the incident is resolved, confirming what was affected, what caused the issue, and what was done to resolve it.

Post-incident review documentation is provided for significant incidents, covering the root cause, the timeline of detection and response, the impact on your environment, and the actions being taken to prevent recurrence. Post-incident review documentation is typically available within a defined number of business days following resolution.

Responsibilities in the Support Model

Effective support depends on both GLBNXT and your team fulfilling their responsibilities within the model.

GLBNXT is responsible for: responding to support requests within the timeframes committed in your service agreement, investigating and resolving platform-level issues, communicating clearly and promptly during active incidents, maintaining the support infrastructure and channels through which requests are raised, and providing post-incident documentation for significant events.

Your team is responsible for: raising support requests promptly when issues are identified rather than attempting to resolve platform-level issues without engaging GLBNXT, providing the information needed for effective investigation when raising a request, distinguishing between platform-level issues and application-level issues before escalating to GLBNXT, maintaining up-to-date contact information for the people in your organisation who should receive incident notifications, and ensuring that your team knows how to access support channels before they are needed.

The distinction between platform-level issues and application-level issues is worth particular attention. GLBNXT support covers issues originating in the managed platform layer. Issues originating in your application code, your workflow logic, your prompt design, or your data are application-level issues that your team is responsible for investigating and resolving. When the root cause of an issue is unclear, raising a support request to confirm whether the platform layer is involved is always appropriate. GLBNXT will advise on whether the issue has a platform-level component or whether the investigation should focus on the application layer.

Service Level Agreements

Response time commitments, availability targets, and escalation timeframes are defined in your service level agreement. Service level commitments vary by service tier and by the priority classification of each support request or incident. Your service agreement is provided during onboarding and should be reviewed by your team before going into production so that everyone understands what to expect from GLBNXT and within what timeframes.

If your organisation's support requirements are not met by the standard service level tiers, discuss your requirements with your GLBNXT contact during onboarding. Custom service level arrangements are available for enterprise customers and partner deployments with specific support needs.

Self-Service Resources

In addition to direct support, the following self-service resources are available to your team.

This documentation covers platform architecture, solution building, security and compliance, administration, and operational guidance. The documentation is the first place to look for answers to technical questions about platform capabilities and configuration.

The GLBNXT Trust Centre provides security, compliance, and assurance documentation including available certifications, security assessment summaries, and compliance documentation for your team and for your clients or regulators who require evidence of the platform's security posture.

Video tutorials on the GLBNXT YouTube channel provide guided walkthroughs of common platform tasks and solution patterns.

If a self-service resource does not address your question or if you identify a gap in the available documentation, raise a support request. Documentation feedback is welcomed and used to improve the resources available to all GLBNXT Platform customers.