# Statement of business value <!--- Outline the business value and/or return on investment that is the result of this proposal. Structure in statement of: <proposed change> will improve <business metric(s)> by <description of mechanism> e.g. "Adding the capability for users to give cash tips will increase cash revenue and content producer engagement by generating tip commissions for Minds and cash incentives for users to produce more and higher-quality content." ---> Moving to PostHog and HubSpot will improve sales conversions and improve business metrics by minimizing data maintenance overhead and introducing a suite of new tools and automations. # Scope <!-- MoSCoW specification --> ## Must have <!--- For the goal to be met, it **must** have the following criteria. Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the work – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement. ----> - [ ] Ability to have user-identied analytics - [ ] Opt-out ability in user settings - [ ] Functionality and user interface to wipe all analytics data - [ ] Deprecate Snowplow and scale down Snowflake processing stack ## Should have <!--- For the goal to be met, it **should** have the the following criteria. They are important but not vital. Without them the solution is still viable. One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected. ----> - [ ] An email system that can support imap/pop/smpt and allow forwarding - [ ] A functional CRM that empowers our sales and customer success team ## Could have <!--- For the goal to be met, it **could** have the the following criteria. It is wanted or desirable but less important. These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best case scenario. When a problem occurs and the deadline is at risk, one or more of the Could haves provide the first choice of what is to be dropped from this timeframe. ----> - [ ] Feature flag handling through PostHog * [ ] Sunset Zendesk for HubSpot/ChatWoot ## Won’t have this time <!--- The below will be out scope and it not expected or required to meet the goal ----> - Ability for users to download their data # Technical Analysis <!--- This section will usually be filled out following the completion of a Spike or Analysis task. The criteria above must be sufficiently built out before the analysis can be completed. --->