Attachment_E_-_Solution_Requirements_V3.docx

DOCX document 51 KB Posted Jun 24, 2026

Attached to: MNIT/DOC MINNCOR eCommerce Solution
Solicitation number: 2000018420
Issued by: Ramsey County, Minnesota

About this file

Written by GovTribe AI · Jun 30, 2026

This document is an Attachment E—Solution Requirements specification for an eCommerce Print Shop Solution developed by the Minnesota Department of Information Technology Services (MNIT) in partnership with the Department of Corrections (DOC) MINNCOR Industries Division. The State seeks a comprehensive, vendor-managed cloud-based eCommerce platform to serve as a centralized hub for MINNCOR's diverse product line, including commercial printing, office furniture, seating, upholstery, high-visibility clothing, and specialized manufacturing goods. The solution must support the complete product lifecycle from management through ordering, fulfillment, and reporting. The specification document functions as a detailed requirements matrix where vendors must respond "Yes" or "No" to indicate whether their solution meets each requirement, classified as Critical (C), Desired (D), or requiring narrative Response (R). Requirements span system foundations including role-based access controls with three administrative levels (Webmaster, Administrator, Limited Access), system security compliant with Minnesota IT Service standards, accessibility standards (VPAT Section 508, WCAG 2.0, and PDAA compliance to Level AA), and support for current browser versions including Google Chrome, Internet Explorer, and Safari.

The specification requires the vendor to provide comprehensive implementation services, including data conversion of existing products, customer profiles, order history, and master product information with photos and variable specifications. The vendor must deliver vendor-specific contact resources, documented implementation plans with internal and State testing, training on system functionality delivered at multiple levels with online knowledge bases and training videos, and ongoing maintenance and support included in Year One pricing. Critical requirements include nightly encrypted database backups stored off-site, data export capabilities, integration with Microsoft products and Epicor Kinetic for inventory and financial management, and compatibility with EFI PrintSmith for cost estimation. The solution must support three distinct user types—administrative staff, customers in hierarchical account structures (Company, User Group, User levels), and suppliers (subcontractors)—with role-based access, customizable permissions, and segregated product catalogs. Additional requirements encompass product management functionality for static and variable data products with Adobe InDesign compatibility, automated proof generation, pricing with quantity breaks and tax handling, supplier dashboard and order management, customer shopping functionality with saved addresses and payment methods, and comprehensive reporting including order, product, configuration, spending, and promotion reports.

View the file

Other files

File	Type	Posted
Attachment_C_-_Cost_Detail.docx	DOCX document	Jun 24, 2026
Attachment_F_-_MINNCOR_s_Product_Lines.docx	DOCX document	Jun 24, 2026
MNIT_DOC_MINNCOR_eCommerce_Solution.pdf	PDF	Jun 24, 2026
RFP_Template_MINNCOR_eCommerce_Solution_2026_Final_V2.docx	DOCX document	Jun 24, 2026
RFP_Addendum__1.docx	DOCX document	Jun 24, 2026
RFP_Addendum__3.docx	DOCX document	Jun 24, 2026
ptsamplecontractsandexhibits.docx	DOCX document	Jun 24, 2026
Attachment_D.pdf	PDF	Jun 24, 2026
Attachment_A_and_B.pdf	PDF	Jun 24, 2026
RFP_Addendum__2.docx	DOCX document	Jun 24, 2026

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Attachment E – Solution Requirements: eCommerce Print Shop Solution

The table below presents the system requirements. In the Response column, respond Yes or No indicating you have read and understand the requirement and whether your solution meets the requirement. If a different response is required (indicated by an “R” in the Code column) follow instructions to either type the narrative response in the corresponding Requirements column/cell or provide the information in an attachment to the proposal identifying by number of the requirement the narrative is provided in response.

No response will be taken to indicate that you do not meet the requirement.

Code:

C = Critical Requirement D = Desired Requirement R = Response Required (narrative or attachment)

Requirements

Code

Response (Indicate Yes or No for all C and D requirements)

