Solutions Architects Processes

SA Process Maps

The SA organization uses process mapping as a framework for structured and continuous improvement. LucidChart is used to document SA execution workflow and details; in other words, what we do and how we do it is documented as a visual process map. This provides a single location to find reusable artifacts, enablement, and tooling.

The goals of SA process mapping are inclusive of the following:

• To be prescriptive and deliberate with SA activities in order to continuously increase efficiency and effectiveness
• Faster SA onboarding
• Make more of what we do measurable
• Hold each other accountable
• Make it easier to collaborate and iterate on what we did
• Create a repeatable process for all SAs to collaborate with our customers

SA process mapping is not meant to restrict creativity, experimentation, or improvement. As part of the SA Learning Organization, SAs are encouraged to challenge our mental models and focus on solving problems as a team. If something can be done better, please try it out and share your learnings. Contribute to our process maps and to the supporting handbook pages.

To following process maps are best viewed in full screen. Please note that many of the map nodes are clickable, leading to other maps, handbook pages, or other supporting artifacts.

SA Activity Capture

Solutions Architects record all customer and prospect activity to promote transparency and collaboration. By consistently capturing our customer facing activity, we can perform analysis for further reporting to establish efficient decision making for GitLab’s business. More information on this process can be found on the SA Activity Capture page.

We have a standard meeting notes document that is formatted to enable the activity capture in Troops which should be utilised for each customer engagement

Customer Success Plan

A Customer Success Plan is a customer-facing and mutually agreed roadmap for achieving value through GitLab adoption. This is an outcome of collaboration between GitLab Solution Architecture and the customer with the primary objective of ensuring customers are successful. The process is designed to support shifting from product scoped conversations (focusing on specific features or functions and limited to a specific subset of DevSecOps stages) towards solution (addressing specific pain points) or strategic (shaping business outcomes through holistic organizational process innovation and transformation tied to top strategic initiatives ) scopes. This Success Plan starts in the pre-sales process and is intended to carry through to the post-sales Success Plan.

Note: While the Customer Success organization also has a Customer Success Plan, with the following template for post-sales, with the intent of it being used as a customer facing document, so that updates can be made on post-sales initiatives and milestones, the Solutions Architect’s Customer Success Plan process, intends to provide all the necessary context, and to capture the Customer’s Voice, requirements and outcomes, in collaboration with the Customer during pre-sales, to ensure a smooth transition to Customer Success. This is the previous pre-sales standard template.

In order to ensure that the Customer Success Plan continues to be a living document the Mutual Customer Success Plan was jointly developed by the SA and CSM orgs. The Mutual Customer Success Plan represents a living document, capturing the entire content and outcome of a customer’s journey with GitLab. It is used interchangeably with Customer Success Plan. The Mutual Customer Success Plan is intended to be dynamic and should therefore be regularly reviewed on an agreed-upon cadence.

Customer Success Planning core goal is to identify and state:

• Business outcomes
• Key business stakeholders
• High-impact strategic requirements
• Current state of customer technology ecosystem
• Current and desired capabilities
• Operational alignment with strategic objectives
• Perceived gaps and deficiencies in current capabilities

The Mutual Customer Success Planning process

1. The Solutions Architect starts with a Technical Close Plan during customer technical discovery (Stage 3 - Technical Evaluation) to understand the customer business outcomes and will remain the DRI
2. After the Technical Evaluation completes successfully, the Solutions Architect will utilize the mutual customer success plan template in a collaborative session with the customer to capture any necessary information not already captured in the Technical Close Plan, tracking the document in the Customer Success Plan field on the opportunity in Salesforce
3. After the initial Customer Success Plan is drafted, the link to the document will be updated by the Solution Architect in the Customer Success Plan field on the opportunity in Salesforce in a timely manner and before the opportunity closes
4. Where applicable, the Solution Architect will engage other functions (CSM, Professional Services) towards the end of technical evaluation to ensure long-term alignment, using the CSM Ready field on the opportunity in Salesforce to indicate plan readiness
5. The Solution Architect will share the results with the customer, either part of or in support of a proposal
6. The account team should ask the customer if they are willing to sign the plan as a gesture of joint commitment to the plan
7. The Solutions Architect should follow the meeting with an email summary, potentially using this email template, ensuring the customer is aligned with the plan and acceptance is capture
8. After reviewing and securing buy-in with the customer, capture the acceptance of the Customer Success Plan in Salesforce using the Customer Accepted field on the opportunity
9. The Account Team and the customer will agree on the cadence for reviewing and updating the Success Plan during and after the sales cycle
10. The Customer Success Plan will be reviewed with the CSM team when the account moves into Post-Sales

