Enkompass would like to thank you for the opportunity to be of service to you. This proposal outlines the First Contact Marketing Software which we will call ‘Smartvestor’ throughout this document. Smartvestor is a piece of software that will have the following features:
- Software-as-a-Service – the software will be multi-tenant and multi-user. Users will need to buy a subscription to use the software.
- Microsoft Office365 integration
- Google Apps integration
- Twilio Integration
- Redfin CRM Integration
- Wealthbox CRM integration
- PayPal or Stripe Integration
- Application Programming Interface (API)
- Workflow Engine
- Notification Engine
- Logging Engine
- Analytics Engine
SAMPLE USER FLOW
Users log on to the platform with their Microsoft or Google credentials via OAUTH2. When they authenticate, they get to see the main interface which allows the user to create campaigns (or workflows). This specific version of the software will provide every user with one campaign only and users will not be able to create additional campaigns or remove the default campaign. The only action a user can take on a campaign is edit it.
In the campaign editor, a user is able to create one or more steps for the campaign. The first step is predetermined and cannot be removed, it can only be edited. Any single step can only perform one of two actions: email or text. When email is the action to take, the step editor will also allow the user to choose an email template from a list. There will be 10 variations of a default response template that will be provided by Smartvestor to all users. Each user will be able to create up to 10 templates of their own. Smartvestor will provide basic word processing tools to allow users to create and edit their templates. Every step also has additional properties such as its number in the workflow sequence, its execution disposition (whether or not it requires human approval in order to execute ), its delay in execution in relation to the previous step.
The sequence number determines when Smartvestor will execute any given step relative to other steps in the workflow. The first step is called the default step and is always executed when a workflow is first triggered. All steps in a workflow execute in relation to the previous step and their execution time is determined by the delay property of that particular step. The delay property is editable by the user and can be set to a maximum of 4 weeks. The only exception in the execution delay of a step is if a step’s disposition property is set to approval required. Smartvestor ignores the step’s execution delay when approval is required and waits for a human to approve the execution of the step and the delay in execution is measured from the time when the approval was granted.
The default step in the default workflow will be the only working trigger when this app version is completed. This trigger will require Office365 or a Google Apps integration in order to function. The trigger scans a user’s inbox and looks for incoming mail from a predetermined source having a predetermined subject line. When an item that matches said criteria is found, the item is then marked as read in the user’s mailbox and moved to a predetermined mail folder. At the same time, the contents of the item are copied and passed in a function call to the workflow engine, triggering its default step. The platform will be capable of recognizing several thousand triggers per second, only is limited by the maximum number of simultaneous Lambda invocations that applies to the AWS account hosting the platform.
Whenever a workflow needs to send out a notification to an entity, it simply uses the API to contact the notifications module. The notifications module will be capable of handling any kind of user notifications to include UI notifications (badges, popups, etc.), email notifications to any email address, text messages to any phone number.
Underneath all of these modules, a logging module will ensure that all actions throughout the system are properly logged and retained in order to comply with industry regulations. Extensive logging capabilities will be built throughout every module to ensure that we can always determine when a message was sent out and to whom. The logging module simply abstracts the logic that makes the log reads and writes possible.
Any given user will be allowed to view basic analytics related to their own account. Users can also change their picture and the main accent color of the UI as well as specify the login details to their Microsoft, Google, Twilio, and cloud CRM accounts. Users will be allowed to use either Microsoft or Google (but not both) as sources for their workflows. Likewise, cloud CRM account integrations will be allowed to any one single vendor supported by the platform. In the case of Twilio, if the user has a company account, the user will be unable to use the integration and will rely on his company’s administrator for things like phone number assignment and adding credits to the Twilio account. Individual and company accounts will be able to use the Twilio integration to select a phone number for the platform to use when sending out text messages. The Twilio integration will be one way and no incoming SMS messages will be processed. A message to that effect will be sent to any users trying to make contact via SMS to any Twilio number registered to the platform.
SAMPLE COMPANY ADMIN WORKFLOW
The accounts in the system will be one of three possible types: individual, company, and company user. All accounts start as individual accounts. Accounts can invite other accounts to join the company. When this happens, the inviting account becomes the company’s administrative account. Admin accounts can add and remove users to the company account. Another important distinction is that company accounts are responsible for payment for any and all associated accounts with that company. Initially, only users with the same domain in their email account will be allowed to join a company. Admin accounts can also run reports for any associated account and for the company at large. Once associated with a company, accounts can only be removed from the organization by the account admin. Adding or removing accounts in the middle of a billing cycle will cause an immediate prorated charge and/or refund being issued.
Admins of the platform will have a special dashboard where they can see their most important metrics displayed. Platform admins can also create subscription packages. Subscription packages determine what users will be charged for the service.
The platform admins can remove subscribers from any subscription package. Removing a user from a subscription will trigger a prorated refund. In order to allow user accounts to retain the features they may have signed up with, the platform will allow admins to create multiple subscription types. A subscription type could also be used to collect subscription revenue in a different type of currency. All subscriptions are renewed on the 1st of the month.
The system will automatically suspend accounts whose payment method cannot be charged. The platform admin can choose to grant users a grace period before their accounts are suspended. All subscriptions will be processed using a single payment processor. Admins can also invite users and they can create special ‘free’ accounts. All free accounts will expire at the end of the month in which they were issued. An account will be able to be marked free permanently with the approval of two admins. Optionally, a global limit on free accounts can be set. Free accounts can only be individual accounts. Free accounts may not ask other accounts to join it as a company.
IMPORTANT NOTE
Some functionality may have been inadvertently overlooked in the sample flows above. This does not mean that the functionality will not be included in the application.