System Foundations

1.1.

Role Based Access and Account Structure

1.1.1.

Administrative Access

1.1.1.1.

The system will be expected to provide a means to create accounts and access so that the proposed solution can be administered.

Note: System administrators will typically be MINNCOR employees C

1.1.1.2.

The proposed solution will be expected to grant MINNCOR the authority to control the administrative rights and levels of access.

Note: MINNCOR currently uses three levels of administrative access, which in order of descending access are: Webmaster, Administrator, and Limited Access. The access permissions include administering the product listings, viewing orders, setting prices, user administration and receiving system messages per Company.

1.1.1.2.2.

Describe the levels of administrative access of your proposed solution:*

*Responders should provide a narrative response to the left

1.1.1.3.

The proposed solution will be expected to allow MINNCOR to control the access of Customers, by specific User, User Group and Company, so that some users have full access, but others have only access to limited functions.

1.1.1.4.

The proposed solution will be expected to allow MINNCOR to control Customer user names and permissions.

1.1.1.4.1.

Describe the different type of permissions that can be granted to customer users:*

*Responders should provide a narrative response to the left

1.1.2.

Customer Access

1.1.2.1.

The system will be expected to provide a means to create unique customer accounts. (see section 6 for Customer Account requirements)

1.1.2.2.

The system will be expected to provide a means to create a hierarchical user account structure to allow the creation of a Company with multiple User Groups within each Company.

1.1.2.3.

The system will be expected to provide a means to assign permissions at all levels of the account structure hierarchy: Company, User Group and Users.

1.1.3.

Supplier Access

1.1.3.1.

The system will be expected to provide a means to create unique supplier accounts. (see section 4 for Supplier Account requirements)

Note: Suppliers are typically contractors who are responsible for producing fulfilling orders on behalf of MINNCOR in a sub-contractor capacity.

1.1.3.2.

The proposed solution will be expected to allow MINNCOR the ability to assign multiple Suppliers, that are assigned inventory, to provide distribution of product. MINNCOR uses the PO number (entered/provided by the customer) or an auto generated order number if one is not provided to assign product orders to Suppliers.

1.2.

System Security

1.2.1.