To summarize, there are three additional fields in the Customer Success Plan section, on the Opportunity level in SFDC, that should be maintained through the process:

1. Customer Success Plan: field for the URL to the plan
2. CSM Ready: Check if the plan is/can be handed over to the CSM
3. Customer Accepted: Check if the customer accepted the plan

Please read the Customer Success Plan page for more details on the Mutual Customer Success Plan process.

Positioning Professional Services

Solutions Architects should be pitching professional services at every qualified customer opportunity due to long term customer sucess and growth. Please use this deck and rubric to familirize yourself with the catalog listed here. Please add “Positioned PS” as SA activity type after you have positoned it for your opportunity.

Engaging Professional Services

Follow the process detailed in the Working with Professional Services handbook page.

Simplified process description:

• Ensure that PS Opportunity has already been created by SAE / AE in SFDC.
• If it a standard (non-customized) service from our full catalog.
  • SAE / AE to order PS directly from Zuora in SFDC.
• If standard services do not meet the needs of the customer
  • Use the Services Calculator to generate an issue and a draft quote.
  • Iterate on that issue with PS and SAE / AE.

Customer Security Assurance

Follow the process detailed in the GitLab’s Customer Assurance Activities handbook page.

Optional Considerations when engaging the Customer Assurance team:

• You can start with Security - GitLab Trust Center in some cases.
• Encourage customers to use and review Self-service Information Gathering.
• SAs can attempt a first-pass for all security questionnaires if time permits
  • Do it, it’s fun and educational!
  • You can also make use of the GitLab’s Trust Center
• Additional requests can be made in #sec-fieldsecurity Slack Channel.
• When spending time on a security questionnaire ensure you capture the initial time dedicated via our SA Activity Capture system (troops).

SA Initiatives and OKRs

Solutions Architects record and track their OKRs (Objectives and Key Results) and Initiatives in the SA Initiatives GitLab project. OKRs are directly realted to the fiscal year SA focus areas as well as company OKRs. Initiatives are independent of focus areas and OKRs. Every Solution Architect can start a new Initiative and OKR as well as contribute to existing. Both are ideally broken down to quarterly achievable efforts with DRIs (Direct Responsible Individual) for each action item as well as measurble deliverables (Key Results). For documentation and tracking use the OKR and Initiatives template provided in the project and apply the corresponding labels. At the end of the quarter each Inititative and OKR should be successfully closed, archieved or moved to the next quarter if necessary. New planning starts at the beginning of the new quarter.

Cross-functional Sales Team Processes

Working Agreements

Enterprise Solutions Architects typically support sales teams made up of Sales Development Representatives, Strategic Account Leaders and Customer Success Managers. Commercial Sales Solutions Architects support Mid-Market Account Executives and SMB Customer Advocates in a pooled model. When joining a sales team, establishing working agreements is critical to providing optimal service to the customers as well as the GitLab team. A sample template of working agreements is found below to help facilitate conversation and establish these agreements:

