Washington State Department of Commerce
Solicitation Management System (SMS)
iBi Nexus designed and deployed the portal for solicitation and RFP/RFX-related workflows.
The need
Public-sector solicitations involve documents, review and communication around each opportunity. A portal brings that work into one application.
The delivered system
iBi Nexus designed and deployed the Solicitation Management System portal. The portal supports solicitation and RFP/RFX-related workflows.
Inspect a conceptual solicitation-workflow example
Conceptual public workflow
Information, review and communication need a clear handoff.
Solicitation work brings documents, responsible decisions and public communication together. This example explains those relationships alongside the confirmed project.
Request context · clarification remains open
Supporting document needs clarification
- Role
- Requesting team
- Information
- Purpose, supporting documents and review owner
- Who takes the next step
- Reviewer checks whether the information is ready.
- Requesting team supplies the brief
- Reviewer returns the document question
- Publication remains pending
- Coordinator communicates response/status
Request context
A clear brief names its purpose, evidence and responsible reviewer.
The missing document returns to the requesting team. Publication remains pending.
Explore workflow engineering →Try the connected process →Project status
Fully deployed and operational.
The Washington State Department of Commerce Solicitation Management System portal is operational for solicitation and RFP/RFX-related workflows.
Try an illustrative workflow decision →Connect this context to workflow engineering →First-party project / Current public website
A website that shows how we engineer.
We wanted this website to explain what we do through examples visitors can try. That meant building clear pages and interactive demonstrations that work across screen sizes.
Six services, interactive examples and a clear way to discuss your project.
From an idea to a tested website
- Direction + promptsOur engineers define what the site should explain and how it should work. AI helps us explore designs and refine the code.
- Implementation + judgmentWe built the website with React, Next.js and TypeScript, with animation and diagrams to explain the examples. Engineers reviewed and corrected the results.
- Behavior + deliveryWe test layouts, keyboard navigation, interactions and motion, alongside automated code checks. Changes must pass the project’s checks before production deployment.
Current status: live at www.ibinexus.com.
See one decision behind this website
Decorative signal travel depends on viewport visibility, actual document visibility and the live reduced-motion preference. The same diagram remains readable without animation. This excerpt comes from the shared implementation in this website’s repository.
const shouldAnimate = movement && documentVisible && visible;
// Travel and opacity share the same recurring schedule.
// Specific action transfers remain finite.What AI contributed
AI helped explore design ideas and refine the implementation, with engineers directing the work throughout.
What our engineers are responsible for
Our engineers remain responsible for the design, code review, factual claims, interactions, testing and deployment. This website shows that approach in practice.
Institutional work
University of Washington
iBi Nexus has completed an ERPO-related project and other smaller projects within the University of Washington environment.
Office automation / Product work
The document arrived. The work around it should be easier to follow.
iBi Nexus has built office automation products.
When information is split across an inbox, a record and a message, it can be unclear who should act next. Follow one document through a connected office workspace.
Conceptual office workflow · D-204
D-204 / R-204 · No person assigned to the next step. Next: name who will follow up. Document, record and update share this context.
Service record
R-204 · office display request
D-204 / Service-request attachment
Meeting-room display
- Related request
- R-204
- Location
- North office
- Source
- Service desk attachment
- Document relationship
- D-204 attached to R-204
- Location
- North office · from D-204
- Person responsible
- No person assigned to the next step
- Request status
- Waiting for someone to handle the next step
Inbox
Arrival has a destination
Document D-204 stays linked to its request. The inbox shows its arrival; the request record holds the current status.
Associated → R-204Message / update
The handoff is readable
R-204 is waiting for a next owner. D-204 is linked and available.
The message uses the request’s current status, so it does not create a conflicting version.
Keep the source, the owner and the state together.
The attachment keeps its original details. Assigning a responsible person updates both the request and the message.
- 01 / SourceInformation stays with its document.
You can view document D-204 alongside the information in request R-204.
- 02 / ResponsibilityThe next person is named.
The sample assignment gives the coordinator a clear follow-up.
- 03 / StateAn update tells the same story.
The connected message reflects the record, not another copy.
What should your next working application make possible?
Tell us about the task or system you want to build, connect or improve. We can help identify a practical starting point.
Discuss a similar engineering need →