Deciding to Deliver: Sales Offering

Accountable

Atria Team

Lead

Mia Egger

Driver for this Agreement

As we transitioned from building custom Managed Solutions to a more standardized product portfolio, the need to address specific customer needs that don’t yet fit into our offerings has become apparent. As long as it aligns with VSHN’s vision, we are committed to finding ways to deliver, even if it requires customer-specific solutions. We see this as an opportunity to meet customers where they are, truly understand their needs, and use these insights to guide our product development towards actual customer value. This proactive approach can enable us to make informed decisions quickly, enhancing our sales process, driving business growth, and increasing customer satisfaction.

This is the opportunity we see in this, for the driver describing the problems that led to this, see VIP-302.

Summary

Those in contact with the customer to understand their business and technical requirements (see Requirements Engineering), typically the Solution Architect working with the Account Manager or Sales, create an initial draft of what to offer, usually a documented "Solution Design". This might need to include products, services, software, and tooling that we don’t officially offer now in order to fully address the customer’s needs. In a weekly meeting with all necessary Product Owners (not everyone) and the Product Manager, we decide together what we offer, how we offer it, who would build and run it, and what it needs to cost to ensure profitable business. This is the only place and time where we make such decisions, together. Only things that are perfectly clear from product definitions can be sold directly without going into this meeting.

1. Preparation before the Meeting

We prepare topics in an Agenda for the meeting, to a point where we can come up with concrete proposals and decide in the meeting. In respect of our precious time and the effectiveness of the process we don’t discuss unprepared topics - A link to HubSpot, or an initial customer request is not a prepared agenda item.

  1. SAs & Sales prepare the meeting agenda by Friday 17:00, including all relevant information:

    1. Requirements documentation (coming from Requirements Engineering)

    2. What do we already know? Link to:

      1. Solution design (draft, coming from Requirements Engineering)

      2. Which products or teams could contribute?

    3. What do we need to decide?

Check if participation is needed

  1. The Meeting Host reorganizes the meeting slots in a way that the least number of participants need to join by Monday 14:00, informing all attendees via the group chat.

  2. All potential participants (Product Owners, Product Manager, Solution Architects, Account Managers and Sales) are required to check which slots (agenda items) they need to attend:

    1. If there is no reason to join they don’t join, but keep the meeting blocker to be ready to be called in (zoom invite) anytime - they must be reachable. This is a key aspect of this concept, it isn’t optional.

    2. If they can’t attend or are not reachable, they must proactively inform the Meeting Host to decide who can step in. They should also ensure the stand-in is briefed well on the topic before the meeting.

2. The Weekly Meeting

  • Meeting Slot: Every Tuesday 10:00 to 10:45 remote-only via Zoom.

  • Meeting Agendas: in our wiki here.

We go item by item:

  • What can we offer to fulfill the requirements, and how? See How to decide what we offer and how.

  • When could we deliver what? (And by when an offer needs to be signed to be able to keep this date)

  • Who (which team) does what?

  • Estimate one-time effort to offer (and what to do on our side).

  • Define (or at least estimate) recurring costs for unclear products, custom solutions or MVPs.

  • Possible alternatives in case we can’t provide something to still offer a full solution.

We are here with an expectation of not accepting a "we don’t know". If a solution can’t be found right away within the meeting (for example someone else from a team needs to be consulted) we agree on the next concrete action and who will do it and until when when Sales (or who ever represents the Agenda Item) gets the needed answer or input to move forward.

3. Follow-up after Meeting

  1. Solution Architect finalizes design, gives input for offer.

  2. Inside Sales creates the offer.

  3. Sales sends out the offer and follows-up with customer.

Depending on the probability of the deal, the Product Owners might inform their team to not get surprised when we get the order soon.

When the offer gets accepted

  • A (Key) Account Manager is in the lead for the project and organizes the kick-off between all involved stakeholders.

  • We stick to what we decided and documented in the meeting. Small changes can directly be coordinated with the affected Product Owners.

  • If major scope changes occur, we may drag the issue back to the next meeting to revise our decisions and offer whatever the scope change brought up to the customer.

Responsibilities

Function / Role Who

Meeting Host

Mia Egger for Customer Experience Team

Representing Agenda Item

SA, Account Manager or Sales

Representing VSHN Portfolio and Product Pricing

Product Manager

Evaluation of this Process and Meeting

Mia Egger for Customer Experience Team

Representing the Team and Product

Product Owners

Constraints

  • Management must be involved in the decision-making process and qualified objections need to be addressed before offering, if:

    • we are offering something that would require VSHN to change core processes, organize ourselves differently, or that would have a major impact on our work culture,

    • or we see a bigger financial or legal liability risk, for example guaranteeing delivery or levels of services with high potential penalty payments that exceed one month service fees.

All time definitions are Zurich time. This agreement is tracked and reviewed as Governance Item VIP-302.