1. Customer response time for emails and meeting followups I will always do my best to provide same-day responses to customer inquiries and follow ups unless otherwise noted. I like to provide customers top-notch service, but interruptions can affect that target. I will use my out of office when traveling so customers can expect delayed responses during those times. Feel free to contact me if it’s approaching the end of the day and you didn’t see me address a customer request. Slack is the easiest way to find me most of the time.
2. Delivery Excellence If the nature of my response requires a top-notch service needing me to contextualise my response in better and higher quality to our customers, I will collaborate with my GitLab sales team and set reasonable timelines for completions. Examples could be customized and tailored summaries of technical guidance as per our documentation (not just a url), suggested reference solutions architectures, and/or integrations with third-party technologies to GitLab.
3. Calendar Schedule things as necessary right on my calendar during working hours - I’ll do my best to keep my calendar up to date. However, if you see only one empty slot for a day or if it looks like the meeting would be back to back with something else, please check with me before confirming dates and times with the customer. If you want me at my best for you, I will need time to prepare and followup. If we schedule back to back, I’ve found I’m often late to arrive due to the last meeting, flustered as I context shift, lacking answers for known questions, unprepared with demo environments that were altered in the last call, etc.
4. Regular communication A weekly strategy hour-long call with the SA, SAE, SDR and CSM is preferred. If more frequent synchronous communication is desirable or required, we should work together as a team to identify a viable cadence, required attendees, convenient time and agenda for those calls. In either of those regular communication methods, documenting discussion points and agreements is essential.
5. Elevated conversations The more we focus on value and stay away from very deep technical and troubleshooting conversations, the more I can help you achieve target sales. I’m happy to review and contribute to business plans and strategies so we remain in sync.
6. Professional Services After careful assessment of the clients needs to drive faster adoption, I’m happy to recommend and propose required services for prospects and customers. I will write the initial SOW and get approvals from the Professional Services team.
7. Travel While strategic enterprise sales absolutely require travel, each day on the road can increase the volume of work and calls on other days of the week as my dialogs with customers often require extensive time commitments to research and model specific customer solutions. Please plan strategically when looking at on-sites, considering that I support at least two sales teams in my region. Additionally, please work with the customer when arranging for an on-site (or F2F) visit with 1 week’s notice. This will allow me to ensure my commitment to attend and take alternative arrangements for family and other matters if needed.
8. Notes Unless otherwise directed, external call notes with customers will be linked to a Google document from Salesforce and stored in the Gdocs “GitLab Sales” directory. Email communication with customers will also be bcc’d to Salesforce. If you prefer to record notes and actions differently, please let me know what that collaborative method is and I will link it to the SA Activity process.
9. Continuous learning Things at GitLab move really fast, and I need time to keep up. I’ll block a few hours on my calendar coincident with releases to absorb the latest GitLab feature set, but new technologies and competitive products also appear regularly. Please expect that I will need to allocate additional time to learning about those on a regular basis to sufficiently support our customers.

Tool Usage within Cross-functional Teams

1. Salesforce [To-do] Add info on views and reports to use during the sales cycle. Also, guidance on SA being listed on opportunities and accounts (there is not any info in our current handbook)
2. Gainsight Primarily for account planning in partnership with SAE and CSM. The easiest way to access Gainsight is via Salesforce. See the Account Planning in Gainsight page for details.
3. Slack Create a public internal team slack channel for your cross-functional team. This will allow you to collaborate easily without sending DM’s.
4. Google Drive There is a shared GitLab Sales folder. Running customer notes and other documents related to a specific customer should be stored in the Customers and Prospects Subfolder under the appropriate letter and customer name subfolder.
5. GitLab Account Management Project may be used for a POV and/or CSM collaboration with a customer post-sale.
6. Chorus.ai is used to record meetings. The GitLab Notetaker will automatically join meetings with people outside of GitLab once your account is set up.

Account Planning

Account planning helps the SAE and the SA elevate opportunity-driven conversations into value-based conversations that focus on the customer’s value drivers. It is a critical step in strategically supporting the customer at the account level, and facilitates more efficient opportunity planning. See the Using Gainsight for SAs page for details.

Quarterly Exchange

At the end of a quarter, an SA team meets to share what they have been focused on to either share learnings or gather insights.

Goals

1. Collaborate, learn from, and improve upon each other's customer activities
2. Create a dialog to leverage each other's work
3. Grow closer as a team

Anti-goals

1. Perfection
2. Busy work
3. Another meeting

