Assemble support

Overview

While it is hoped your time with Assemble will be trouble free, issues can occasionally occur. Support is built right into the Assemble application, allowing users to search online help and raise issues directly to the Assemble support team or, if configured, to your in-house support team for first line support.

Assemble support's core hours are 09:00-17:30 Mon to Friday excluding UK public holidays. Turnaround on issues is dependent on their severity and impact, but we pride ourselves on our support responsiveness and service.

If you have concerns or questions on the support process please contact the support manager or your account manager for more information.

Raising an issue

For more information on raising an issue with Assemble support please see Reporting a bug

To raise an issue either press "Submit a request" at the top right of this page, or "Support" then "Contact Us" from the bottom of any Assemble application screen

Triage

All new issues are quickly triaged by the support team and assigned an appropriate severity. This allows removal of issues that are “how do I?” or enhancement requests, which are managed through a separate process to system issues.

Severity is judged on a couple of factors: the impact on the system at a technical level, and the impact on the customer’s business. Some examples are given below to assist in the understanding of the priority process used by the Assemble support team when assigning a severity to an issue:

System: High

System impact is generally decided by the Assemble support team. High issues will typically have no workaround, affecting main system functions and/or large numbers of users.

A main function would be the volunteer portal, rota system, news feed or similar being inaccessible. i.e. a single report would not be classed as high, but the reporting platform being unavailable would.

System: Low

Issues with a workaround and/or affecting only a limited number of users or features. More cosmetic than impacting on day-to-day use. Examples include a rarely used report with a fault, non-impacting but erroneous errors displayed or single user issues.

Business impact: High

Business impact will typically be decided in conjunction with the customer. High impacting issues would relate to multiple users (as with system impact), but also taking into account potential damage to the customer's reputation such as branding problems, incorrect information being displayed, etc.

Business impact: Low

Low impact issues will relate to single users or functions that are rarely used. For example, incorrect fonts on internal reports, single user unable to log in or use a feature, etc.

Triage

Once the impact on both system and business is known a severity will be assigned as summarised below.

Final severity will be agreed between the support team and the affected user, based on the guidance above. Severity is not fixed, but will always be adjusted to reflect the current situation. Thus an urgent ticket may be downgraded should a suitable workaround be found, or a high may become urgent if found affecting more users than initially thought.

Fix releases

Severity 4 (urgent) issues where the problem is code based will have a target of a hotfix release within the current sprint where possible. Hotfixes to resolve an issue are used for short-term emergency fixes only, and subject to limited testing and release directly to production as shown below:

Hotfix release path: Resolved ⇒ Test (Combined unit & integration test) ⇒ Production (Live deployment)

Hotfixes will be subsequently reviewed/superseded through the standard ongoing development cycle and patch release process.

Severity 3 (high) or severity 2 (normal) issues will be assigned into the current/next sprint and follow our standard agile patch release process:

Patch release path: Resolved ⇒ QA Environment (Unit test) ⇒ Development Environment (Integration testing) ⇒ Helpdesk ticket close (advise affected customers) ⇒ Staging (Acceptance testing) ⇒ Production (Live deployment)

Severity 1 (cosmetic) issues will be placed on the next available sprint with space to accommodate (via the backlog). Timings will be dependent on existing development priorities and open issues, as higher priority work will be completed in preference to completion of these problems.