Custom Solutions (Pre-)Sales Flow

Driver

Based on the 2024/2025 strategy understanding with VSHN’s End-to-End Solutions and Product Business Areas, we need clarity on the process—from initial request through identifying a fitting solution, to selling and implementing it once ordered by a customer.

This page describes the flow for selling Solutions and how it differs from selling (or enabling self-service of) VSHN standard products.

Summary

Sales (including Account Managers) own a Sales Opportunity (in Odoo). When the Opportunity goes beyond selling a standard product or assisting with self-service, we enter the Solution Business of VSHN. Here it is crucial to first understand the customer’s business and technical requirements and constraints, design and document a fitting solution, collaboratively decide to offer it, and then proceed with the offer.

Once ordered, the implementation must be planned in Epics (Jira) as part of the customer project. Ownership, transparent information flow, and clarity are key to ensuring we sell the right solution that can be delivered on time and evolve over time, while managing both customer and VSHN expectations.

solution sales flow.drawio

General Guidelines and Rules

  • “Sales Roles” include Account Management and anyone in a (temporary) sales function.

  • Sales must not make binding offers beyond VSHN standard products (AppCat, APPUiO, OpenShift) without going through the Solution Offering flow. Cost estimates are okay, but must be clearly indicated as such.

  • Tender submissions always require the Solution Offering process.

  • We avoid designing solutions in chat; all information must be recorded in the SA Task in Jira or linked wiki page.

  • An SA task must not be assigned to a Solution Architect (or other VSHNeer) who is not regularly part of SA coordination meetings.

  • If a request created by a Sales Role is urgent (within 1 week), ping #solution-architect with a link to the SA task.

  • If not otherwise specified in the SA task, Sales Role expect a first answer (at least who owns the SA task) within a day after the coordination meeting.

  • SA tasks in Jira are ISMS-internal (the classification); never use them for communication with external parties. The Solution Design (for example Wiki page, once good enough) can be shared with the customer, if there are no ISMS-internal contents left (for example VSHN strategy or PM considerations)

Technical Support for Sales

Whether as part of a solution offering or ad hoc, Sales Roles may need technical support in meetings with (potential) customers. The Solution Architect role (multiple) is available to assist, while ownership of the Sales Opportunity remains with the Sales Role.

  1. Sales Role creates a "SA Sales Support" task under SA-206 - SA Sales Support. Describe the Opportunity and your expectations in 1–3 sentences and link to the Opportunity in Odoo.

  2. Solution Architects assign the task during their coordination meetings, which typically occur twice weekly.

General Information Requests from Sales

Sales Roles may need to quickly assess whether a Sales Opportunity is strategically relevant or get a rough estimate of the potential solution and costs. These are not binding offers and cannot be submitted as such to the customer.

  1. Sales Role creates a "SA Sales Support" task under SA-206 - SA Sales Support. Include a short summary of the Opportunity.

  2. Solution Architects review the task during coordination meetings. A Solution Architect, PO, or PM will respond via a comment in the SA task.

Solution Offering

When a Opportunity becomes more concrete, we begin the proper process to develop a solution design we can offer and, ideally, sell.

  1. Sales Role maintains the Opportunity in Odoo.

  2. Sales Role creates a "Case" task under SA-1 - Cases, including at minimum a summary of the business and technical needs, the deadline, and a link to the Opportunity in Odoo.

  3. Solution Architects assign the task and next steps during coordination meetings.

  4. Assigned Solution Architect provides feedback in the SA task. If not otherwise specified in the SA task, Sales Role expect an answer within a day after the coordination meeting.

    1. This often involves coordinating Requirements Engineering calls with the customer.

  5. Once requirements are clear, the Solution Architect:

    1. Develops the Solution Design and collaborates with Sales on pricing.

    2. Checks strategic alignment, pricing model, and team capacity (see Strategy and Sales Coordination).

  6. Once the Solution is designed and okay to offer, the Sales Role:

    1. Creates the offer in Odoo; Solution Architect supports.

    2. Fills out tender documents or similar processes; Solution Architect supports.

    3. Sends the customer an email (or other form of presentation) with the offer, solution design, and other needed information.

    4. Usually schedules a call to present the solution and offer; the Solution Architect supports and can be invited to the call for this.

  7. During negotiations and any evolving requirements, the Solution Architect supports the Sales Role.

  8. If the Opportunity is won (ordered):

    1. Sales Role comments in the SA task.

    2. Solution Architect creates Epics and initial tasks in Jira for implementation and coordinates with relevant POs on timeline planning. See Customer Project Management.

  9. If the Opportunity is lost:

    1. Sales Role comments and closes the SA task.

Strategy and Sales Coordination

To ensure alignment between Solutions designed by Architects, Sales Roles, and VSHN’s strategy and team capacities, the decision to offer a solution does not lie with either role independently. Any offering beyond standard products or simple extensions must be collaboratively reviewed.

Coordination happens asynchronously via Sales Coordination Chat or ideally during the weekly Sales Coordination Meeting.

Sales Coordination Meeting

When and what

  • Time: Every Tuesday, 10:00–10:45 (remote-only via Zoom).

  • Agenda: Sales Coordination Weekly.

  • Items are reviewed one by one. The item owner decides when their topic is done. Others may raise objections, which we qualify and address collaboratively.

Follow-up

  • The task owner remains responsible for follow-up and implementing any action points agreed upon during the meeting.

Preparation

This should be automated via Jira status/label filters.

Check if participation is needed

  1. The Meeting Host organizes the agenda to minimize required participation, completing this by Monday 14:00 and notifying participants via chat.

  2. All potential participants (Product Owners, Product Manager, Solution Architects, Account Managers, and Sales) must review which items they need to attend:

    1. If not needed, they skip the meeting but must remain reachable during the slot. This is not optional.

    2. If unavailable, they must inform the Meeting Host and arrange a briefed stand-in.

All times are in Zurich time.