Format

15-30 minutes for each SA to either Reflect Back or Look Forward.

⬅️ Reflect Back

Reflecting back on the past quarter, an SA can share what worked well or what should be avoided. A great way to facilitate this reflection and discussion is through Closed Opp Key Learnings or a Customer Strategy Plan.

Look Forward ➡️

Looking forward on the upcoming quarter, an SA can share a Technical Opportunity Plan to outline their strategy to secure a technical win and gather feedback and insights from team members.

Quarterly Business Reviews (QBR)

Solutions Architect Managers prepare QBR content by utilizing SA specific Dashboards, feedback from their SA and regional cross-functional teams, and through the Quarterly Exchange.

SAs should offer proactive assistance in matters related to articulation of technical win and success criteria details in the Notable Opportunities section.

Slides are stored in the Solutions Architects QBR folder in the appropriate quaterly subfolder.

Engaging an SA During the Sales Cycle

Solution Architects may participate in initial qualifying meetings (IQM’s) or allow the SDR and SAE/AE to manage the initial call and utilize information gained during it for additional preparation. Teams can handle this on a case by case basis.

Once objectives and expectations have been established following the command of the message discovery, we suggest a recommended review as an account team of information gathered. This will help us determine if qualification criterias have been met to proceed with further technical discovery or that the account requires further discovery of their outcomes. Solutions Architects oftentimes will have a unique perspective in a given opportunity and it is vital that this information is distilled and shared out, preferably through the command plan, to the rest of the account team.

The perceived size of a given opportunity is not always reflective of the amount of effort that an SA ought to put into a given customer. The requirements listed below are aimed at:

• Providing the SA to interface with as many opportunities as possible, by ensuring the proper preparation has been done prior to meeting with the customer
• Giving every customer increased confidence in the value they perceive through meeting with the SA and having them validate their plans
• Leveraging SAs exposure to opportunities to give SAs the autonomy to invest appropriate levels of time where they see the most amount of investment needed
• Reduce the onset of SFDC Opportunity confusion due to the lack of information provided or lack of in-depth knowledge within the varied technical domain(s) presented

When reaching out to engage SAs during opportunity qualification, discovery, and technical evaluations, please provide the below information. This will enable the SAs to accelerate execution, enable success, and promote consistent and quality opportunity outcomes aligned to the varied Sales roles and adopted strategies. The SAs reserve the right to decline the meeting if the below information is missing/not provided after being asked & if the correct personas are not engaged. We will review the exceptions on a case-by-case basis in case the below information is not provided and/or not qualified.

• Please provide active SFDC opportunity ID
• Please provide link to the associated and completed Command Plan
  • Ensure the Why Now?, Identified Pain, and Champion have been captured
• Any additional opportunity information (i.e. company overview and background, initiatives, desired outcomes, personas, etc.)
• Ensure that any scheduled or planned customer meetings have been discussed with the SA before customer engagement
  • What are we attempting to accomplish within the scheduled meeting?
  • Are the objectives clear and understandable?
  • Have expecatations been managed and cleary discussed?

Poorly positioned opportunities where the SAs has been engaged at the wrong time or without enough context will lead to SA burnout, stalled or prolonged sales cycles, and misalignment with the customers needs. It is critical that SAs are engaged when the Command Plan is leveraged, specifically the Why Now/Identify Pain are in sentence format.

Solution Architects should participate in technical discovery after lead qualification is complete and in other activities during the sales process that lead to a technical win, e.g.

• GitLab demos
• GitLab technical deep dives
• GitLab hands-on workshops & Labs
• Whiteboarding sessions
• Prospect Q&A sessions
• RFI/RFP completion
• PoV planning, documentation and execution strategy
• Security Audits
• SOW Scoping with Professional Services

SA’s may also work in tandem with a CSM to support existing customers, especially when expand opportunities exist within the account. And SA’s may also have regular touch points smaller customers who do not have a CSM assigned.

SA/CSM Engagement Overlap

