Product requirements document24 August 2026 · Design handoff · Version 2.1
Resk Intelligence
A complete redesign of Resk as the back-office intelligence and operating system for business owners, with one shared product foundation and two genuinely different experiences.
Restaurant IntelligenceService readiness, covers, prep, food cost, waste, labor, purchasing, and menu margin.
Resk becomes the place where an owner understands the business, makes decisions, coordinates action, and sees whether the outcome was achieved.
What Resk Intelligence owns
The daily operating brief and priority order.
Forecasts, exceptions, explanations, and comparisons.
Proposed work, approvals, assignments, and audit history.
Cross-system coordination and outcome verification.
Deep back-office records that support the decision.
What it does not try to own
Live order entry, tables, kitchen display, checkout, packing, or terminal flows.
A generic chatbot as the main home screen.
A replacement for every POS, ecommerce, booking, payroll, or accounting system.
A blended Restaurant and Retail dashboard with generic cards.
Model-generated business calculations that bypass canonical Restaurant or Retail services.
Five questions the product must answer
What changed?The material change since the owner last checked, not a wall of undifferentiated alerts.
What matters now?The highest-impact issue, opportunity, or deadline for this business and location.
What decision is required?The exact choice, evidence, authority, and risk that needs human judgment.
What did Resk do?The work Resk prepared, coordinated, or executed, including the systems and records touched.
Did it work?The read-back, settlement, record change, or operational evidence that proves the outcome.
Primary users
Single-location owners, multi-location operators, restaurant general managers, retail store managers, and finance or back-office managers.
Adoption promise
A restaurant or retailer can keep its existing front desk and still adopt Resk for intelligence, planning, back-office work, and verified outcomes. CloudPOS is an available execution surface, not an onboarding requirement.
02
Research and design audit
The redesign is grounded in the current Resk product, the supplied Marble screens, Nory's connected restaurant model, Restaurant365's back-office breadth, and modern retail inventory systems. The goal is to borrow the strongest product principles without copying another company's interface.
224Current route declarations that need an owner and migration decision.
22Potentially visible primary navigation definitions competing for attention.
26Restaurant routes inside the current application.
61Retail routes inside the current application.
Reference
What is strong
What Resk should do differently
Current Resk
The Operator review detail already shows proposed action, affected records, source freshness, confidence, risk, approval, and rollback. This is the strongest foundation in the current product.
Stop exposing internal module structure. Bring the trust model forward and organize the product around owner jobs.
Marble
A clear restaurant back-of-house category, work described in restaurant language, visible agent progress, and retained human sign-off.
Do not use an empty chat home, icon-only navigation, pale low-contrast copy, repetitive approval cards, or conventional dashboards disconnected from action and outcome.
Nory
Forecasting, inventory, workforce, payroll, and business intelligence are connected through a shared demand model.
Use the connected operating principle, not Nory's interface. Resk must also work for Retail and for businesses retaining another POS.
Restaurant365
Mature coverage across accounting, inventory, purchasing, workforce, payroll, forecasting, logs, tasks, and integrations.
Preserve deep records without recreating a departmental navigation maze.
Resolve the experience from the retailer's operating profile. A showroom, beauty store, grocer, and ecommerce brand should not receive identical records or priorities.
01Current Resk: the navigation is fragmented, but the review detail is a valuable trust pattern. The redesign should keep the evidence, risk, authority, and rollback depth while simplifying the shell.
02Marble chat: a clear AI entry, but a weak default work surface. Owners should not need to invent the prompt before Resk tells them what matters.03Marble approvals: human sign-off is visible, but decision evidence is too shallow. Resk should show impact, affected records, source freshness, risk, reversibility, and verification before approval.
04Marble forecasts: coherent vertical forecasting, but conventional dashboard composition. Resk should connect every important variance to the work and verified outcome it creates.05Marble records: useful back-office depth, but direct administration can imply full replacement. Resk must clearly distinguish source records, native records, and connected-system ownership.
03
One product model
The two business pathways share the same mental model. The content inside that model changes completely according to the selected business.
TodayThe operating brief, material changes, decisions, completed work, and next horizon.
WorkThe full lifecycle of detected, prepared, awaiting decision, executing, verifying, verified, and failed work.
PerformanceTrends, comparisons, forecasts, variances, drivers, and verified business outcomes.
RecordsDeep vertical administration and source-linked operational records, organized by business language.
ConnectSystems, permissions, read/write/verify capability, synchronization, freshness, and connector health.
The business-aware experience resolver
The vertical is a business property, not a decorative toggle. When a user switches business context, the product resolves the appropriate content from all of the following:
Selected business
Restaurant or Retail vertical
Operational profile
Enabled modules and plan
Connected systems
Read, write, and verify capability
User role and authority
Location or portfolio scope
Data freshness and confidence
Current service or trading horizon
Open work and deadlines
Recent verified outcomes
The shared work lifecycle
Every work type follows the same lifecycle so users learn one trust model, even though the domain content changes.
DetectedA material change, risk, or opportunity is identified.
PreparedEvidence and a recommended action are assembled.
DecisionAn authorized person approves, revises, or declines.
ExecutingResk or an assigned person carries out the action.
VerifyingResk reads back the target system or awaits evidence.
VerifiedThe requested state and outcome are confirmed.
FailedThe failure, uncertainty, and safe next action are explicit.
04
Two business pathways
The shell is shared. The operational hierarchy is not. A restaurant and a retailer must recognize their own business immediately, before reading the business name.
Restaurant
Know what the restaurant needs before service, control food and labor cost during the week, and close the loop on every back-office action.
Forecast covers and revenue
Service readiness and prep
Ingredient and menu availability
Food cost, waste, and labor variance
Purchasing, suppliers, and invoices
Retail
Keep the right stock in the right place, protect margin and cash, and coordinate replenishment across stores and channels.
Sales pace and demand
Stockout and overstock risk
Reorder and transfer decisions
Sell-through, aged stock, and shrinkage
Purchasing, receiving, and returns
Experience contract
Restaurant Intelligence
Retail Intelligence
Primary horizon
Next service period, trading day, and weekly cost plan.
Current trading pace, replenishment window, and stock investment horizon.
Demand unit
Covers, bookings, menu items, daypart, and service period.
Units, variants, category, store, channel, and lead time.
Core cost question
Food cost and labor against forecast demand.
Gross margin, markdown, shrinkage, and cash tied up in stock.
Highest-frequency work
Prep, purchasing, availability, waste, schedule, and supplier exceptions.
Reorder, transfer, receiving, stock count, markdown, and return exceptions.
The first viewport reads as an operating brief, not a grid of equal KPI cards.
One top priority with business impact and deadline.
Readiness for the next service period.
Forecast covers and revenue versus plan.
Ingredient, menu-item, prep, and supplier risk.
Labor plan and labor-cost pressure.
Food-cost, waste, and margin exceptions.
Decisions waiting and actions verified since last visit.
Work examples
Approve a purchase order, resolve an ingredient shortage, revise a prep plan, investigate food-cost variance, confirm a stock count, or assign a waste investigation.
Performance examples
Forecast accuracy, revenue versus plan, covers by daypart, labor variance, food cost, menu contribution, waste, purchasing variance, and supplier performance.
Retail Today
The first viewport reads as a trading and stock brief, ordered by cash and availability impact.
One top priority with cash, margin, or availability impact.
Sales pace and demand versus plan.
High-impact stockout and lost-sales risk.
Reorder, transfer, receiving, and supplier deadlines.
Overstock, aged stock, and markdown opportunity.
Returns, shrinkage, and stock-count anomalies.
Decisions waiting and actions verified since last visit.
Work examples
Approve a reorder, transfer stock between locations, revise a purchase order, investigate shrinkage, reconcile receiving, or review a controlled markdown.
Performance examples
Net sales, gross margin, sell-through, stock turns, availability, aged stock, markdown impact, shrinkage, returns, supplier performance, and channel contribution.
05
Information architecture
The primary navigation is deliberately small. Depth remains available, but owners do not need to understand internal Resk modules before they can understand their business.
Destination
Default composition
Critical rule
Today
Top priority, next horizon, decisions, recent verified work, and supporting evidence.
One strong hierarchy. No equal-weight card wall.
Work
Saved views for awaiting decision, assigned, executing, verifying, failed, and verified work.
Lists expose impact, deadline, source, freshness, authority, and next action.
Performance
Questions, explanations, comparisons, forecasts, and outcome history.
Every important variance can create or open exact work.
Records
Vertical record groups, deep search, source ownership, and contextual return paths.
Records support the operating model. They are not the default mental model.
Connect
System capability, health, freshness, permissions, and affected workflows.
Read, write, verify, and freshness are shown separately. Never overstate connector ability.
Ask Resk is contextual, not a separate world
Always receives
Business, vertical, location, date, and current destination.
Visible record, selected period, user role, and permissions.
Source freshness, connector capability, and open work context.
Can produce
An explanation with visible sources.
A comparison, report, or exact record retrieval.
A proposed work item that enters the normal evidence and approval lifecycle.
Navigation to the right record or destination without losing context.
The generic blank chat should not remain the default entry. Resk should be proactive first and conversational when the operator wants to investigate, explain, compare, or prepare action.
06
Trust, approval, and verification
Resk can be assertive about attention and still be careful about action. The product must make authority, evidence, reversibility, execution, and verification visible at the exact moment they matter.
Every consequential work item shows
Reason
What changed, why it matters now, the expected impact, and what happens if the owner does nothing.
Evidence
Exact sources, affected records, freshness, confidence, missing coverage, and any conflicting data.
Authority
Who can approve, whether policy approval exists, and which permission is required.
Change
The precise proposed write, target system, duplicate protection, and whether it can be revised.
Risk and rollback
Customer, financial, stock, labor, or service consequences plus a clear reversibility statement.
Outcome
Execution status, read-back evidence, verification availability, partial failure, and safe next action.
Connector capability is explicit
Read
Which records and date ranges Resk can access, including the last successful synchronization.
Write
Which actions Resk can execute in the source system and which require human handoff.
Verify
Which outcomes Resk can independently read back and which remain unverified.
Freshness
Expected cadence, current delay, stale-data effects, and the workflows affected.
Health
Authentication, permission, partial outage, last error, and recovery guidance.
State rules
Approval and execution are separate states.
Execution success never means verified outcome by itself.
Retries reconcile the previous attempt before another external write begins.
Permission, freshness, and connector limits fail closed.
Every state survives refresh, sign-out, device change, and background execution.
Cross-business and cross-location scope is checked at navigation, read, mutation, handoff, and return.
07
The front-office boundary
Resk Intelligence owns the back-office decision loop. CloudPOS or another front-office system owns live transaction and service execution.
Runs the live transaction or service flow using its own operational interface and authority.
Order entry and checkout
Tables, kitchen, packing, and terminals
Live customer-facing service
Native ecommerce or booking flow
System-of-record execution where required
Handoff contract
PrepareResk assembles the exact business, location, record, amount, item, policy, and intended action.
Declare capabilityThe product states whether it can write and verify directly or must hand off.
Open the right surfaceCloudPOS or the external system receives exact context, not a generic homepage.
Return intactThe owner returns to the same work item with context and status preserved.
Verify safelyResk reconciles the source before marking complete or allowing a retry.
08
Product requirements
The launch requirements protect the core product model. They are written as experience contracts that design and engineering can validate together.
P0 launch requirements 14 requirements
REQ-001
Business-aware pathway resolution
Resolve the full experience from business vertical, operational profile, enabled capability, role, scope, freshness, and time context. No manual visual-only pathway toggle.
REQ-002
Shared five-destination shell
Today, Work, Performance, Records, and Connect are the only primary operating destinations. Settings moves to the business or user menu.
REQ-003
Vertical-specific Today
Restaurant and Retail use different priorities, metrics, language, examples, work types, empty states, and supporting evidence.
REQ-004
Unified Work lifecycle
All work supports durable state, ownership, deadline, evidence, decision, execution, verification, failure, and audit history.
REQ-005
Restaurant domain pack
Support service readiness, demand, prep, ingredients, menu, food cost, waste, labor, purchasing, suppliers, invoices, and bookings.
REQ-006
Retail domain pack
Support sales pace, SKU and variant availability, replenishment, transfers, purchasing, receiving, aged stock, markdown, shrinkage, returns, and margin.
REQ-007
Evidence-first action review
Show reason, impact, exact change, source, freshness, affected records, authority, risk, reversibility, audit, and verification method before consequential action.
REQ-008
Connector capability transparency
Declare read, write, verify, freshness, health, and affected workflows separately for every connected system.
REQ-009
CloudPOS and external-system handoff
Open the right operational surface with exact context, preserve return state, reconcile the result, and prevent duplicate execution.
REQ-010
Performance-to-work linkage
Every material variance or forecast can open the records, explanation, existing work, or preparation flow that addresses it.
REQ-011
Contextual Ask Resk
Ask Resk receives visible business context, uses vertical language, cites sources, and sends proposed action through the normal Work lifecycle.
REQ-012
Multi-location and portfolio scope
Scope is always visible. Owners can compare and switch locations without mixing authority, data, measures, or work.
REQ-013
Route disposition and legacy migration
All 224 current routes receive a destination, contextual deep link, CloudPOS handoff, settings move, redirect, or retirement decision before removal.
REQ-014
Accessible and responsive operation
Meet WCAG 2.2 AA for the five destinations and core journeys across desktop, tablet, mobile review, keyboard, zoom, screen reader, and reduced motion.
P1 after pathway validation 5 requirements
REQ-015
Saved operating views
Owners can save relevant filters and portfolio views without creating competing dashboards.
REQ-016
Role-aware daily brief
Priority order and detail adapt to authority, responsibility, and location scope.
REQ-017
Team assignment and completion evidence
Assigned work includes owner, due time, proof, acceptance, and escalation.
REQ-018
Proactive brief delivery
Send useful, role-aware summaries without making email or chat the canonical work surface.
REQ-019
Outcome history
Connect actions to verified operational results without presenting model estimates as financial proof.
P2 future extensions 2 requirements
REQ-020
Cross-business portfolio overview
Give multi-business owners a careful high-level view while keeping Restaurant and Retail metrics separate.
REQ-021
Scenario planning
Compare controlled staffing, purchasing, pricing, transfer, or markdown scenarios before creating work.
Non-functional launch standard
Performance
Useful shell and cached brief within 2 seconds on typical business broadband. Fresh data can update without unexpected layout reordering.
Reliability
Durable decisions, observable background execution, explicit degradation, idempotent writes, and state that survives refresh and device changes.
Security
Server-side authority, least-privilege data access, business and location isolation, and audit history with actor, source, exact change, result, and time.
Accessibility
Semantic landmarks and controls, readable chart alternatives, visible focus, error recovery, non-color state cues, and 200 percent zoom support.
Responsive behavior
Desktop for dense operations; tablet for counts, receiving, schedules, and approvals; mobile for brief review, assignment, approval, and verification status.
Data ownership
Restaurant and Retail services remain canonical for domain records and calculations. Operator coordinates and explains through their contracts.
09
Brief for the product designer
Design a colorful, confident operating system with a serious hierarchy. Extend Resk's public black, warm white, and orange brand into the product, then let Restaurant and Retail express different operating contexts without becoming separate brands.
Core ink #1A1A1A
Shared surface #FAF4F0
Resk action + Restaurant #E85D2F
Retail secondary #2E5F91
Attention #EEE4CA
Visual character
Operational, warm, legible, and decisive.
Shared charcoal, warm-white, and Resk-orange shell across both pathways.
Restaurant uses Resk orange prominently for pathway emphasis, selected states, and operational signatures.
Retail uses blue as a secondary context and data color; shared navigation, approvals, and primary actions remain Resk orange.
Warm sand or amber is reserved for attention states that still include a label, icon, or written explanation.
Typography, navigation, spacing, controls, and shared surfaces remain consistent across Restaurant and Retail.
One dominant issue per view, followed by decisions, outcomes, and evidence.
Color indicates business context and meaning, never decoration alone.
Dense data is progressively disclosed without hiding the evidence needed for trust.
Avoid
A pale beige Marble imitation.
A wall of equal cards or generic KPI boxes.
Icon-only primary navigation.
Chat as the only visible intelligence surface.
Low-contrast labels, ornamental gradients, excessive status chips, or color-only meaning.
A green foundation or any pathway color replacing the Resk orange brand and action language.
Required design deliverables
Route-disposition map for all owner-facing screens.
Restaurant external-POS, Retail external-POS, and native CloudPOS journey maps.
Shared-shell information architecture with pathway-specific content inventories.
Desktop flows for Today, Work list and detail, Performance, Records, Connect, and Ask Resk.
Restaurant and Retail home variants at identical viewport sizes.
Trust specification for evidence, approval, execution, verification, failure, and rollback.
Three materially different visual directions that satisfy this PRD.
One selected visual system with shared foundations and vertical behavior.
Responsive designs for desktop, tablet, and mobile review.
Clickable prototype covering all pilot journeys.
Accessibility annotations and content hierarchy specification.
Migration map from current routes and components to the redesigned system.
Prototype validation scenarios
S1
Restaurant before service
Identify an ingredient shortage, understand affected menu items and revenue risk, review a supplier substitution and purchase change, approve it, and see execution begin.
S2
Restaurant weekly margin review
Compare three locations, find worsening food cost, understand the drivers, assign a stock-count investigation, and later see verified findings.
S3
Retail replenishment
See a high-selling SKU at stockout risk, compare a transfer with a reorder, approve the transfer, and see inventory-system confirmation.
S4
Retail aged stock
Find stock tying up cash, compare markdown and margin tradeoffs, approve a controlled markdown, and later see verified sell-through and margin outcome.
S5
External POS onboarding
Connect an existing POS, understand what Resk can read, change, and verify, and receive a useful Today brief without enabling CloudPOS.
S6
Multi-business owner
Switch from a restaurant to a retailer. Keep the five-destination mental model while priorities, language, metrics, work, records, and color change immediately.
10
Rollout and measurement
Migrate the operating model before retiring depth. Restaurant and Retail can move independently, while the shared shell and trust patterns remain consistent.
Final product principle: Resk Intelligence is one system of attention, decision, coordinated action, and verified outcome. Restaurant and Retail share that system, but each business sees its own operating world.
