To receive a custom solution, a customer must first submit a Request for Quote. The customer fills out the document with as many details, screen shots, and examples of use cases as possible. The completed form can be submitted through your sales rep or via this webform. After receiving the Request for Quote form, the SalesPad sales rep will create a quote request detailing the project for the business analysts and developers to review. If the RFQ is submitted online, the request is sent directly to our team of business analysts to create the quote request. This quote request will include all of the documentation provided by the customer. The completed SalesPad quote (Statement of Work) becomes the final outline of the work to be performed, replacing the initial Request for Quote, since requirements may change from the original Request for Quote during discussions. The original Request for Quote is only a reference while the quote is being developed.
BUSINESS ANALYST Quoting
The quote request is placed in a quoting queue for SalesPad business analysts and developers to review and begin to define the Statement of Work. For simple requests like scripts, this process may be as simple as reviewing the document and determining hours. More complex requests will require a customer conversation and code investigation. Conversations to review any open questions or receive any clarification that may be needed between the business analysts, developers, and the customer will be arranged by the business analyst or sales rep.
New screens and functionality requirements may require a developer to investigate how the request would affect existing code, whether this functionality affects core components, and whether it could affect other customers’ business processes and use of SalesPad software. In the case of new screens or major user interface changes, SalesPad may create a wireframe mockup with our design tools to give the customer a representation of the new screen. The wireframe mockup is intended to be a basic layout of how the screen could be arranged, as a reference for the customer, but this can be changed upon later testing and review.
Internal Review Process
All custom quotes go through a multi-person scheduled review process that occurs several times per week. This meeting is used to evaluate the custom quote and ensure that the proposed solution satisfies the customers’ needs in the best manner possible, while eliminating other alternatives. After the quote is approved, the document is then put into a sales rep queue, which sends an email notification that the quote is now ready for delivery to the sales rep.
Lead Time Calculation
Internally, we have various lead times based on the type of work the custom request requires. Scripting, TSQL, and quick reports generally have shorter lead times, while new forms have longer lead times.
Note: SalesPad’s lead time calculation considers many factors, including but not limited to the project onboarding process, current developer workload, and external client communications. As an example, an eight-week lead time is factored from date of received deposit to the time the developed solution is delivered to the customer for testing.
Rush fees begin at an additional $50 per billable hour and may or may not be available for your project. To inquire about a rush fee, please email your sales rep.
Quote Delivery Process
The sales rep will email the quote along with any other additional files, such as any wireframe mockups created during quoting, to the customer. Solution Sales quotes contain the description, total hours, and total cost of the work to be completed.
Depending on the complexity of the solution proposed, a delivery call with the customer, sales rep, and business analyst may be scheduled to review the details and answer any questions.
Customer Order & Billing
The quote becomes an order by having the customer email or fax the signed quote to their sales rep. Solution pieces will require a 25% deposit if the total cost of the piece is $2,500 or greater. The invoice will not show line-item detail. Once deposit payment is received, the solution piece will be placed into the work queue, and the lead time starts. Therefore, the lead time begins after receipt of the 25% deposit and is not based on the date the customer signs the statement of work\quote.
Note: Custom deposits are applicable to any custom with a cost of $2,500 or greater. For custom under $2,500, the quote will immediately go into the weekly assignment development queue.
Solution pieces will be invoiced progressively on a bi-monthly basis (1st and 16th). Hours invoiced up to the 25% deposit amount will have a $0 unit price, so the invoice is at no cost (the deposit covers these hours). Once we have consumed 25% of the hours, invoices moving forward will show cost with Net 15 terms. When 75% of the total hours quoted has been consumed, a notification email will be sent to the project manager, assigned developer, and sales rep. If additional hours will be needed, the developer is then responsible for creating a "change order" quote, with specific detail of work remaining to be completed, along with suggested hours (the quote PO description should be the same as the original work order, with "Change Order" added). A lead time for this portion of work is also added. This quote is to be placed into "Manager Approval." The project manager is then notified when this quote is approved to send to the customer. If no change order is needed, no action is taken. When 100% of the total hours quoted has been consumed, work is halted until the customer signs off on a change order.
Developers are expected to provide screenshots/demos of completed work as often as possible throughout the project to ensure the customer feels comfortable submitting payments on work they do not yet have available to them. Solution Sales managers will monitor time consumed on a per line item basis, and address as they see necessary.
SalesPad's Agile Development Process is an iterative approach to software development and project management, focusing on continuous releases and incorporating customer feedback with each iteration. Whereas a traditional development process focuses on one large and comprehensive deliverable, an Agile team delivers work in smaller, more consumable increments called sprints, which are time-boxed to two-week cycles. This means that SalesPad is able to provide functional deliverables to customers for texting in two week increments. By utilizing this Agile approach to development, project requirements, plans, and results are evaluated continuously. As a result, SalesPad teams have a natural mechanism for quickly responding to change based on priority, which further improves collaboration and brings about solutions faster.
The methodology for this process breaks down into the following categories:
- Work: A list of small, defined tasks, sorted by priority and work effort estimates
- Time: Short, fixed-length iterations (sprints) with results that can be described and demonstrated on an adaptive schedule
- Organization: Small, cross-functional, self-organizing teams
Once a project has been assigned to a developer(s), and after the internal kickoff, there will be a kickoff call between the customer, the SalesPad project manager and the developer(s) (the project team). This meeting will serve to introduce the customer to our project manager and the developer(s) and is scheduled by the project manager. The developer(s) will be looking to clarify points of the quote that require customer input. From the customer side, we will be looking for a project champion that the development team can contact for answers throughout the development process. Typically, this individual is not a manager. They should be a regular user, with the expectation they will be dedicating time each week to testing and approving parts of the project.
Note: If there is an active implementation project associated with the custom piece, the kickoff call will also include the SalesPad implementation consultant.
The two types of development are custom deliverables and custom dlls. Custom deliverables consist of scripts and TSQL solutions. Examples of this type of work are pre-save scripts, quick reports, and TSQL views\stored procedures. After customer signs off on the custom work, a customer can update these modifications. Since a customer can modify scripts, reports, and TSQL, the customer is responsible for keeping the latest copy of the code. Customers can enlist SalesPad to make changes to these modifications at any time.
Custom dlls are customizations involving new screens, settings, and security. These modifications are done by our development team and are not modifiable by a customer in the future, unless the security or settings have options for the functionality. To modify a custom-built screen, a customer would reengage SalesPad to make the changes. Additionally, SalesPad is responsible for making sure our custom dlls upgrade properly between new versions of SalesPad.
Development work is done in C# for desktop and mobile applications, Java for web applications, and in TSQL for Database work.
During the development stage, a developer will be emailing or calling the project champion with new questions and clarifications.
Change Order Process
When 75% of the total quoted hours have been consumed on a project and the amount of remaining work exceeds the total number of hours approved, a change order will be generated for customer approval. Specifically, when the 75% threshold is reached, a notification email is sent to the assigned project manager, developer, and sales rep. The developer will then create a change order quote with specific details regarding the amount of work remaining, including an estimate of hours required to complete the task and the estimated project duration. Once this has been done, the project manager will provide the change order quote to the customer for approval. Once 100% of the total quoted hours are reached, further work is halted until the change order is approved.
During the first stage of software testing, the developer who wrote the code completes their own testing. After that, the developer sends the testing build, piece of software, or scripting files to the quality assurance tester by updating the development ticket and assigning it to our quality assurance team. The tester is responsible for testing and approving the build after testing both the intended functionality and trying to find any unintended consequences. If the tester finds any problems within the software, it is returned to the developer and the testing process is restarted.
In addition to the manual testing, SalesPad runs nightly tests on our core software branch. This is done through a testing tool called SmartBear, which mimics a user interacting with the software to confirm consistent responses to common core features. The purpose of this testing is to ensure new coding does not break existing functionality.
Customer Acceptance Testing
Acceptance testing is to be done by the customer. We highly suggest all customers have a testing database that is a copy of their production database. Please do not test in your live environment. This testing environment is where you install and test new builds before installing on your live system once testing has been completed. Ultimately, the customer is responsible for testing their own business use cases and finding any bugs or calculations that do not behave as required. SalesPad tries to find all problems prior to delivery, but the ultimate approval comes from the customer. The initial solution is not guaranteed to be bug-free, but it will provide the opportunity for the customer to test and use the features as outlined. If the customer finds any bugs during this phase, the developer(s) will be ready to make changes and repeat the entire testing process, providing a new build for approval.
The customer will need to sign off, by email or formal signature, indicating that they are satisfied with the final software product. After customer acceptance, additional support will go through the SalesPad support staff and not the development staff, as the developer(s) will be moved to other projects. If the customer remains unresponsive after two emails for more than three weeks, SalesPad will consider this to be a customer acceptance of the software. Upon this approval, the customer will be invoiced for the remaining balance of the custom piece.
SalesPad has two departments to support solutions software. The Custom Development team will write the solution and support the solution software for 6 months after the final invoice. The Desktop team will take over maintenance of the software after the 6-month period. Modifications done during the first 6 months are considered billable unless a piece of code unrelated to their software breaks an existing working feature. For example, if a piece of code displays a different behavior during active development, that is billable. If the code displays a different behavior based on upgrading to a new version of DevExpress® or a modification completely unrelated to the customer solution, a review will be conducted to determine the scope of the necessary changes and determine their billable status.
Future versions of the SalesPad products are compatible with your previous SalesPad software. However, this may require a company to update two SalesPad applications. This is accomplished by ensuring the custom code is either put into the core of the software or isolated in a customer-specific dll. If a customer has their own dll, we will sometimes have to modify it when we update to a new version of the DevExpress® controls package we use. This is essentially the only time we would modify a customer dll, and this process historically has not caused any upgrade problems.
SalesPad has a robust 30-person development team dedicated to custom development work. This team, comprised of technical business analysts, developers, and project managers, provides customization for our SalesPad products, as well as any custom standalone projects or applications.