Reference the Minnesota IT Service page regarding Security Policies and Standards (https://mn.gov/mnit/government/policies/security/) for further information on the statutory basis and resources necessary to comply with this section. For determining which standards apply, the Data Protection Categorization is Low and the Data Classification is Public.

1.2.2.

The system will be implemented with the necessary security certificates to ensure proper encryption of the site.

1.2.3.

The system will comply with State of Minnesota security standards for a web-based application.

1.2.4.

The system will comply with State of Minnesota security standards for a Cloud-based solution – only applies if that type of solution is proposed by the vendor.

1.2.5.

The vendor will be responsible for testing site security and functionality.

1.2.6.

The vendor will submit to a Minnesota IT Service Web Application Assessment Report during the development and after the system is deployed into production.

1.2.7.

The Vendor will mitigate all issues that fall into the Critical and High severity issues identified in the Minnesota IT Service Web Application Assessment Report.

1.2.8.

The vendor will make a reasonable effort to mitigate Medium and Low severity issues identified in the Minnesota IT Service Web Application Assessment Report

1.3.

System Accessibility

1.3.1

Reference the Minnesota IT Service page regarding Accessibility and Policies and Standards (https://mn.gov/mnit/government/policies/accessibility/) for further information on the statutory basis and resources necessary to comply with this section. All mandatory forms outlined in this section can also be found on this page.

1.3.2.

The vendor will be expected to complete the Voluntary Product Accessibility Template (VPAT section 508)

1.3.3.

The vendor will be expected to complete the Web Content Accessibility Guideline (WCAG 2.0)

1.3.4.

The vendor will be expected to complete the Policy Driven Adoption for Accessibility (PDAA)

1.3.5.

The vendor will be expected to meet the standards for the State of Minnesota as it applies to the Voluntary Products Accessibility Template (VPAT Section 508) as adopted June 14, 2018, at no cost to the site.

1.3.6.

The vendor will be expected to meet the standards for the state of Minnesota associated with the Web Content Accessibility Guideline as adopted June 14, 2018, at no cost to the state. The vendor will comply to level AA prior to implementation into production.

1.4.

Browsers and Platforms Supported

1.4.1.

The proposed solution will be expected to run on the current version of Google Chrome, Internet Explorer and Safari.

1.4.2.

The proposed solution should run on the current version of Microsoft Edge, Mozilla Firefox.

1.4.3.

The proposed solution will be expected to be designed to support future versions of browsers as part of normal maintenance for the lifecycle of the solution.

1.4.4.

The State desires that the proposed solution be mobile-friendly

1.4.4.1.

Describe or provide examples of a mobile-friendly version of your solution.*

*Responders should provide a narrative response to the left

1.5.

Maintenance and Support

1.5.1.

The State requires the Contract Vendor to provide maintenance for the proposed solution. Maintenance for Year One of the contract will be expected to be included in the proposed price.

1.5.2.

The state requires the Contract Vendor provide support for the proposed solution.

1.5.2.1.

Provide detail on the type(s) of customer support included with the proposed solution (i.e., phone, online, email, etc.):*

*Responders should provide a narrative response to the left

1.5.3.

The State desires to have the ability to escalate a support ticket.

1.5.3.1.

Describe your escalation process, include a detailed problem resolution chart or similar documentation.*

*Responders should provide a narrative response to the left

1.5.4.

The State requires that the Contract Vendor provides regular maintenance of the proposed solution.

1.5.4.1.

Describe your process for implementing system upgrades, providing needed maintenance, and how you troubleshoot any issues:*

*Responders should provide a narrative response to the left

1.5.5.

The State requires the Contract Vendor provide at least a 2-business day notification about planned outages and to respond to unplanned outages within one business day.

1.5.5.1.

For unplanned outages, including response times, how do you respond to issues – during normal hours of operation and after normal hours of operation.*

*Responders should provide a narrative response to the left

1.5.5.2.

Provide information on Attachment C (Cost Proposal) for any service level options.*

*Responders should provide a narrative response to the left

1.5.6.

Vendor will be expected to have experience in troubleshooting customers’ interactions with the website to facilitate the design and ordering of products in an eCommerce environment.

1.5.6.1.

Describe your experience and provide the name and contact information of at least one government entity reference, where the contract is of similar size and scope to the proposed contract:*

*Responders should provide a narrative response to the left

1.6.

Backup Requirements

1.6.1.

The proposed solution’s application database will be expected to be fully backed up nightly. Backups will be expected to be encrypted and stored at an off-site location each night.

1.6.1.1.

Describe your data backup and disaster recovery plan for the proposed solution:*

*Responders should provide a narrative response to the left

1.6.2.

Responders will be expected to disclose the off-site location that would house the State’s backed up database:*

*Responders should provide a narrative response to the left

1.6.2.1.

If a responder wishes to designate this information as non-public for security reasons, please see Paragraph 23 of the State’s General Terms and Conditions.

1.7.

Data, Retention and Data Export

1.7.1.

The State desires that the proposed solution retains and stores records in a format that is searchable for the entire term of the contract.

1.7.1.1.

Provide detail on data retention cycles and whether those are controllable by an Administrator.*

*Responders should provide a narrative response to the left

1.7.1.2.

Provide detail on how customers, MINNCOR administrators and suppliers can search any data that might be archived due to data retention cycles.*

*Responders should provide a narrative response to the left

1.7.2.

The proposed solution will be expected to have data export capabilities.

1.7.2.1.

Provide documentation about the proposed solution’s data export capabilities. Data exports that are in a proprietary format will be expected to be labelled as being in a proprietary format.*

*Responders should provide a narrative response to the left

1.7.3.

The State desires, that if the data exports are in a proprietary format, that the data export can be converted to an industry standard, non-proprietary format.

1.7.3.1.

Do not provide price information here if additional costs are associated with this requirement. Provide price information in Attachment C, only.

1.8.

Integration with external systems

1.8.1.

The proposed solution will be expected to be compatible with Microsoft products and Epicor Kinetic for importing data and pricing.

1.8.2.

The proposed solution will be expected to be compatible with and communicate with EFI PrintSmith. Note: EFI PrintSmith is used for creating cost estimates.

Implementation

2.1.

System Transition (Conversion)

2.1.1.

The responder is responsible for customizations and any and all conversions necessary to convert all of MINNCOR’s current products (variable or static) to make them compatible with the proposed solution’s format.

2.1.2.

The proposed solution will be expected to allow MINNCOR to upload previous transaction order history data to the solution and have that information accessible and usable by MINNCOR and Customers.

2.1.3.

The proposed solution will be expected to allow MINNCOR to upload master product information, including photos, pricing, variable specification, and inventory levels, into the solution and have that information accessible and usable by MINNCOR and Customers.

2.1.4.

The proposed solution will be expected to allow MINNCOR to upload Production and Customer saved reports, into the solution and have that information accessible and usable by MINNCOR and Customers.

2.1.5.

The responder is responsible to convert all of MINNCOR’s existing customer profiles (e.g. account information, addresses, variable product specifications, etc.).

2.2.

Development and Testing

2.2.1.

Vendor will be expected to work closely with the State-assigned contact resource. The Vendor will be expected to assign a contact resource to work with the State who shall be available to answer questions and provide information as required by the State. The Vendor will be expected to also assign a member of the Vendor's Quality Assurance team or a Project Manager to MINNCOR to facilitate any conversion.

2.2.2.

Vendor will be expected to have a documented implementation plan that includes testing the site. Vendor will be expected to conduct thorough internal testing before releasing work to the State for further testing. The Vendor will make the site live only after it has been tested by MINNCOR, and MINNCOR is satisfied with the look and functionality of the site.

2.2.2.1.

Please describe the implementation plan, including any and all testing that is done internally and by MINNCOR:*

*Responders should provide a narrative response to the left

2.3.

Training and Help Resources

2.3.1.

Vendor will be expected to provide training on the function of MINNCOR’s site specific to MINNCOR’s training needs.

2.3.1.1.

Where is the training provided?*

*Responders should provide a narrative response to the left

2.3.1.2.

What resources are necessary to conduct a training class?*

*Responders should provide a narrative response to the left

2.3.1.3.

Describe what is included in your user training.*

*Responders should provide a narrative response to the left

2.3.1.4.

Describe a typical training session and include a sample training schedule or agenda.*

*Responders should provide a narrative response to the left

2.3.1.5.

Give a detailed description of your proposed plan and method for training, including group size. Will be expected to include written or on-line documentation.*

*Responders should provide a narrative response to the left

2.3.1.6.

Describe any additional advanced or refresher training.*

*Responders should provide a narrative response to the left

2.3.1.6.1.

Provide a description of each additional training that is available to the State, including group size and location.*

*Responders should provide a narrative response to the left

2.3.2.

Vendor will be expected to provide an online knowledge base and training videos/materials/documents allowing MINNCOR staff to research solutions and or train at any time

2.3.2.1.

If yes, provide detail, and provide documentation or a URL:*

*Responders should provide a narrative response to the left

System Administration

3.1.

Page Content and Administration

3.1.1.

Site Design for Customer Interface

3.1.1.1.

Vendor will be expected to utilize a Stylesheet to incorporate the logo files and design guidelines/input/mock-ups provided by MINNCOR for the look and feel of the site theme. See Attachment E Minnesota State Brand Style Guide (2018).

3.1.1.2.

Vendor will be expected to provide MINNCOR with options to customize the Customer Interface, to be used by MINNCOR at its discretion, to alter the overall look and feel of the buyer shopping experience.

3.1.1.3.

The proposed solution will be expected to allow MINNCOR to build and upload product templates, static and variable data, into the solution.

3.1.1.3.1.

Describe how a product template is built and uploaded onto the storefront:*

*Responders should provide a narrative response to the left

3.1.1.4.

The State desires that templates can be built without an internet connection.

3.1.1.5.

The State’s current system uses PageFlex. The State desires that the proposed system work with PageFlex to provide MINNCOR the ability to transfer current design files into the system.

3.1.1.5.1.

Provide information on what the process of transferring data would entail and an approximate timeline for the conversion.*

*Responders should provide a narrative response to the left

3.1.1.6.

The proposed solution will be expected to allow MINNCOR to maintain product listings (aka catalogs) that are specific to Companies and User Groups.

3.1.1.6.1.

The following is an example hierarchy that could be implemented in a Company’s product listing:

· Brochures

· Business Stationery

· Business Cards, including versions for employees, mid-managers, and upper management

· Letterhead

· Envelopes

· Forms

· Standard Forms

· Application Forms

· Registration Forms (in-state and out-of-state)

· Absentee Forms

3.1.2.

Reference Table Maintenance

3.1.2.1.

The system will be expected to provide a means for an authorized user to add drop down lists fields to forms created in the system.

3.1.2.2.

The system will be expected to provide a means to update values (Add, Edit, Delete) contained within reference tables within the system. These values will appear in drop down lists contained on various forms within the system.

3.2.

Product Listing – Creation and Maintenance

3.2.1.

Content Creation – Static products

3.2.1.1.

The proposed solution will be expected to allow MINNCOR to offer Customers static products. This includes both print and non-print (e.g. clothing) products.

3.2.1.2.

The proposed solution will be expected to allow the Customer to customize static products without MINNCOR staff assistance through category drop-downs (e.g., paper, binding, folding, hole-punches, hard copy proof, fabric, logo options, etc.).

3.2.1.3.

The proposed solution will be expected to provide a large text box (at least 800 characters) for comments to allow customers to provide directions to MINNCOR for production.

3.2.1.4.

The proposed solution will be expected to provide a function to allow customers to upload files.

3.2.2.

Content Creation – Variable data

3.2.2.1.

The proposed solution will be expected to make variable data products available to the Customer.

3.2.2.2.

The proposed solution will be expected to offer variable data content creation using flexible design templates. Flexible design templates are created, managed, and uploaded through MINNCOR.

3.2.2.3.

The proposed solution will be expected to work with Adobe Design formatting programs and criteria, specifically InDesign.

3.2.2.4.

Variable data product files submitted for order will be expected to be compiled on an FTP site for easy downloading by MINNCOR staff.

3.2.2.5.

The proposed solution must, for variable data products, include category drop-downs for more advanced printing requirements. An example is a booklet with options for binding, size, and paper with corresponding pre-entered options.

3.3.

Customized Proofs

3.3.1.

The proposed solution will be expected to automatically generate a proof of Customer’s order.

3.4.

Pricing

3.4.1.

The proposed solution will be expected to allow MINNCOR to set prices and price breaks for higher quantity orders.

3.4.2.

The proposed solution will be expected to have pricing visible and available to a Customer during the order process, so that a Customer does not need to wait until the shopping cart phase to see prices.

3.4.3.

The proposed solution will be expected to provide the ability for pricing markups based on variable options (e.g. clothing sizes).

3.4.4.

The proposed solution will be expected to provide pricing for shipping options.

3.4.5.

The proposed solution will be expected to provide the ability to apply sales tax or omit sales tax based on customer tax exempt status.

3.5.

Product Images – Creation and Maintenance

3.5.1.

The system will be expected to provide a means to create (or upload) and maintain product images. Note: MINNCOR currently edits product images in Adobe Photoshop prior to uploading. The current file formats include JPEG, GIF or PNG.

3.5.1.1

Describe the file types allowed for uploading product images and any other features the software provides for creating product images:*

*Responders should provide a narrative response to the left

3.6.

Fulfillment Operations and Inventory Levels

3.6.1.

The system will be expected to provide a means to track the following components of product inventory

3.6.1.1.

Product ID

3.6.1.2.

Product Name

3.6.1.3.

Company Associated with the Product

3.6.1.4.

Product Price

3.6.1.5.

Product Quantity on Hand

3.6.1.6.

Product Description

3.6.1.7.

Automated Product Supplier Assignment

3.6.1.8.

Re-Order Point

3.6.2.

The proposed solution will be expected to have the ability to track inventory levels of static products.

3.6.3.

The proposed solution will be expected to provide a Customer the level of their static product inventory online that is updated automatically when a Customer places an order.

3.6.4.

The proposed solution will be expected to provide the ability for authorized users to manually update inventory levels.

3.6.5.

The proposed solution will be expected to provide the ability for authorized users to manually set a re-order point for an inventory item. This includes the ability to indicate that an inventory does not have a re-order point.

3.7.

Transaction History

3.7.1.

MINNCOR Staff will be expected to have the ability to search order histories for all customers and to place orders on a Customer’s behalf.

3.8.

Pre-Defined and Customized Reports

3.8.1.

The proposed solution will be expected to provide, at a minimum, the same or substantially similar, reporting options as described below:

3.8.1.1.

Applicable reports are available for MINCORR, Customers and Suppliers.

3.8.1.2.

Same or substantially similar reporting to include the following:

ORDER REPORTS

· Order Report *

· Credit Card Transactions

· Inventory Report *

· User that receives the inventory notifications

· Line Item Report *

· Delivery Turnaround Report

· Pending Approval *

· Shipment Report *

PRODUCT REPORTS

· Product Report

· Product Report – Variable Spec Report

· Product Report – Price Schedules

· Product Report – Price Breaks

· Inactive Product Usage Report

CONFIGURATIONS REPORTS

· User Report

· User Group Report

· User Cost Center Report

SPENDING REPORTS

· Spending Account Status *

· Spending Account Transaction Report *

PROMOTION REPORTS

· Coupon Status

· Coupon Transactions

· Gift Card Status

· Gift Card Transactions

* Report that is available to Customer C

3.8.1.3.

The proposed solution will be expected to provide the ability to produce the reports in a format that allows editing/filtering similar to a spreadsheet.

3.8.1.4.

Attach a copy of the reporting options available through the proposed solution.

Attach copy

3.8.2.

The proposed solution will be expected to have the ability to create customized reports for Production and Customer, including: Inventory reports, individual product sales reports, individual customer sales reports, and customer order history reports.

3.9.

Managing Notifications

3.9.1.

Vendor will be expected to offer customizable automatically generated notifications and email messages, ex: forgotten username/password, order confirmation, shipping information, inventory level low/depleted, new order received, etc.

3.10.

Managing Suppliers

3.10.1.

The system will provide a means for an authorized user to maintain (Add or Delete) Suppliers in the system.

3.11.

Managing Customers

3.11.1.

The system will provide a means for an authorized user to maintain (Add or Delete) Customers in the system.

3.12.

Managing Companies

3.12.1.

The system will provide a means for an authorized user to maintain (Add or Delete) Companies in the system.

3.12.2.

The system will provide a means for an authorized user to maintain (Add or Delete) User Groups within Companies in the system.

Supplier Accounts and Login

4.1.

Supplier Account Credentials and Security

4.1.1.

The System will provide a means to create user login id’s

4.1.2.

The system will provide a means to associate a password to access a supplier account.

4.2.

Supplier Account Components

4.2.1.

The system will provide a means to create custom user accounts that are associated with an individual person to a specific supplier.

4.2.2.

The system will be expected to provide the user access to only transactions and products assigned to the supplier.

Supplier User Interface

5.1.

The proposed solution will be expected to include a Supplier Dashboard that displays pertinent information on status of their orders. This includes messages/notifications and a summary of incoming orders (e.g. number of new orders, open, completed and cancelled).

5.2.

The proposed solution will be expected to automatically forward product orders to Suppliers as assigned by MINNCOR.

5.3.

The proposed solution will be expected to allow MINNCOR to manually direct product orders to Suppliers because not all product orders will have an assigned Supplier.

5.4.

The proposed solution will be expected to allow MINNCOR to re-direct or override an automatically forwarded product order to a different supplier when deemed appropriate.

5.5.

The proposed solution will be expected to allow MINNCOR to access, alter, and monitor orders that have been directed to a Supplier for processing.

5.6.

The proposed solution will be expected to provide each Supplier with their own online interface to manage orders, inventory, and shipments.

5.7.

The proposed solution will be expected to not allow other external Suppliers to view different supplier information including orders, inventory and shipments.

5.8

The proposed solution will be expected to provide the ability for the Supplier to print the orders (pick lists).

5.9

The proposed solution will be expected to provide the ability for the Supplier to update the status of the order.

5.10

The proposed solution will be expected to provide the ability for orders with multiple line items to have line items directed to different suppliers.

Customer Accounts and Login

6.1.

Customer Account Credentials and Security

6.1.1.

The System will provide a means to create user login id’s.

6.1.2.

The system will provide a means to associate a password to access a customer account.

6.1.3.

The system will provide a means to associate a customer account with an established Company stored in the system.

6.1.4.

The system will provide a means for an Administrator to set permissions per Company to allow (or not allow) users to setup their own user account within an established Company account. Note: currently there are only certain companies where users are allowed to setup their own user account. Others require user account creation by MNCORR Administrators.

6.1.4.

The system will be expected to provide the ability for self-service password resets (i.e. forgotten password)

6.1.5.

The system will be expected to provide the ability for Administrators to manually reset a user’s password.

6.2.

Customer Account Components

6.2.1.

The system will provide a means to create custom user accounts that are associated with an individual person in a specific Company and User Group.

6.2.2.

The system will be expected to provide customer access to only their Company and User Group’s products.

6.3.

Customer Account History

6.3.1.

The system will provide a means to review customer accounts history (payments, balances, etc.).

Note: This is currently managed in Salesforce. MINCORR would like the option to manage this information in the eCommerce system.

Customer User Interface

7.1.

Customer Dashboard

7.1.1.

The proposed solution will be expected to include a Customer Dashboard that displays pertinent information on status of their orders. This includes messages/notifications and summary of order/quote requests status (e.g. number of orders and requests open, completed, cancelled).

7.2.

Product Search

7.2.1.

The proposed solution will be expected to include the ability for the customer to search for products in a variety of ways. Examples of searchable criteria includes product name, description, number, etc.

7.2.2.

The proposed solution will be expected to include the ability for the customer to find products by browsing the product listing in a hierarchical navigation (e.g. categories, sub-categories). The navigation should provide a breadcrumb trail or graphical location representation to inform the user where they are in the hierarchy.

7.3.

Initiating a Proof

7.3.1

The proposed solution will be expected to include the ability for the customer to generate a proof.

7.3.2.

The proposed solution will be expected to have a highly visible button for a Customer to print the automatically generated proof.

7.3.3.

The proposed solution will be expected to provide a Customer with the option of requesting a hard copy proof of their variable data product from MINNCOR.

7.3.4.

The proposed solution will be expected to require the Customer to approve the proof before they can continue the ordering process.

7.4.

Initiating a Quote

7.4.1

The proposed solution will be expected to include the ability for the customer to request a quote.

7.4.1.1

The proposed solution will be expected to provide data entry fields for the information needed to generate a quote.

7.4.1.2

The proposed solution will be expected to provide the ability for a customer to upload files related to the quote request.

7.4.1.3

The proposed solution will be expected to provide the ability for a customer and the MINNCOR staff to exchange communication/questions regarding the quote request.

7.4.2

The proposed solution will be expected to provide a method to submit the quote to the customer.

7.4.3

The proposed solution will be expected to provide the ability for the customer to accept or reject a quote.

7.4.4

The proposed solution will be expected to provide the ability for an accepted quote to generate an order.

7.5.

Initiating an Order

7.5.1.

Ordering

7.5.1.1.

The proposed solution will be expected to allow Customers to search their own order history and be able to reorder past orders. Including the ability to search for previous and current orders in various ways. Examples of searchable criteria include: PO number, bill to address, ship to address, company, division/location within a company, buyer, date range, and product.

7.5.1.2.

The proposed solution will be expected to allow Customers to edit a past order to create a new order.

7.5.1.3.

The proposed solution will be expected to send MINNCOR a production-ready PDF file of the variable data template product when Customer submits an order.

Note: this currently is sent to an FTP site.

7.5.1.4.

The proposed solution will be expected to provide a shopping cart feature and allow the user to add multiple items to the cart.

7.5.2.

Shipping Information

7.5.2.1.

The proposed solution will be expected to allow the Administrator to customize (per Company) the “Ship To” information data fields displayed and designate which ones are required.

7.5.2.2.

The proposed solution will be expected to allow a Customer to save “Ship To” addresses.

7.5.2.3.

The proposed solution will be expected to provide, for subsequent orders, a Customer with a drop-down menu of all saved “Ship To” addresses.

7.5.2.4.

The proposed solution will be expected to provide shipping options (e.g. expedited, different delivery providers, etc.).

7.5.3.

Billing Information

7.5.3.1.

The proposed solution will be expected to allow the Administrator to customize (per Company) the billing information data fields displayed and designate which ones are required (e.g. Purchase Order number).

7.5.3.2.

The proposed solution will be expected to allow a Customer to save “Bill To” addresses.

7.5.3.3.

The proposed solution will be expected to provide, for subsequent orders, a Customer with a drop-down menu of all saved “Bill To” addresses.

7.5.3.4.

The proposed solution will be expected to allow for various payment methods including purchase order and credit card.

7.5.4.

Order Confirmation

7.5.4.1.

The proposed solution will be expected to provide a function for the user to review and confirm their order.

7.6.

Customer Notifications

7.6.1.

Notification of Order Submittal

7.6.1.1.

The proposed solution will be expected to automatically generate a notification to the Customer confirming the order was submitted.

7.6.2.

Notification of Order Shipping

7.6.2.1.

The proposed solution will be expected to automatically generate a notification to the Customer confirming the order was shipped and include any available tracking information.

7.6.3.

Low or Depleted Inventory Automatic Notifications

7.6.3.1.

The proposed solution will be expected to allow a Customer to set a re-order level.

7.6.3.1.1.

Describe how this is accomplished and provide a sample notification.*

*Responders should provide a narrative response to the left

7.6.3.2.

The proposed solution will be expected to automatically notify a Customer when their static product inventory level has reached the re-order level.

7.6.3.2.1.

Describe how this is accomplished and provide a sample notification.*

*Responders should provide a narrative response to the left

7.6.3.3.

The proposed solution will be expected to automatically notify a Customer when their static product inventory level has been depleted.

7.6.3.3.1.

Describe how this is accomplished and provide a sample notification.*

*Responders should provide a narrative response to the left

7.6.3.4.

Inventory notifications will be expected to also be sent to MINNCOR via email.

7.6.3.4.1.

Describe how this is accomplished and provide a sample notification.*

*Responders should provide a narrative response to the left

7.7

Business to Consumer (B2C) Capabilities

7.7.1

The solution will be expected to fully support Business to Consumer (B2C) eCommerce transactions, including secure public‑facing purchasing, consumer account creation, guest checkout, PCI‑compliant payment processing, tax calculation, shipping configuration, order tracking, and automated customer notifications

7.7.2

The system will be expected to allow MINNCOR to configure consumer‑specific pricing, promotions, and product availability rules.

7.7.3

All B2C transaction data will be expected to integrate in real time with Epicor Kinetic for inventory, financial reconciliation, and order management.

7.7.4

Describe your B2C capability details

*Responders should provide a narrative response to the left

File details come from the government source that posted it. Updated Jun 30, 2026.