Prospective customer
Submits a guided request and attaches relevant technical files.
Product Demo · Software & Systems
Industrial RFQ intake and internal review
A working demonstration of how structured intake, file collection, qualification, ownership, and status can replace incomplete requests scattered across email.
This is not a customer case study. Soultware built this system to demonstrate product and engineering capability against a representative industrial sales problem.
Problem being demonstrated
Incomplete intake creates work before estimating can begin
This is a representative business scenario, not a claim about a specific customer. The demo explores what happens when the information needed to qualify industrial work has no consistent entry point.
- Quote requests arrive without the specifications needed for review.
- Drawings and supporting files are spread across email threads.
- Engineering spends time asking for information that could have been required at intake.
- Ownership and qualification status are difficult to see.
- Sales and engineering may qualify similar requests differently.
Representative users
One request, viewed by people with different responsibilities
Sales or estimating
Reviews commercial context, completeness, priority, and ownership.
Engineering reviewer
Sees the technical answers and files needed for an initial review.
Operations or admin
Maintains the request state and coordinates the next action.
These are representative roles. They are not described as users from a Soultware client.
Workflow
A complete path from customer request to internal review
- 01
Customer submits a structured request.
- 02
Required and conditional information is validated.
- 03
Files and specifications are attached to the request.
- 04
The request enters an internal review view.
- 05
Staff can qualify it, assign ownership, add notes, and manage status.
- 06
CRM or ERP integration is scoped separately when it provides enough value.
Product walkthrough
The working demo shows both sides of the handoff
Customer intake
Conditional questions collect company, contact, project, timing, budget, technical requirements, and files before submission.
Internal review
The reviewer can inspect answers and attachments, change qualification state, set priority and ownership, add a note, and print a summary.
Architecture and implementation
Technical claims tied to code that exists in the demo
Guided intake and validation
Project type changes which questions appear. The server validates the submitted fields with a defined schema instead of trusting the browser.
Workspace-scoped records
Requests, attachments, notes, and activity are stored in relational tables and filtered by the visitor demo workspace.
File handling
The demo accepts up to five files, enforces a 10 MB limit per file and an extension allowlist, and stores objects separately from request records.
Bounded API operations
Public submission, internal review updates, notes, and attachment retrieval use separate route handlers with server-side checks.
Disposable demo sessions
An HTTP-only cookie identifies an isolated demo workspace. Demo records expire after 48 hours and cleanup removes database rows and stored files.
Deployment and tests
The application is packaged for Cloudflare Workers with D1 and R2 bindings. Automated tests cover validation boundaries and the customer-to-reviewer path.
Implemented in this demo
- Conditional intake and server-side validation
- Workspace-isolated RFQ, attachment, note, and activity records
- File size, count, and extension checks
- Status, priority, assignee, notes, and attachment download
- 48-hour demo cleanup
- Validation and end-to-end workflow tests
Defined for a production implementation
- Identity provider, authentication, organization membership, and role permissions
- Exact field configuration, qualification rules, statuses, and approval boundaries
- CRM, ERP, email, document, or quoting integrations and their failure handling
- File scanning, content inspection, retention, backup, recovery, and audit requirements
- Hosting region, monitoring, incident response, availability, and support expectations
- Privacy, regulatory, contractual, and organization-specific compliance controls
Engineering decisions
The interface follows explicit operational choices
Make required fields configurable
Machine builders and integrators quote different work. The intake model should allow questions and requirements to change without rewriting the entire application.
Keep files inside the request record
A reviewer should not reconcile attachments from separate email threads. File access belongs beside the answers, status, and activity for that RFQ.
Model qualification state explicitly
A visible state makes “new,” “needs information,” “qualified,” and “engineering review” distinguishable and gives the team one shared view of what happens next.
Bound external integrations
The RFQ system should own intake and qualification. A CRM or ERP connection should exchange only agreed records and statuses through a documented boundary.
Define permissions per organization
The demo uses an isolated visitor workspace, not production authentication. A real implementation would map actions and data visibility to actual sales, engineering, admin, customer, and organization roles.
Limitations
A demonstration system is not a production security model
The demo has no production identity provider or role-based authorization, no real CRM or ERP connection, and no malware scanning or organization-specific compliance controls. Its cookie-based workspace isolation exists to keep visitors’ demo records separate.
Security, integrations, permissions, hosting, retention, backup, observability, support, and compliance requirements vary and are scoped for each production implementation.
See the proof first
Explore the request-to-review flow, then decide whether a conversation is useful.
In a 15-minute review, we can map where RFQ information enters your process, identify the biggest qualification gaps, and decide whether custom software is worth exploring.
Back to Work