• On a high level note, SAs are the pre-sales advisors for our prospective as well as existing customers and CSMs manage the post-sales relationship of existing customers and are responsible for the GitLab adoption.

Further details can be found here: Overlap Between Solution Architects and Customer Success Managers

Technical Discovery and Demo Preparation

The Solutions Architect, in order to tailor conversations and demos to demonstrate value as well as address current problem areas, will want to understand the following information, and may request further technical discovery¹ prior to any demo:

1. Outcome:

• What’s in it for the client?
• Why look at a new strategy for software development?
• What triggered the sudden client interest in GitLab?

1. Infrastructure:

• What tools are currently in place?
• What tools have potential to be replaced?
• What processes or workflows have potential to change?

1. Challenges:

• What problems/roadblocks have been uncovered?
• What current process or technology is being utilized for what software development reasons? (i.e. what purpose does the developed application have?, What language is it written in?)
• What is the current release velocity?
• What is the current planning process?
• What visibility, traceability or efficiency concerns exist?
• What collaboration or governance opportunities exist?
• What security or compliance inefficiencies exist?

Once a technical discovery has been completed, SA will work within the account team to solidify a path forward (will the customer proceed with a purchase, trial, proof of value?) and idenitfy the corresponding metrics that will be used to determine the success of the evaluation.

Solution Architect Engagement Models

U.S. Enterprise Account and Opportunity Engagement Model

The Enterprise Strategic SA Engagement Model intends to foster collaboration and influence an even greater iteration amongst ourselves and customers.

Given that Landed Addressable Market (LAM or LAM Dev) might not always be correct and the Opportunity Net ARR isn’t always indicative of the potential, this model segments an SA team’s engagement by the AE role, so that the SA engagement model is aligned with the AE team structures.

Solutions architects are responsible for owning their engagement on opportunities. The “engagement model” is a general recommendation, not a rule, and will be left to the discretion of the solutions architect.

For Major Account Executives, SAs are aligned with the account executives in their respective account activities.

For Strategic Account Executives, SAs are aligned with the account executives based on ongoing opportunities.

For Strategic Account Executives, the below process can be used to request a SA.:

• The Strategic Account Executives will click on the “SA Request” button in salesforce after creation of a qualified opportunity.
• This requires information regarding the customer’s pain points, why now and any additional information needed to get SA help.
• This information is pre filled from command plan and close plan if it exists. If this doesn’t exist, then this will also be added back to the command plan and close plan
• This request is triaged through a slack channel and will be accepted by a SA which will populate the Primary SA field.
• The turn around time for a SA allocation is 24 hrs.
• Enterprise SAs will be dedicated through out the lifetime of the opportunity.
• Retaining SAs for multiple opportunities throughout the life cycle of an account or dedicated SA for SAE will be at SA/ASM manager discretion.
• The SA/SAE alignment will be visible on a report

Async Slack support

In some cases SA support might be required in early stage or not fully qualified opportunities. Slack can be used for answering technical questions, providing additional customer outreach materials or helping an Account Executive with a narrowly-scoped customer inquiry. These requests can be served asynchronously via Slack:

AMER EAST: #us-amer-east-sa-support AMER WEST: #us-amer-west-sa-support

These Slack channels are considered to be a safe harbor for all enterprise AE <-> SA communication. When asking questions, please ensure you provide as much context as possible; including the SFDC URL, and type of subscription (SaaS or Self-Managed). Solutions Architecture will monitor and provide best effort support on these requests.

EMEA Account Engagement Model

EMEA Enterprise Solutions Architects support the Major Account Executives (MAE) as well as the Strategic Account Executives (SAE) with an alignment model.

SAs are regionaly aligned to AEs and aligned in their respective account activities. Each team collaborates according to standard Working Agreements, but they can be adjusted by teams individually.

Default alignment is maintained in the EMEA AE-SA Alignment page.

When workload exceeds the SA’s capacity or when there is a request from other departments, please reach out via #emea-customer-success Slack channel for assistance.

Commercial Engagement Model

