12. Frontline Support

Frontline Support Overview

The Phase 1 production solution will include an ongoing frontline support model for day-to-day user and operational issues after go-live. 3Wrkz's intent is to satisfy this requirement through a specialized support partner that can provide true 24/7 coverage, while 3Wrkz remains responsible for application ownership, escalations, defect resolution, and higher-level technical intervention when issues move beyond frontline handling.

This allows the support model to combine round-the-clock user coverage with escalation to the delivery organization that built the platform. The result is a practical operating model: routine support requests are handled by a team built for frontline service delivery, while application defects, complex troubleshooting, and code-level issues are escalated quickly to 3Wrkz.

Support Model

The proposed support structure should operate as a coordinated service model with two primary layers:

1. frontline support partner

   A subcontracted support organization will provide first-line support coverage for users, intake of incidents and service requests, basic troubleshooting, call and ticket handling, and routine operational guidance.

2. 3Wrkz escalation and product support

   3Wrkz will maintain a dedicated development and technical team for escalations, defect correction, deeper troubleshooting, and support of issues that require application, integration, data, reporting, or infrastructure expertise.

This structure gives VNA a stable support front door without separating support from the people responsible for the solution itself.

Coverage and Support Channels

The frontline support model will be designed to align with the support expectations reflected in the VNA scope matrix, including:

1. 24/7 support coverage
2. email and phone support
3. a designated support representative or support-management contact
4. self-help materials and user guidance

The support partner would be responsible for maintaining the frontline intake channels and service coverage window. 3Wrkz would remain responsible for the technical escalation path behind that service layer.

Escalation Model

Not every issue should go directly to the development team. The support process should triage issues by type and severity so that routine requests are resolved quickly while higher-risk problems move immediately into the escalation path.

The expected escalation flow is:

1. user issue or service request is received by the frontline support partner
2. frontline support handles routine assistance, access questions, usage guidance, and basic troubleshooting
3. issues requiring technical analysis, defect review, integration investigation, data correction, or release-level changes are escalated to 3Wrkz
4. the 3Wrkz team investigates, corrects, and coordinates resolution as needed across web, mobile, data, reporting, and Azure-hosted components

Severity-based escalation should be defined during final support planning so that production-impacting issues are routed to 3Wrkz immediately rather than waiting in a normal support queue.

Hypercare and Early Production Support

The initial go-live period should include a defined hypercare window with elevated coordination between the frontline support provider, the 3Wrkz implementation team, and VNA operational leadership. During that period, issue intake, triage, escalation, and daily review should be tighter than the steady-state model so the team can respond quickly to production-learning issues.

This early support period should include:

1. heightened monitoring of incident trends and recurring user questions
2. rapid escalation to the 3Wrkz delivery team for production defects or unstable workflows
3. daily or near-daily review of open issues during the initial stabilization window
4. refinement of knowledge-base content and support scripts based on actual user needs

Once the production environment stabilizes, support can move into the normal ongoing operating model.

Ongoing Support Responsibilities

Under the proposed model, the ongoing responsibilities should be split clearly between the frontline provider and 3Wrkz.

The frontline support provider should handle:

1. user intake across phone and email channels
2. first-response troubleshooting and service-request handling
3. ticket creation, routing, and status communication
4. basic guidance for common workflows and known issues

3Wrkz should handle:

1. escalated incident investigation
2. application defects and bug fixes
3. code-level and integration-level troubleshooting
4. reporting, data, and environment-related escalations
5. release coordination when a fix requires deployment

This division keeps the support model efficient without leaving VNA dependent on a generic call center for issues that require real system knowledge.

Knowledge Transfer and Support Readiness

Because the frontline function will be handled by a specialized support vendor, implementation closeout should include deliberate knowledge transfer. The 3Wrkz team should provide the support partner with system orientation, support procedures, issue-routing rules, known-error guidance, and access to user-facing support materials before full steady-state support begins.

That readiness package should include:

1. support runbooks and escalation criteria
2. user guides, quick-reference content, and other help materials
3. issue categorization and ticket-routing rules
4. named contacts for support management and escalation

This reduces the risk of avoidable escalation churn after go-live and helps the frontline provider operate effectively from the beginning.

Support Term and RFP Alignment

The VNA materials clearly require vendor-provided ongoing support, post-implementation support, and 24/7 support coverage. They also require pricing to include ongoing support and maintenance within a five-year total cost of ownership view.

Based on the RFP language reviewed, the clearest support-related requirements are:

1. Vendor-provided implementation, data migration, training, and ongoing support in Section 7
2. 24/7 support coverage, email and phone support, and dedicated support representative in the scope matrix
3. Post-implementation support and go-live support in the scope matrix
4. pricing that includes ongoing support and maintenance and five-year total cost of ownership (TCO) in Appendix A.8

The RFP does appear to require support to be included in the five-year pricing model, but it does not appear to state, in the reviewed language, that VNA must commit to or that the vendor must guarantee a fixed standalone five-year support term under one support contract structure. For proposal purposes, the cleanest position is to describe the support model as available for the full five-year pricing horizon requested by VNA, with final support terms to be reflected in the commercial agreement.