Working online demonstration / fictional data
Sevrim DeskContext, responsibility and history in one place.
A graphite and blue workspace connected to an online demo server: persistent requests, four stages, access roles and a deliverables portal.
An online demonstration with fictional accounts and data shared by visitors. Use fictional data only. It is not a production system and sends no emails or notifications.
Sevrim Desk / interface illustration
SEVRIM DESKFICTIONAL DATA
Every request, in its stage.NewEXAMPLE / 01Salon websiteAssigned · Demo teamHistory available
QualifiedEXAMPLE / 02Service applicationAssigned · Demo teamHistory available
ProposalEXAMPLE / 03Quote automationAssigned · Demo teamHistory available
ConfirmedEXAMPLE / 04Deliverables portalAssigned · Demo teamHistory available
View a screenshot of the local lab
THE NEED WE EXPLORE
Where the concept starts
When information lives in separate messages and spreadsheets, teams lose a request’s context. The lab explores a shared journey from a request and its owner to a deliverable, feedback and approval.
DESIGN DECISIONS
Why it looks and works this way
Stage and responsibility stay visible
New, Qualified, Proposal and Confirmed make the journey explicit. Filters and assigned team members keep context close, with no mandatory dragging.
Each role has a perspective
Owners, operators and clients work within server-enforced permissions. The portal separates deliverables and client approval from request administration.
Confirmation reflects the save
The interface confirms an operation after the server responds. History, versions and error messages explain changes and situations that need another attempt.
THE LOCAL LAB
What you can try now
- Sign in with a demonstration owner or operator account and create a fictional request.
- Change its stage and assigned team member, search and inspect the history; reload the page to retrieve saved data.
- Open the portal and explore deliverables and the client perspective for feedback and approval of a version.
IMPLEMENTATION AND LIMITS
What is implemented
- A React and TypeScript interface with a Node API and a separate online demonstration SQLite database. Saved data survives page reloads and is shared by visitors.
- Authentication with scrypt password hashing, sessions, role and organisation permissions, change history and versions for concurrent changes.
- Fictional accounts, organisations, requests and projects. Visitors use the same demo accounts and can change the fictional data. No emails or notifications are sent.
FOR A REAL PROJECT
What needs defining and connecting
These are project requirements, not features the demonstration claims to provide.
- Business rules, real accounts and their access lifecycle need defining and verifying for the client’s organisation.
- Hosting, secrets, backup and restore, monitoring and operating responsibilities in a real environment.
- External integrations, notifications, data policies and specific scenarios require separate implementation and validation.