SA engagement for customer interactions, RFP’s, audits and more (how to engage a Commercial SA) can be requested by an SMB or Mid-Market Account Executive or other GitLab team-member using the SA Request button on the Salesforce Opportunity. Find more information about engagement considerations, triage process and expectations in dedicated Commercial Solutions Architecture Engagement Model handbook page.

APAC Account Engagement Model

APAC SAs are aligned regionally into regions such as ANZ, SEA (South-East Asia), India, South Korea and Japan in close alignment to the Strategic Account Leaders, Commercial AEs and Channels Managers territories. Teams collaborate to the standards Working Agreements.

Ecosystem SA Engagement Model

The Ecosystem SA (ESA) team is global. The Ecosystem SA’s are aligned variously with global and regional partners of all types based on the team member’s experience and needs of the region. Working alongside Ecosystem Sales Managers (ESM) in each region, Ecosystem SAs focus on developing Partner relationships as opposed to direct Customer relationships. Ecosystems SAs do participate in direct customer engagments when the Partner needs support in the sales cycle and their account team is not ready to involve GitLab sales teams. Ecosystem SAs will seek to document all customer interactions and as quickly as possible hand off to Field SAs to drive the opportunity with the partner and customer. Ecosystem SAs can provide backup to the Field SA community in support of a Partner aligned opportunities.

Most Opportunity based enagement should start with the ESM and they should identify the appropriate Ecosystem SA to engage. The ESM for every account is listed in the SFDC customer account record. The ESA for a partner account is listed in the SFDC partner account record. If no ESA is listed reach out to the Ecosystem Sales Manager for assistance.

See the details of how to engage an Ecosystem SA in the Ecosystem Solutions Architect Engagement Model handbook page.

Subject Matter Expert Engagement Model

Before you invite or request an Subject Matter Expert for your opportunity, ensure your opportunity is fully qualified. The SME should be requested by the primary Solutions Architect. This will help make sure we’re using our resources efficiently and effectively.

Create an issue in the SME Triage Project using the template. You can have a look on the board for current engagements.

Secondary SA

A given opportunity may be found to be too complex, valuable, or risky for a single SA to adequately secure a technical win on their own.

Ad Hoc Support

As part of GitLab’s CREDIT values, SAs are encouraged to collaborate with one-another on customer activities to deliver better results. As such, SAs often reach out on their own seeking assistance. Examples include asking questions in Slack channels or Stackoverflow, scheduling brainstorming or enablement meetings, and supporting each other’s demonstrations or workshops.

Long-Term

To better support the business and create an opportunity for SAs to collaborate and learn from one another, SA Leaders may assign a secondary SA to pair long-term on an opportunity.

When only ad hoc support is needed without a long-term secondary SA, SAs should continue relying on and collaborating with one another.

Tracking Secondary SA Engagement on Opportunities

Ad hoc and long-term secondary SAs should log activities as if they were the primary SA supporting the account, capturing their impression of the customer interaction. The Primary Solutions Architect field in Salesforce would be used to designate the primary SA, and any other SAs involved in the opportunity would be derived from the logged activities.

If a secondary SA is also involved as a Subject Matter Expert, the SA Assistance - Subject Matter SA Activity Type should be used when logging the activity.

Issue Creation Details

1. Navigate to the correct board for your region. NOTE: All triage boards are located in the SA Triage Boards group in projects broken out by region or engagement model.
2. Create a new issue.
3. Use one of the available templates:

• New activity: use the “SA Activity” template to ensure the proper data is collected and available
• Follow up activity: use the “Follow Up” template
• Security audit: use the “Vendor Security Assessment” template

1. To help the SA group ensure success for the client, the following information should be made available prior to SA engagement

• Customer Information: Customer name, SFDC opportunity link
• Preferred Date Options: When would the customer want to have the call (including time zone information)
• Target Hosting Environment: Self-Managed, cloud or GitLab.com?
• Challenges/Pain Points: What is the customer pain/problems?
• Required Capabilities: What does the customer need?
• Current Tools/Competitors: What is the current tool set? Are any of those tools non-negotiable?
• SA Asks: What do you need from the SA’s (demo, technical Q&A, SOW, etc.)

1. Add one or more of the following labels as needed (labels listed below).

Board Label Descriptions

• Open/no label: Newly submitted issues
• SA Triaged: Issue ownership has been claimed by an SA
• SA Demo Ready: Prep has been completed for a customer interaction and further scheduling or conversations can now occur
• Security Audit: This request requires security team involvement, typically upon receiving a customer security questionnaire
• Services Request: If this opportunity focuses on services, use this label to indicate that
• SA Doing: Once an SA signals they are actively working the issue, the issue is moved to ‘Doing’. The issue will stay in this status until the SA, customer and sales team agree the issue has been completed
• SA Followup: Followup work is required by the SA for this particular request (example: questions needing research after a call ends)
• SA Waiting: This label indicates that an SA is waiting on the requestor for more information before advancing this issue
• SA POV: A Proof of Value is being requested or needs support

Triage of Issues

The SA team associated with each region will monitor the triage board and/or an associated Slack channel for incoming work and will contact the appropriate Customer Success team members via Slack, email or phone depending on required skills, schedules and availability. SLA for activity is 48 hours unless the issue is marked with an ‘Expedite’ label.

Requesting an SA to support Events

Solutions Architects are often needed to support events requiring their expertise. The event support requests require SA assignments worldwide and collaboration between the requestor, SA leadership, and individual SAs. Without an efficient and transparent request and triage process, we risk incurring higher expenses than necessary, disrupting revenue opportunity SA engagements, and suboptimal diversity and inclusion.

To request an SA to support an event, it is required that you:

1. Create a request using the SA_Request template here.
2. Provide all required information.

SA Leaders will leverage the SA request triage board to track all requests and assign the most appropriate SA for each event. The following criteria will be considered:

• Competency required
• SA Availability
• SA Location
• Diversity and Inclusion

Following this request and triage process will ensure we minimize the expenses associated with supporting events, avoid disruption on revenue-producing opportunities, and represent diversity and inclusion at the events.

There is a 5 day SLA in place to secure SA participation.

Request Solutions Support from Product

When a prospect or customer have required capabilities that do not map directly to our product offering, Solutions Architect’s first step is to explore solutions or work-arounds that would satisfy their requirements with our current toolset. If the SA is unable to determine an approach that works for the prospect, the next best action is to reach out to the Product Manager. To determine what Product Manager is appropriate, review the Product Categories handbook page.

To be efficient as possible, this is the recommended approach:

1. Gather: Document and articulate the Customer journey
   1. Start by creating an issue on their Account Management Project. Include the customer business objectives, existing approach, and communication between the prospect (call recordings, emails, etc).
   2. Reference running logs in the Customers & Prospects folder
2. Explore: If applicable, document the solutions or work-arounds that were explored with the customer and why that was not sufficient
3. Engage: Reach out to the Product Manager
   1. Create a new slack channel with SA/SAE/PM/etc with a link to the Account Management issue
   2. Be mindful and gift a minimum of 48-96 hr lead time.  Properly done, PMs should have at least a weeks notice
   3. Collaborate using the Account Management issue, history, running docs, and shared material
   4. [optional] Suggest an internal team call to coordinate materials and next steps
4. Communicate: Set up a call with the prospect or customer to determine the next best steps.

Request Content From A Demo Architect

The two main reasons you would need a Demo Architects assistence is either with help setting up content/infra for a specific event, or request for a demo that may or may not already exist. The process are split below:

Hands On Workshop/Lab

The best way to do this is by filling out this issue. You dont have to know the answer to every column before adding something to the issue but by adding your info a Demo Architect will set up an inital planning/content handoff meeting with you. Please note that the general ask is to have at least a week of heads up before an event.

Specifc Demos

First check out the CS Shared Demo Space and make sure that the demo you are looking for dosent already exist. You may need to request access to be able to see some of the content. If you still dont see content for what you are looking for or think one of the demos needs an update please open an issue by following the READEME here

View page source - Edit this page - please contribute.