System Requirements Document for delegationdesk-task-delegation

1. Introduction

This document specifies the six-page Flowmative marketing site: one agency homepage and five customer-facing product pages for existing business software. The pages market the products; they do not rebuild the applications. The final deliverable is a ZIP of six standalone HTML files plus assets, README and manifest, openable directly from file:// and deployable to any ordinary static host.

The six pages are index.html (Flowmative agency homepage), delegationdesk.html (DelegationDesk), crm.html (Orbit CRM), inventory.html (Inventory ERP), leadflow.html (LeadFlow) and expense.html (Expense & Reimbursement). No other apps are created, and only these six pages belong in the final navigation and export.

Each product page speaks to a distinct audience with a distinct problem: DelegationDesk to owners and team leaders chasing delegated work; Orbit CRM to relationship-led sales teams whose customer context is split across messages and isolated deal lists; Inventory ERP to warehouse, purchase and operations teams who disagree about stock availability; LeadFlow to sales teams whose enquiries arrive without consistent fields, owners or next actions; and Expense & Reimbursement to employees, managers and finance teams handling claims and advances. The homepage speaks to SME owners, sales leaders, operations managers and finance teams with repetitive manual work or scattered process records, evaluating Flowmative as a custom software and automation partner.

2. System Overview

The current delivery is six anonymous, publicly reachable marketing pages. There is no application rebuild, no backend, no database, no server-side routing, no build step, and no deployment or hosting provisioning in this scope. Each page is complete standalone HTML5 with inline CSS and minimal vanilla JavaScript, semantic content present without JavaScript, and relative links to the other five files.

Every product page follows the same story shape adapted to its own visual identity: a first viewport that communicates the product, intended customer, main benefit and next action; a purposeful illustrative product visual; a concise problem/outcome narrative; three or four feature-to-benefit stories; a three-step workflow; short FAQs; and a strong closing CTA. The homepage is longer and carries brand navigation, hero, operational friction, featured product stories, the complete five-product directory, service engagement, delivery process, reasons to enquire, short FAQs and an enquiry section.

The accepted human actors are the prospective customers for each page and the prospective Flowmative agency client. Conversion is by mailto: link only. All product visuals are inline SVG or CSS and are labelled as sample data.

2a. Product Interpretation and Delivery Boundary

These are marketing surfaces, not the products. Everything on the pages describes confirmed capabilities and their business outcomes; nothing on the pages performs task management, CRM, inventory, lead or expense work.

Delivery is six portable HTML files with inline CSS and JavaScript. Each must open by double-clicking from the local filesystem and must also work on any ordinary static host. No fetch calls for local data, no JavaScript modules requiring a server, no platform-specific scripts, no 8080 injected preview scripts, telemetry, data adapters or editor dependencies in the final export. Optional images and fonts must be licensed local assets in an assets folder referenced by relative paths, with font fallbacks; temporary asset URLs are not permitted. Inline SVG and CSS are the preferred illustration method.

Access is anonymous and public on all six pages. There is no account, no login, no gated content, and no application-owned identity. The primary conversion on each product page is a mailto: link to mr.deep4k@gmail.com with a product-specific subject; the homepage's agency conversion is a mailto: link to flowmative@gmail.com. The email address is shown as selectable text on each page, and the pages never claim an email was sent merely because the mail app opened.

Current scope is the six pages. The actual applications are explicitly out of scope. The exported designs and code will be independently refined before production use. The final ZIP — six HTML files plus assets, README and manifest — is requested after all six page prompts.

Product-specific boundaries are stated on each page and are not project-wide bans: DelegationDesk reminders require background triggers and notification setup, and automatic WhatsApp API delivery is not included by default; Orbit CRM has no automatic email sync, call recording or AI forecasting claim; Inventory ERP requires physical stock checks and accurate entries, and e-invoice support covers export and acknowledgement capture without automatic portal filing or statutory compliance guarantees; LeadFlow's configured nightly sweep can flag missed follow-ups but does not imply universal automatic outbound messaging; Expense & Reimbursement records reimbursement without transferring money, and email delivery depends on permissions and configuration.

2c. Page Content and Component Coverage

index.html

Information and state

• Brand navigation with a tasteful text wordmark and a simple favicon; the referenced Flowmative Final Logo.png was not supplied, so no broken image or substitute symbol is shipped.
• Hero with a sharp customer-facing promise such as "Less chasing. Less rework. A business that flows." and a concrete subheading about custom software and automation for sales, operations and teams, stating what Flowmative builds, who benefits and the next action within the first viewport.
• A bespoke before/after process visual in which disconnected enquiry, approval and spreadsheet work becomes an owned, traceable workflow; it does not imply all five products already integrate automatically.
• Recognizable operational friction: repeated entry, owner-dependent follow-ups, slow approvals, scattered reporting — kept concise.
• Featured product stories for DelegationDesk, LeadFlow and Inventory ERP, each connecting a problem to capabilities and intended outcomes and linking to its own page, labelled as product examples rather than verified client success stories.
• Complete product collection with all five working links — delegationdesk.html, crm.html, inventory.html, leadflow.html, expense.html — grouped by customer need, with accessible filter controls welcome if useful but all items available without JavaScript.
• Service engagement covering custom applications, workflow automation and reporting, plus Google Workspace work, explaining when to customize a product versus design a workflow from scratch, without promising compatibility without discovery.
• Delivery process: discovery → process mapping → system design → build/test → handover/support, explaining what a client participates in and receives, with support scope agreed rather than unlimited by default.

• Reasons to enquire presented as an approach — business-process understanding, a visible workflow before implementation, reviewable progress, documented handover — not unsupported performance claims.
• Short FAQs on customization, working with existing tools, handover/support, and how scope and pricing are determined.
• Enquiry section with direct email, the GitHub link https://github.com/deep4kk, the LinkedIn link https://linkedin.com/in/deep4kk, and the brief "Tell us what your team keeps doing by hand."
• A small credibility section may mention technologies without making the homepage read like a developer résumé; product-specific technology claims must match the briefs, which describe Apps Script/Sheets applications.

Primary and supporting actions

• Primary agency CTA: "Discuss your project" linking to mailto:flowmative@gmail.com?subject=Flowmative%20project%20enquiry.
• Secondary CTA: "Explore the systems", moving to the product collection.
• Supporting actions: following a featured product story link; filtering the product collection; following a product page link; following the GitHub or LinkedIn link; copying the agency email shown as selectable text.
• No form that pretends to submit, no fake booking, no payment feature, no coming-soon alert.

Domain entities

• Flowmative service: custom web applications, business systems, workflow automation, Google Workspace automation, reporting dashboards.
• Product example: DelegationDesk (task ownership and follow-up), Orbit CRM (accounts, contacts, deals and activities), Inventory ERP (stock, purchasing and warehouse records), LeadFlow (configurable lead capture, assignment and follow-up), Expense (claims, approvals and reimbursement records).
• Delivery stage: discovery, process mapping, system design, build/test, handover/support.
• Enquiry: agency email, GitHub, LinkedIn.

Component responsibilities

• Before/after process visual: inline SVG/CSS showing disconnected enquiry, approval and spreadsheet work becoming an owned, traceable workflow.
• Product directory: grouped by customer need, with accessible filter controls that leave all items available without JavaScript.
• Featured product stories: three entries linking to their product pages, labelled as product examples.
• Delivery-process diagram: the five stages with what the client participates in and receives.
• Enquiry block: agency email as selectable text, GitHub and LinkedIn links, and the invitation brief.

States

• Loading: not applicable; the page is static and renders immediately.
• Empty: not applicable; all content is authored.
• Success: the visitor understands what Flowmative builds, who benefits, how a project runs and what handover/support scope means, and sends an agency enquiry.
• Error: if the mail client does not open, the agency email remains visible as selectable text.
• Recovery: the product directory and FAQs remain reachable regardless of the mail client outcome.

delegationdesk.html

Information and state

• Hero on a charcoal ground: the headline "BIG PLANS. ACTUAL FOLLOW-THROUGH." with the final word underlined by a lime rule; the supporting sentence "You hired a team. You shouldn't have to be its reminder app."; a short explanation; the primary CTA; and the secondary workflow link.
• The daily problem: unclear ownership, manual chasing and uncertain completion, in customer language.
• What changes: a three-column ledger mapping each confirmed capability to an operational benefit and a business outcome.
• How it works: three stages — assign responsibility, track and follow up, review the outcome — as an accessible tab set.
• FAQs: how this differs from a task list, reminder setup requirements, and realistic limits.
• Closing CTA and simple footer, with a brief mention of the Google Apps Script and Google Sheets foundation near the bottom, led by business outcomes rather than technical architecture.
• Static page state; no data loading, no user-specific state, no persistence.

Primary and supporting actions

• Primary CTA: "Request a demo" linking to mailto:mr.deep4k@gmail.com?subject=DelegationDesk%20demo%20enquiry, in the hero and the closing CTA.
• Secondary CTA: an on-page link to the workflow explanation.
• Supporting actions: selecting a "How it works" tab; following the "by Flowmative" link to index.html.
• No form that pretends to submit, no fabricated booking availability, no checkout, no unsupported free trial.

Domain entities

• Task: title, named responsible owner, accountable owner, consulted and informed participants, deadline, priority, status, acceptance criteria, authority level, risk indicator, history.
• Recurring task template: a repeat-work definition that generates routine tasks.
• Escalation: a multi-level rule that surfaces approaching deadlines and overdue work to appropriate people.
• Reminder: a configurable notification rule, subject to deployment configuration.
• Team dashboard: a manager-facing view of execution with context.
• Ownership chain: Responsible / Accountable / Consulted / Informed.

Component responsibilities

• Hero task-board illustration: inline SVG/CSS showing four task rows with task title, named owner initials, deadline chip, status chip, and one row visibly escalated with a lime rule and the label "escalated to Dana"; carries a muted "Illustrative data" label.
• Ownership-chain diagram: a small inline SVG showing Responsible / Accountable / Consulted / Informed as a horizontal rule diagram.
• Capability ledger: three aligned columns — capability, operational benefit, business outcome — separated by hairline rules, with the outcome column set in lime.
• Workflow tab set: accessible tabs with a lime active indicator, keyboard arrow navigation, and a crossfade between panels that becomes an instant swap under reduced motion.
• FAQ list: question-and-answer pairs covering differentiation from a task list, reminder setup requirements, and realistic limits.
• Footer: simple, with the brief foundation note, the demo link and the "by Flowmative" link.

States

• Loading: not applicable; the page is static and renders immediately.
• Empty: not applicable; all content is authored.
• Success: the visitor understands the promise and the honest limits, and follows the demo link or the workflow link.
• Error: if the mail client does not open, the address remains visible as text so it can be copied manually.
• Recovery: the workflow explanation and FAQ remain reachable regardless of the mail client outcome.

crm.html

Information and state

• Left-aligned editorial hero with overlapping account and conversation records, carrying the headline direction "Keep the whole relationship in view." and the primary and secondary CTAs.
• Purposeful visual: one customer account linked to contacts, a deal and recent activities, using fictional sample records.
• Problem/outcome narrative: customer context split between individual messages and isolated deal lists.
• Capability-to-outcome stories: connected records → context survives hand-offs → more coherent customer conversations; deal stages and expected close dates → clearer prioritization → better pipeline discussions; activity history → fewer repeated questions → more prepared sales teams.
• Workflow: connect the account → record the conversation → progress the deal.
• FAQs covering the boundaries: no automatic email sync, no call recording, no AI forecasting claim; any forecast or probability is configured or entered information, not a guarantee.
• Closing CTA and "by Flowmative" link.

Primary and supporting actions

• Primary CTA: "Request a demo" linking to mailto:mr.deep4k@gmail.com with an Orbit CRM-identifying subject, with the email shown as selectable text.
• Secondary CTA: scrolls to the product workflow.
• Supporting action: following the "by Flowmative" link to index.html.

Domain entities

• Account; contact linked to an account; deal with value, stage, probability and expected close date; lead with owner and stage; linked activity history; sales rep, manager and admin views.

Component responsibilities

• Relationship map: a visual linking one account to its contacts, deal and recent activities, rather than a kanban-board hero.
• Overlapping account and conversation records in the hero.
• Capability-to-outcome stories and the three-step workflow.
• FAQ block carrying the boundary statements.

States

• Loading: not applicable; static page.
• Empty: not applicable; all content authored.
• Success: the visitor understands that connected records, deal stages and activity history keep context through hand-offs and support better pipeline discussions, and requests a demo.
• Error: if the mail client does not open, the address remains visible as selectable text.
• Recovery: the workflow and FAQ remain reachable.

inventory.html

Information and state

• Editorial split hero with an architectural stock illustration and ledger-inspired margins, carrying the headline direction "Know what you have. Decide what comes next." and the primary and secondary CTAs.
• Purposeful visual: a warehouse stock position with received, reserved/dispatch context only where supported, batch/expiry and reorder level; reservation functionality is not invented.
• A receipt-to-dispatch strip and a near-expiry example.
• Problem/outcome narrative: teams disagreeing about stock availability, with purchasing and dispatch lacking a shared record.
• Capability-to-outcome stories: warehouse ledger → shared quantity history → better availability decisions; batch/expiry tracking → clearer dispatch choices → less avoidable expiry exposure; purchasing and receipts → connected buy-to-stock records → better replenishment context.
• Workflow: purchase and receive → track, transfer and count → dispatch and review.
• FAQs covering the boundaries: physical stock checks and accurate entries remain necessary; e-invoice support includes export and acknowledgement capture, with no claim of automatic portal filing or statutory compliance guarantees.
• Closing CTA and "by Flowmative" link.

Primary and supporting actions

• Primary CTA: "Request a demo" linking to mailto:mr.deep4k@gmail.com with an Inventory ERP-identifying subject, with the email shown as selectable text.
• Secondary CTA: scrolls to the product workflow.
• Supporting action: following the "by Flowmative" link to index.html.

Domain entities

• Products, suppliers, customers and warehouses; purchase and sales orders; internal material requests; goods receipts, issues, transfers and adjustments; batch and expiry tracking; stock ledger; cycle counts; valuation; invoices, bills, receipts and payments.

Component responsibilities

• Architectural stock illustration with ledger-inspired margins.
• Receipt-to-dispatch strip and near-expiry example.
• Capability-to-outcome stories and the three-step workflow.
• FAQ block carrying the boundary statements.

States

• Loading: not applicable; static page.
• Empty: not applicable; all content authored.
• Success: the visitor understands that a shared stock ledger, batch/expiry tracking and connected buy-to-stock records improve availability and replenishment decisions, while physical stock checks and accurate entries remain necessary, and requests a demo.
• Error: if the mail client does not open, the address remains visible as selectable text.
• Recovery: the workflow and FAQ remain reachable.

leadflow.html

Information and state

• Centered professional hero with a wide pipeline preview, carrying the headline direction "Good leads deserve a great next step." and the primary and secondary CTAs.
• Purposeful visual: a lead record connected to a named owner, stage and scheduled follow-up, with illustrative records.
• A narrow lead-to-next-action ribbon and asymmetric benefit sections.
• Problem/outcome narrative: enquiries arriving without consistent fields, owners or next actions.
• Capability-to-outcome stories: configured capture → more consistent records → better hand-offs; assigned owners and follow-ups → clearer next actions → more consistent customer contact; stage visibility → less guesswork → better sales reviews.
• Workflow: capture and assign → schedule next step → review pipeline and outcomes.
• FAQs covering the boundaries: a configured nightly sweep can flag missed follow-ups, but universal automatic outbound messaging is not implied; no conversion gains are promised; the page distinguishes this configurable lead workflow from Orbit CRM's accounts/contacts/deals emphasis.
• Closing CTA and "by Flowmative" link.

Primary and supporting actions

• Primary CTA: "Request a demo" linking to mailto:mr.deep4k@gmail.com with a LeadFlow-identifying subject, with the email shown as selectable text.
• Secondary CTA: scrolls to the product workflow.
• Supporting action: following the "by Flowmative" link to index.html.

Domain entities

• Configurable fields, stages and sources; roles and assignment hierarchy; lead ownership and assignment history; follow-up date, time, type, status and outcome; pipeline and sales outcome records.

Component responsibilities

• Wide pipeline preview in the hero.
• Lead-to-next-action ribbon.
• Lead record illustration with named owner, stage and scheduled follow-up.
• Capability-to-outcome stories and the three-step workflow.
• FAQ block carrying the boundary statements and the Orbit CRM distinction.

States

• Loading: not applicable; static page.
• Empty: not applicable; all content authored.
• Success: the visitor understands that configured capture, assigned owners and follow-ups, and stage visibility produce more consistent records and clearer next actions, without expecting universal automatic outbound messaging or conversion gains, and requests a demo.
• Error: if the mail client does not open, the address remains visible as selectable text.
• Recovery: the workflow and FAQ remain reachable.

expense.html

Information and state

• A single receipt transforming into an approval trail as the page's distinct composition, with alternating employee, manager and finance perspectives and a compact, orderly closing section.
• Purposeful visual: an illustrative claim showing receipt, category, approval remark and reimbursement status.
• Problem/outcome narrative: receipts arriving across chats and employees unable to see where a claim is stuck.
• Capability-to-outcome stories: structured claims → fewer missing details → easier review; visible decisions → less status chasing → clearer employee expectations; reimbursement records → traceable closure → better finance hand-offs.
• Workflow: submit with evidence → review with context → record reimbursement.
• FAQs covering the boundaries: recording reimbursement does not transfer money; email delivery depends on permissions and configuration; no automatic bank integration or fraud-detection guarantee.
• Closing CTA and "by Flowmative" link.

Primary and supporting actions

• Primary CTA: "Request a demo" linking to mailto:mr.deep4k@gmail.com with an Expense-identifying subject, with the email shown as selectable text.
• Secondary CTA: scrolls to the product workflow.
• Supporting action: following the "by Flowmative" link to index.html.

Domain entities

• Claim with category, amount, date and receipts; category limits and receipt requirements; approval and rejection remarks; advances; status-change emails; activity trail; reimbursement date and reference records.

Component responsibilities

• Receipt-to-approval-trail composition.
• Alternating employee, manager and finance perspective blocks.
• Illustrative claim showing receipt, category, approval remark and reimbursement status.
• Capability-to-outcome stories and the three-step workflow.
• FAQ block carrying the boundary statements.
• Compact, orderly closing section.

States

• Loading: not applicable; static page.
• Empty: not applicable; all content authored.
• Success: the visitor understands that structured claims, visible decisions and reimbursement records reduce missing details and status chasing, while recording reimbursement does not transfer money and email delivery depends on permissions and configuration, and requests a demo.
• Error: if the mail client does not open, the address remains visible as selectable text.
• Recovery: the workflow and FAQ remain reachable.

3. Functional Requirements

FR-1 — Six final marketing pages in one project As a prospective Flowmative agency client, I should see exactly six final marketing pages in one project, so that the navigation and export contain only the intended pages.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is the project scope; observable result is six pages — index.html, delegationdesk.html, crm.html, inventory.html, leadflow.html, expense.html; continuation is building each page from its brief.
• Acceptance: no other apps are created; only these six pages belong in the final navigation and export.

FR-2 — Preserve existing work as reference As a prospective Flowmative agency client, I should have existing work preserved as reference, so that unrelated files and projects are not lost.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is the project scope; observable result is that unrelated files and projects remain; continuation is building the six pages.
• Acceptance: no unrelated files or projects are deleted.

FR-3 — Marketing pages, not application rebuilds As a prospective customer, I should encounter marketing pages that explain the customer's problem, what the product enables, and the operational and business benefit, so that I am not shown a rebuilt application.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is opening any of the six pages; observable result is marketing content; continuation is reading the page.
• Acceptance: no page rebuilds the actual application.

FR-4 — Standalone HTML5 with inline CSS and minimal vanilla JavaScript As a prospective customer, I should receive each page as complete standalone HTML5 with inline CSS and minimal vanilla JavaScript, so that I can open it anywhere.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is delivery; observable result is six standalone files with inline <style> and <script>; continuation is local review.
• Acceptance: semantic content is present without JavaScript, and each page carries relative links to the other five files.

FR-5 — Opens from file:// and works on any static host As a prospective customer, I should be able to open each page by double-clicking and also host it statically, so that it works in both contexts.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is opening the file locally or from a static host; observable result is a fully rendered page; continuation is reading the page.
• Acceptance: both contexts work; no local fetch or module imports are used.

FR-6 — No frameworks, build step, backend or platform runtime As a prospective customer, I should receive plain HTML/CSS/vanilla JavaScript, so that no toolchain is required.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is delivery; observable result is the absence of React, JSX, Next.js, Vue, routing framework, Tailwind runtime, npm, build step, backend and platform runtime; continuation is opening the file.
• Acceptance: none of these are present.

FR-7 — No injected preview scripts, telemetry, data adapters or editor dependencies As a prospective customer, I should receive a clean export, so that no preview or editor machinery ships with the pages.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is delivery; observable result is the absence of 8080 injected preview scripts, telemetry, data adapters and editor dependencies; continuation is opening the file.
• Acceptance: none are present in the final export.

FR-8 — Licensed local assets with relative paths and font fallbacks As a prospective customer, I should see optional images and fonts delivered as licensed local assets with relative paths and font fallbacks, so that no temporary asset URL is required.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is loading the page; observable result is locally referenced assets and working fallbacks; continuation is reading the page.
• Acceptance: no temporary asset URLs; SVG/CSS illustrations are used where appropriate.

FR-9 — Responsive at 360, 390, 768, 1024 and 1440px As a prospective customer, I should be able to read each page at 360, 390, 768, 1024 and 1440px, so that the layout holds on any device.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is resizing or using a device at one of these widths; observable result is a correct layout with no clipped headlines, overflow or overlapping badges; continuation is reading the page.
• Acceptance: no clipping, overflow or overlap at any of the five widths.

FR-10 — Accessibility and zoom As a prospective customer, I should be able to navigate each page with a keyboard and assistive technology and read it at 200% zoom, so that I can use it regardless of ability.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is keyboard, assistive-technology or zoom use; observable result is WCAG AA text contrast, keyboard access, visible focus, reduced-motion support, body text at least 16px, and accessible mobile navigation and tabs; continuation is completing the journey.
• Acceptance: all of these hold at 200% zoom.

FR-11 — Section count and word budget As a prospective customer, I should read roughly 5–7 sections and 450–750 words per app page, so that each page stays focused on advancing the buying decision.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is reading a product page; observable result is 5–7 sections within the word budget; continuation is the closing CTA.
• Acceptance: the homepage may be longer; each section advances the buying decision.

FR-12 — Distinct design language per product As a prospective customer, I should experience a different design language on each product page, so that the pages are not interchangeable.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is moving between pages; observable result is different composition, typography, palette, product illustration and section rhythm — not just accent colours; continuation is reading the page.
• Acceptance: a small "by Flowmative" link appears on every app page.

FR-13 — DelegationDesk keeps its charcoal/lime bold direction As a prospective DelegationDesk customer, I should experience the original charcoal/lime bold direction, so that the page preserves the direction the owner liked.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is opening delegationdesk.html; observable result is the charcoal/lime bold direction; continuation is reading the page.
• Acceptance: the direction is preserved.

FR-14 — Primary app CTA As a prospective customer, I should be able to request a demo from any product page, so that I can start a conversation.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is activating "Request a demo"; observable result is the mail client opening a message to mr.deep4k@gmail.com with a URL-encoded product-specific subject; failure/recovery is that the email remains visible as selectable text if the mail client does not open; continuation is sending the message.
• Acceptance: the label is "Request a demo"; the email is shown as selectable text; the page never claims an email was sent merely because the mail app opened.

FR-15 — Agency CTA As a prospective Flowmative agency client, I should be able to discuss a project from the homepage, so that I can start an agency conversation.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is activating "Discuss your project"; observable result is the mail client opening a message to flowmative@gmail.com with subject Flowmative project enquiry; failure/recovery is that the agency email remains visible as selectable text; continuation is sending the message.
• Acceptance: the link is mailto:flowmative@gmail.com?subject=Flowmative%20project%20enquiry.

FR-16 — Brand and contact facts As a prospective customer, I should see accurate brand and contact facts, so that I can reach Flowmative and verify its presence.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is reading the homepage; observable result is Flowmative described as a custom software and automation agency in Panipat, India, working remotely, with services listed as custom web applications, business systems, workflow automation, Google Workspace automation and reporting dashboards; agency enquiries at flowmative@gmail.com; product demo enquiries at mr.deep4k@gmail.com; GitHub at https://github.com/deep4kk; LinkedIn at https://linkedin.com/in/deep4kk; continuation is the enquiry action.
• Acceptance: all facts are present and accurate.

FR-17 — Honest claims and no fabricated proof As a prospective customer, I should see only honest claims, so that I can trust the pages.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is reading any page; observable result is the absence of repeated disclaimer paragraphs, artificial scarcity, invented testimonials, clients, figures, guarantees and prices; illustrative product records are labelled as sample data; no fake booking forms, payment features or coming-soon alerts; continuation is the CTA.
• Acceptance: all of these hold across all six pages.

FR-18 — Credit estimates and no deployment or backend work As a prospective customer, I should see normal credit estimates and receive no deployment, purchase, hosting provisioning or backend tasks, so that the scope stays bounded.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is the generation request; observable result is a stated estimate and no deployment, purchase, hosting or backend work; continuation is local review.
• Acceptance: none of those activities occur.

FR-19 — Preview mode distinguished from final export As a prospective customer, I should be told clearly if preview mode uses React internally, so that I am not misled about the deliverable.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is the generation request; observable result is a clear distinction between preview mode and the required final plain HTML export; failure/recovery is that if framework-free source cannot be exported, this is explained before generation rather than pretending the preview is the deliverable; continuation is the export.
• Acceptance: the distinction is stated.

FR-20 — ZIP deliverable As a prospective customer, I should receive a ZIP of six HTML files plus assets, README and manifest, so that I have the complete package.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is the ZIP request after all six page prompts; observable result is the ZIP; continuation is independent refinement of the exported designs and code before production use.
• Acceptance: the ZIP contains the six HTML files, assets, README and manifest.

FR-21 — Homepage redesign from the original As a prospective Flowmative agency client, I should see a substantially redesigned homepage, so that the original layout and purple-glow styling are not preserved.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is opening index.html; observable result is a substantially redesigned page that preserves accurate service positioning, location, contact and social links; continuation is reading the page.
• Acceptance: the original HTML, if attached, is treated as content and brand context, not a requirement to preserve its layout or purple-glow styling.

FR-22 — Homepage creative direction As a prospective Flowmative agency client, I should experience a premium independent software studio meets business consultancy direction, so that the homepage is distinguishable from every individual product page.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is viewing the homepage; observable result is ink #142527, soft white #F5F7F4 and a controlled vermilion #E45C3A accent, confident editorial sans-serif headings with one restrained serif accent if useful, strong alignment and alternating light/dark chapters; continuation is reading the page.
• Acceptance: the direction is applied and the page is distinguishable from every product page.

FR-23 — Homepage hero As a prospective Flowmative agency client, I should see a sharp customer-facing promise with a concrete subheading, so that I understand what Flowmative builds, who benefits and the next action within the first viewport.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is viewing the hero; observable result is a promise such as "Less chasing. Less rework. A business that flows." with a concrete subheading about custom software and automation for sales, operations and teams, plus a bespoke before/after process visual in which disconnected enquiry, approval and spreadsheet work becomes an owned, traceable workflow; continuation is the CTA.
• Acceptance: the first viewport states what Flowmative builds, who benefits and the next action; the page does not imply all five products already integrate automatically.

FR-24 — Homepage story As a prospective Flowmative agency client, I should read the homepage story in the specified order, so that each section advances my decision.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is scrolling the homepage; observable result is brand navigation, hero, "Discuss your project" and "Explore the systems" CTAs; recognizable operational friction kept concise; featured product stories for DelegationDesk, LeadFlow and Inventory ERP labelled as product examples; the complete product collection with all five working links grouped by customer need; service engagement; delivery process; reasons to enquire; short FAQs; and a strong enquiry section with the brief "Tell us what your team keeps doing by hand."; continuation is the enquiry action.
• Acceptance: all elements are present; accessible filter controls are welcome if useful but all items remain available without JavaScript; no form pretends to submit.

FR-25 — Homepage service engagement and delivery process As a prospective Flowmative agency client, I should understand when to customize a product versus design a workflow from scratch, and how a project runs, so that I can judge fit.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is reading the service engagement and delivery process sections; observable result is the services (custom applications, workflow automation and reporting, plus Google Workspace work) and the delivery process (discovery → process mapping → system design → build/test → handover/support) with what a client participates in and receives; continuation is the enquiry action.
• Acceptance: no promise of compatibility without discovery; support scope is agreed, not unlimited by default.

FR-26 — Homepage reasons to enquire As a prospective Flowmative agency client, I should see reasons to enquire presented as an approach, so that I am not shown unsupported performance claims.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is reading the reasons-to-enquire section; observable result is business-process understanding, a visible workflow before implementation, reviewable progress and documented handover; continuation is the enquiry action.
• Acceptance: the reasons are presented as an approach, not as performance claims.

FR-27 — Homepage unsupported material removed or rewritten As a prospective Flowmative agency client, I should not see unsupported material from the original, so that the homepage is honest.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is reading the homepage; observable result is the absence of "10+ projects", "50+ processes", "3+ years", "100%", "dozens of production systems", guaranteed 24-hour responses, "nothing missed", absolute error elimination and sector-wide compliance claims; alert('Demo coming soon!') links are replaced with actual product pages or enquiry links; unfinished or private project references stay out of the proof section unless their status is explicit; continuation is the enquiry action.
• Acceptance: none of the unsupported material appears; no testimonials, client logos, case-study outcomes or live demos are invented.

FR-28 — Homepage wordmark and favicon As a prospective Flowmative agency client, I should see a tasteful text wordmark and a simple favicon, so that no broken image ships.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is loading the homepage; observable result is a text wordmark and a simple favicon; continuation is reading the page.
• Acceptance: the referenced Flowmative Final Logo.png is not shipped as a broken image, and no new symbol is presented as the supplied logo.

FR-29 — Homepage technology credibility As a prospective Flowmative agency client, I should see technologies in a small credibility section, so that the homepage does not read like a developer résumé.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is reading the homepage; observable result is a small credibility section; continuation is the enquiry action.
• Acceptance: product-specific technology claims match the briefs, which describe Apps Script/Sheets applications.

FR-30 — Homepage content context As a prospective Flowmative agency client, I should see the homepage's content context applied, so that the positioning and audience are accurate.

• Provenance: explicit
• Lifecycle: initiator is the prospective agency client; trigger is reading the homepage; observable result is the current positioning "We Build Systems That Run Your Business." improved if a more customer-focused headline is stronger; the original Syne/DM Sans, dark purple glows, many small cards, long technology list and nonfunctional demo alerts substantially redesigned; the core audience of SME owners, sales leaders, operations managers and finance teams addressed; agency strengths explained as an approach; the five products used as tangible evidence of the type of system offered; continuation is the enquiry action.
• Acceptance: no guarantee that all five products already integrate; no sixth product or links to products outside the six-page project scope.

FR-31 — DelegationDesk audience, problem and headline As a prospective DelegationDesk customer, I should see the audience, problem and headline direction, so that I recognise my situation.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is opening delegationdesk.html; observable result is the audience (owners and team leaders who spend their day chasing delegated work), the problem (tasks disappearing into messages with unclear responsibility and definition of done) and the headline direction "BIG PLANS. ACTUAL FOLLOW-THROUGH." which may be refined; continuation is reading the page.
• Acceptance: all three are present.

FR-32 — DelegationDesk visual identity and composition As a prospective DelegationDesk customer, I should experience the charcoal/lime visual identity and distinct composition, so that the page preserves the direction the owner liked.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is viewing the page; observable result is charcoal #151515, lime #C2F547, warm white #FAF9F3, bold condensed display type with generous readable body text, a typographic poster hero, an offset task board, a horizontal responsibility chain and a contrasting lime closing panel; continuation is reading the page.
• Acceptance: no blue-and-yellow replacement.

FR-33 — DelegationDesk purposeful visual As a prospective DelegationDesk customer, I should see an illustrative task with a responsible person, accountable owner, deadline, acceptance criteria and an overdue escalation, so that I understand the product's core artefact.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is viewing the hero illustration; observable result is the illustrative task; continuation is reading the capability ledger.
• Acceptance: the illustration shows all five elements.

FR-34 — DelegationDesk confirmed scope As a prospective DelegationDesk customer, I should see the confirmed scope, so that I understand what the product covers.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is reading the capability ledger; observable result is responsible/accountable/consulted/informed ownership; four authority levels; deadlines, priorities, status and acceptance criteria; configured reminders and escalation; recurring templates; risk indicators and activity history; continuation is the workflow section.
• Acceptance: all elements are present.

FR-35 — DelegationDesk capability-to-outcome stories As a prospective DelegationDesk customer, I should see the capability-to-outcome stories, so that I understand the operational benefit.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is reading the ledger; observable result is named ownership → fewer hand-off gaps → clearer accountability; configured reminders → less manual chasing → more management attention available for exceptions; acceptance criteria → clearer completion checks → less avoidable rework; continuation is the workflow section.
• Acceptance: all three stories are present.

FR-36 — DelegationDesk workflow As a prospective DelegationDesk customer, I should see the three-step workflow, so that I understand how the product is used.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is reading the workflow section; observable result is assign with context → track and follow up → review completion; continuation is the FAQ.
• Acceptance: all three steps are present.

FR-37 — DelegationDesk boundaries As a prospective DelegationDesk customer, I should see the product's boundaries, so that I do not expect capabilities that require setup or are not included.

• Provenance: explicit
• Lifecycle: initiator is the prospective DelegationDesk customer; trigger is reading the FAQ; observable result is that reminders require background triggers and notification setup; no automatic WhatsApp API delivery by default; no guarantee that no task will ever be missed; employee scores are not presented as an objective measure of personal worth; continuation is the CTA.
• Acceptance: all boundaries are present.

FR-38 — Orbit CRM audience, problem and headline As a prospective Orbit CRM customer, I should see the audience, problem and headline direction, so that I recognise my situation.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is opening crm.html; observable result is the audience (relationship-led sales teams managing accounts, contacts and deals), the problem (customer context split between individual messages and isolated deal lists) and the headline direction "Keep the whole relationship in view." which may be refined; continuation is reading the page.
• Acceptance: all three are present.

FR-39 — Orbit CRM visual identity and composition As a prospective Orbit CRM customer, I should experience the ink/ivory/plum visual identity and distinct composition, so that the page is distinguishable from the other product pages.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is viewing the page; observable result is ink #302C36, ivory #FAF8F4, plum #713D62, editorial serif headlines paired with clean sans-serif body text, a left-aligned editorial hero with overlapping account and conversation records, and a relationship map rather than another kanban-board hero; continuation is reading the page.
• Acceptance: the direction is applied.

FR-40 — Orbit CRM purposeful visual As a prospective Orbit CRM customer, I should see one customer account linked to contacts, a deal and recent activities, so that I understand the connected-record model.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is viewing the hero illustration; observable result is the linked account visual using fictional sample records; continuation is reading the capability stories.
• Acceptance: the records are labelled as fictional sample records.

FR-41 — Orbit CRM confirmed scope As a prospective Orbit CRM customer, I should see the confirmed scope, so that I understand what the product covers.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is reading the capability stories; observable result is accounts; contacts linked to accounts; deals with value, stage, probability and expected close date; leads with owner and stage; linked activity history; sales rep/manager/admin views; continuation is the workflow section.
• Acceptance: all elements are present.

FR-42 — Orbit CRM capability-to-outcome stories As a prospective Orbit CRM customer, I should see the capability-to-outcome stories, so that I understand the operational benefit.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is reading the stories; observable result is connected records → context survives hand-offs → more coherent customer conversations; deal stages and expected close dates → clearer prioritization → better pipeline discussions; activity history → fewer repeated questions → more prepared sales teams; continuation is the workflow section.
• Acceptance: all three stories are present.

FR-43 — Orbit CRM workflow As a prospective Orbit CRM customer, I should see the three-step workflow, so that I understand how the product is used.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is reading the workflow section; observable result is connect the account → record the conversation → progress the deal; continuation is the FAQ.
• Acceptance: all three steps are present.

FR-44 — Orbit CRM boundaries As a prospective Orbit CRM customer, I should see the product's boundaries, so that I do not expect capabilities that are not included.

• Provenance: explicit
• Lifecycle: initiator is the prospective Orbit CRM customer; trigger is reading the FAQ; observable result is no automatic email sync, no call recording and no AI forecasting claim; any forecast or probability is configured or entered information, not a guarantee; continuation is the CTA.
• Acceptance: all boundaries are present.

FR-45 — Inventory ERP audience, problem and headline As a prospective Inventory ERP customer, I should see the audience, problem and headline direction, so that I recognise my situation.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is opening inventory.html; observable result is the audience (warehouse, purchase and operations teams managing stock across locations), the problem (teams disagreeing about stock availability with purchasing and dispatch lacking a shared record) and the headline direction "Know what you have. Decide what comes next." which may be refined; continuation is reading the page.
• Acceptance: all three are present.

FR-46 — Inventory ERP visual identity and composition As a prospective Inventory ERP customer, I should experience the midnight green/ivory/copper visual identity and distinct composition, so that the page is distinguishable from the other product pages.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is viewing the page; observable result is midnight green #171E1D, ivory #F3F0E7, copper #CE9B75, refined serif accents with legible neutral sans-serif, an architectural stock illustration, ledger-inspired margins, an editorial split hero, a receipt-to-dispatch strip and a near-expiry example; continuation is reading the page.
• Acceptance: the direction is applied.

FR-47 — Inventory ERP purposeful visual As a prospective Inventory ERP customer, I should see a warehouse stock position with received, reserved/dispatch context only where supported, batch/expiry and reorder level, so that I understand the stock model.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is viewing the hero illustration; observable result is the stock position visual; continuation is reading the capability stories.
• Acceptance: reservation functionality is not invented.

FR-48 — Inventory ERP confirmed scope As a prospective Inventory ERP customer, I should see the confirmed scope, so that I understand what the product covers.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is reading the capability stories; observable result is products, suppliers, customers and warehouses; purchase/sales orders; internal material requests; goods receipts, issues, transfers and adjustments; batch and expiry tracking; stock ledger; cycle counts; valuation; invoices, bills, receipts and payments; continuation is the workflow section.
• Acceptance: all elements are present.

FR-49 — Inventory ERP capability-to-outcome stories As a prospective Inventory ERP customer, I should see the capability-to-outcome stories, so that I understand the operational benefit.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is reading the stories; observable result is warehouse ledger → shared quantity history → better availability decisions; batch/expiry tracking → clearer dispatch choices → less avoidable expiry exposure; purchasing and receipts → connected buy-to-stock records → better replenishment context; continuation is the workflow section.
• Acceptance: all three stories are present.

FR-50 — Inventory ERP workflow As a prospective Inventory ERP customer, I should see the three-step workflow, so that I understand how the product is used.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is reading the workflow section; observable result is purchase and receive → track, transfer and count → dispatch and review; continuation is the FAQ.
• Acceptance: all three steps are present.

FR-51 — Inventory ERP boundaries As a prospective Inventory ERP customer, I should see the product's boundaries, so that I do not expect capabilities that are not included.

• Provenance: explicit
• Lifecycle: initiator is the prospective Inventory ERP customer; trigger is reading the FAQ; observable result is that physical stock checks and accurate entries remain necessary; e-invoice support includes export and acknowledgement capture, with no claim of automatic portal filing or statutory compliance guarantees; continuation is the CTA.
• Acceptance: all boundaries are present.

FR-52 — LeadFlow audience, problem and headline As a prospective LeadFlow customer, I should see the audience, problem and headline direction, so that I recognise my situation.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is opening leadflow.html; observable result is the audience (sales teams needing configurable lead capture, assignment and follow-up), the problem (enquiries arriving without consistent fields, owners or next actions) and the headline direction "Good leads deserve a great next step." which may be refined; continuation is reading the page.
• Acceptance: all three are present.

FR-53 — LeadFlow visual identity and composition As a prospective LeadFlow customer, I should experience the white/navy/cobalt visual identity and distinct composition, so that the page is distinguishable from the other product pages.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is viewing the page; observable result is white #FFFFFF, navy #152741, cobalt #2459EE, precise modern sans-serif with restrained typography and crisp rules, a centered professional hero with a wide pipeline preview, a narrow lead-to-next-action ribbon and asymmetric benefit sections; continuation is reading the page.
• Acceptance: the direction is applied.

FR-54 — LeadFlow purposeful visual As a prospective LeadFlow customer, I should see a lead record connected to a named owner, stage and scheduled follow-up, so that I understand the lead model.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is viewing the hero illustration; observable result is the lead record visual with illustrative records; continuation is reading the capability stories.
• Acceptance: the records are labelled as illustrative.

FR-55 — LeadFlow confirmed scope As a prospective LeadFlow customer, I should see the confirmed scope, so that I understand what the product covers.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is reading the capability stories; observable result is configurable fields, stages and sources; roles and assignment hierarchy; lead ownership and assignment history; follow-up date, time, type, status and outcome; pipeline and sales outcome records; continuation is the workflow section.
• Acceptance: all elements are present.

FR-56 — LeadFlow capability-to-outcome stories As a prospective LeadFlow customer, I should see the capability-to-outcome stories, so that I understand the operational benefit.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is reading the stories; observable result is configured capture → more consistent records → better hand-offs; assigned owners and follow-ups → clearer next actions → more consistent customer contact; stage visibility → less guesswork → better sales reviews; continuation is the workflow section.
• Acceptance: all three stories are present.

FR-57 — LeadFlow workflow As a prospective LeadFlow customer, I should see the three-step workflow, so that I understand how the product is used.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is reading the workflow section; observable result is capture and assign → schedule next step → review pipeline and outcomes; continuation is the FAQ.
• Acceptance: all three steps are present.

FR-58 — LeadFlow boundaries As a prospective LeadFlow customer, I should see the product's boundaries, so that I do not expect capabilities that are not included.

• Provenance: explicit
• Lifecycle: initiator is the prospective LeadFlow customer; trigger is reading the FAQ; observable result is that a configured nightly sweep can flag missed follow-ups, but universal automatic outbound messaging is not implied; no conversion gains are promised; the page distinguishes this configurable lead workflow from Orbit CRM's accounts/contacts/deals emphasis; continuation is the CTA.
• Acceptance: all boundaries are present.

FR-59 — Expense & Reimbursement audience, problem and headline As a prospective Expense & Reimbursement customer, I should see the audience, problem and headline direction, so that I recognise my situation.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is opening expense.html; observable result is the audience (employees, managers and finance teams handling claims and advances), the problem (receipts arriving across chats and employees unable to see where a claim is stuck) and the headline direction "From receipt to resolution." which may be refined; continuation is reading the page.
• Acceptance: all three are present.

FR-60 — Expense & Reimbursement visual identity and composition As a prospective Expense & Reimbursement customer, I should experience the deep blue/white/soft mint visual identity and distinct composition, so that the page is distinguishable from the other product pages.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is viewing the page; observable result is deep blue #213B59, white #FFFFFF, soft mint #D7EBDF, calm finance typography on clean document-like surfaces, a single receipt transforming into an approval trail, alternating employee/manager/finance perspectives and a compact, orderly closing section; continuation is reading the page.
• Acceptance: the direction is applied.

FR-61 — Expense & Reimbursement purposeful visual As a prospective Expense & Reimbursement customer, I should see an illustrative claim with receipt, category, approval remark and reimbursement status, so that I understand the claim model.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is viewing the hero illustration; observable result is the illustrative claim; continuation is reading the capability stories.
• Acceptance: the illustration shows all four elements.

FR-62 — Expense & Reimbursement confirmed scope As a prospective Expense & Reimbursement customer, I should see the confirmed scope, so that I understand what the product covers.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is reading the capability stories; observable result is claims with category, amount, date and receipts; category limits and receipt requirements; approval/rejection remarks; advances; status-change emails; activity trail; reimbursement date and reference records; continuation is the workflow section.
• Acceptance: all elements are present.

FR-63 — Expense & Reimbursement capability-to-outcome stories As a prospective Expense & Reimbursement customer, I should see the capability-to-outcome stories, so that I understand the operational benefit.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is reading the stories; observable result is structured claims → fewer missing details → easier review; visible decisions → less status chasing → clearer employee expectations; reimbursement records → traceable closure → better finance hand-offs; continuation is the workflow section.
• Acceptance: all three stories are present.

FR-64 — Expense & Reimbursement workflow As a prospective Expense & Reimbursement customer, I should see the three-step workflow, so that I understand how the product is used.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is reading the workflow section; observable result is submit with evidence → review with context → record reimbursement; continuation is the FAQ.
• Acceptance: all three steps are present.

FR-65 — Expense & Reimbursement boundaries As a prospective Expense & Reimbursement customer, I should see the product's boundaries, so that I do not expect capabilities that are not included.

• Provenance: explicit
• Lifecycle: initiator is the prospective Expense & Reimbursement customer; trigger is reading the FAQ; observable result is that recording reimbursement does not transfer money; email delivery depends on permissions and configuration; no automatic bank integration or fraud-detection guarantee; continuation is the CTA.
• Acceptance: all boundaries are present.

FR-66 — Every page story shape As a prospective customer, I should encounter the same story shape on every product page, so that each page is complete and comparable.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is opening any product page; observable result is a first viewport communicating the product, intended customer, main benefit and next action; a purposeful illustrative product visual; a concise problem/outcome narrative; three or four feature-to-benefit stories; a three-step workflow; short FAQs; and a strong closing CTA; continuation is the CTA.
• Acceptance: the composition is adapted to each page's distinct visual identity and does not clone other page layouts.

FR-67 — Customer-facing prose As a prospective customer, I should read customer-facing prose, so that the pages do not read as technical documentation.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is reading any page; observable result is prose without literal instructions such as "read left to right", "capability earns its place" or "illustrative answers"; setup qualifications live in a relevant FAQ; continuation is the CTA.
• Acceptance: none of those literal instructions appear.

FR-68 — Every page CTAs As a prospective customer, I should see the primary CTA, the secondary CTA and the "by Flowmative" link on every product page, so that I can act from anywhere.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is reaching the hero or the closing CTA; observable result is "Request a demo" via mailto:mr.deep4k@gmail.com with a subject identifying the product, the email shown as selectable text; the secondary CTA scrolling to the product workflow; and "by Flowmative" linking to index.html; continuation is the action.
• Acceptance: all three are present on every product page.

FR-69 — Per-page delivery discipline As a prospective customer, I should receive only the page named in each brief, so that completed pages are not rebuilt.

• Provenance: explicit
• Lifecycle: initiator is the requester; trigger is a page brief; observable result is the named page built and saved within the existing six-page project, with its complete downloadable HTML source, inline CSS and vanilla JS, and any required local assets; continuation is the next brief.
• Acceptance: no credits are spent rebuilding previously completed pages.

FR-70 — Relative links only within the six-page project As a prospective customer, I should see relative links only to the six project files, so that no out-of-scope product is referenced.

• Provenance: explicit
• Lifecycle: initiator is the prospective customer; trigger is following a link; observable result is links to index.html, delegationdesk.html, crm.html, inventory.html, leadflow.html and expense.html only; continuation is the destination page.
• Acceptance: no links to products outside the six-page project scope.

FR-71 — Six files available together for relative navigation As a prospective customer, I should be able to navigate between the six pages, so that relative links resolve.

• Provenance: required_inference
• Lifecycle: initiator is the prospective customer; trigger is following a relative link; observable result is the destination page loading; continuation is reading the destination.
• Acceptance: the six standalone HTML files are available together.

FR-72 — Direct rendering without backend, fetch, module or framework dependencies As a prospective customer, I should be able to render each page directly from file:// and ordinary static hosting, so that no runtime is required.

• Provenance: required_inference
• Lifecycle: initiator is the prospective customer; trigger is opening the file; observable result is a fully rendered page; continuation is reading the page.
• Acceptance: no backend, fetch, module or framework dependency is required.

FR-73 — Product demo mailto links retain product-specific subjects and visible email text As a prospective customer, I should see product-specific subjects and the visible email text, so that I can identify the product and copy the address if needed.

• Provenance: required_inference
• Lifecycle: initiator is the prospective customer; trigger is activating or reading the demo CTA; observable result is a product-specific subject and the email shown as selectable text; continuation is sending the message.
• Acceptance: both are present on every product page.

FR-74 — Homepage retains agency email, GitHub and LinkedIn destinations As a prospective Flowmative agency client, I should see the agency email, GitHub and LinkedIn destinations on the homepage, so that I can reach Flowmative through any channel.

• Provenance: required_inference
• Lifecycle: initiator is the prospective agency client; trigger is reading the enquiry section; observable result is flowmative@gmail.com, https://github.com/deep4kk and https://linkedin.com/in/deep4kk; continuation is the enquiry action.
• Acceptance: all three are present.

FR-75 — Illustrative records and product visuals labelled as sample data As a prospective customer, I should see illustrative records and product visuals labelled as sample data, so that I do not mistake them for real records.

• Provenance: required_inference
• Lifecycle: initiator is the prospective customer; trigger is viewing a product visual; observable result is a visible sample-data label; continuation is reading the surrounding copy.
• Acceptance: every illustrative record and product visual carries the label.

FR-76 — Setup qualifications and operational limits visible in each product page's FAQ As a prospective customer, I should see each product's setup qualifications and operational limits in its FAQ or equivalent boundary content, so that I understand what requires configuration.

• Provenance: required_inference
• Lifecycle: initiator is the prospective customer; trigger is reading the FAQ; observable result is the product's setup qualifications and operational limits; continuation is the CTA.
• Acceptance: each product page carries its own qualifications and limits.

4. User Personas

Prospective Flowmative agency client (SME owner, sales leader, operations manager or finance team member)

Product context. This person has repetitive manual work or scattered process records and is evaluating Flowmative as a custom software and automation partner. They may arrive from a referral, a search, or a product page. They are not shopping for a specific product yet; they are judging whether this agency understands business processes well enough to be trusted with one.

Primary goal. Understand what Flowmative builds, who benefits, how a project runs and what handover and support scope means — well enough to send an agency enquiry.

Distinct accepted responsibilities. They read the homepage promise, the operational-friction section, the featured product stories, the full five-product directory, the service engagement and delivery-process sections, and the FAQs. They decide whether to discuss a project. They are the only accepted human actor on the homepage; no second participant's state changes as a result of their visit.

Relevant inputs or decisions. They read the hero promise and subheading, scan the before/after process visual, read the operational friction, follow a featured product story or a directory link, read the service engagement and delivery process, read the reasons to enquire, read the FAQs, and decide whether to activate "Discuss your project" or "Explore the systems".

Interactions with other accepted participants. None on the homepage. The agency conversation happens outside the page, in the recipient's mail client, and is not modelled here.

Observable success. They understand what Flowmative builds, who benefits, how a project runs and what handover and support scope means, and they send an agency enquiry to flowmative@gmail.com.

Prospective DelegationDesk customer (business owner / operations manager / team leader)

Product context. This person runs or leads a team whose work is currently coordinated through messages, spreadsheets and repeated verbal follow-ups. They are not shopping for a dashboard; they are looking for a way to stop being the human reminder system for their own team. They arrive at the page from a link, a search, or a referral, with no account and no prior exposure to DelegationDesk.

Primary goal. Decide whether DelegationDesk makes ownership, deadlines, progress and escalation visible enough that their team follows through more consistently — and, if so, request a demo.

Distinct accepted responsibilities. They evaluate the page's promise, its problem framing, its capability-to-outcome mapping, its workflow explanation, and its honest limits. They are the only accepted human actor on this page; there is no second participant whose state changes as a result of their visit.

Relevant inputs or decisions. They read the headline and supporting message, scan the capability ledger, inspect the task-board illustration (labelled as illustrative data), read the three workflow stages, read the FAQs, and decide whether to activate the demo link or the workflow link.

Interactions with other accepted participants. None on this page. The demo conversation happens outside the page, in the recipient's mail client, and is not modelled here.

Observable success. They understand the operational benefits and the claim limits well enough to request a demo via the mailto: CTA, or they leave with an accurate understanding of what DelegationDesk does and does not promise.

Prospective Orbit CRM customer (relationship-led sales team member)

Product context. This person works in a relationship-led sales team where customer context is split between individual messages and isolated deal lists. They know the account history exists somewhere, but it is not in one place when they need it. They arrive at the page with no account and no prior exposure to Orbit CRM.

Primary goal. Decide whether Orbit CRM keeps the whole relationship in view — accounts, contacts, deals and activities connected — and, if so, request a demo.

Distinct accepted responsibilities. They read the editorial hero, the account/contact/deal/activity illustration with fictional sample records, the capability-to-outcome stories and the workflow, then decide whether to request a demo. They are the only accepted human actor on this page.

Relevant inputs or decisions. They read the headline direction, inspect the relationship map, read the three capability stories, read the workflow, read the FAQs covering the boundaries (no automatic email sync, no call recording, no AI forecasting claim; forecasts are configured or entered information), and decide whether to activate the demo link.

Interactions with other accepted participants. None on this page. The demo conversation happens outside the page.

Observable success. They understand that connected records, deal stages and activity history keep context through hand-offs and support better pipeline discussions, and they request a demo.

Prospective Inventory ERP customer (warehouse, purchase or operations team member)

Product context. This person manages stock across locations where teams disagree about availability and purchasing and dispatch lack a shared record. They are used to reconciling numbers by hand and to discovering discrepancies late. They arrive at the page with no account and no prior exposure to Inventory ERP.

Primary goal. Decide whether Inventory ERP gives them a shared stock record — purchases, receipts, transfers, counts, batch and expiry — and, if so, request a demo.

Distinct accepted responsibilities. They read the split hero, the warehouse stock position illustration with batch/expiry and reorder level, the capability-to-outcome stories and the workflow, then decide whether to request a demo. They are the only accepted human actor on this page.

Relevant inputs or decisions. They read the headline direction, inspect the receipt-to-dispatch strip and the near-expiry example, read the three capability stories, read the workflow, read the FAQs covering the boundaries (physical stock checks and accurate entries remain necessary; e-invoice support covers export and acknowledgement capture without automatic portal filing or statutory compliance guarantees), and decide whether to activate the demo link.

Interactions with other accepted participants. None on this page. The demo conversation happens outside the page.

Observable success. They understand that a shared stock ledger, batch/expiry tracking and connected buy-to-stock records improve availability and replenishment decisions, while physical stock checks and accurate entries remain necessary, and they request a demo.

Prospective LeadFlow customer (sales team member needing configurable lead capture and follow-up)

Product context. This person handles enquiries that arrive without consistent fields, owners or next actions. Leads land in different inboxes and chats, and the next step depends on who noticed. They arrive at the page with no account and no prior exposure to LeadFlow.

Primary goal. Decide whether LeadFlow gives them configurable capture, clear ownership and scheduled follow-up — and, if so, request a demo.

Distinct accepted responsibilities. They read the centered hero with the pipeline preview, the lead-to-next-action ribbon, the lead record illustration with a named owner, stage and scheduled follow-up, and the workflow, then decide whether to request a demo. They are the only accepted human actor on this page.

Relevant inputs or decisions. They read the headline direction, inspect the pipeline preview and the lead record, read the three capability stories, read the workflow, read the FAQs covering the boundaries (a configured nightly sweep can flag missed follow-ups, but universal automatic outbound messaging is not implied; no conversion gains are promised; this configurable lead workflow is distinct from Orbit CRM's accounts/contacts/deals emphasis), and decide whether to activate the demo link.

Interactions with other accepted participants. None on this page. The demo conversation happens outside the page.

Observable success. They understand that configured capture, assigned owners and follow-ups, and stage visibility produce more consistent records and clearer next actions, without expecting universal automatic outbound messaging or conversion gains, and they request a demo.

Prospective Expense & Reimbursement customer (employee, manager or finance team member)

Product context. This person handles claims and advances where receipts arrive across chats and employees cannot see where a claim is stuck. They are used to chasing status and to reconciling reimbursement records after the fact. They arrive at the page with no account and no prior exposure to the product.

Primary goal. Decide whether Expense & Reimbursement gives them structured claims, visible decisions and traceable reimbursement records — and, if so, request a demo.

Distinct accepted responsibilities. They read the receipt-to-approval-trail composition, the illustrative claim with receipt, category, approval remark and reimbursement status, the capability-to-outcome stories and the workflow, then decide whether to request a demo. They are the only accepted human actor on this page.

Relevant inputs or decisions. They read the headline direction, follow the alternating employee/manager/finance perspectives, read the three capability stories, read the workflow, read the FAQs covering the boundaries (recording reimbursement does not transfer money; email delivery depends on permissions and configuration; no automatic bank integration or fraud-detection guarantee), and decide whether to activate the demo link.

Interactions with other accepted participants. None on this page. The demo conversation happens outside the page.

Observable success. They understand that structured claims, visible decisions and reimbursement records reduce missing details and status chasing, while recording reimbursement does not transfer money and email delivery depends on permissions and configuration, and they request a demo.

5. Core User Flows

Flow 1 — Prospective agency client evaluates Flowmative and sends an enquiry

1. The prospective agency client opens index.html by double-clicking it from file://, or visits it on a static host. No account, login, or gate is involved.
2. The hero renders with a sharp customer-facing promise such as "Less chasing. Less rework. A business that flows." and a concrete subheading about custom software and automation for sales, operations and teams, stating what Flowmative builds, who benefits and the next action.
3. The client reads the bespoke before/after process visual: disconnected enquiry, approval and spreadsheet work becomes an owned, traceable workflow. The page does not imply all five products already integrate automatically.
4. The client scrolls into the operational-friction section and recognises repeated entry, owner-dependent follow-ups, slow approvals and scattered reporting.
5. The client reads the featured product stories for DelegationDesk, LeadFlow and Inventory ERP, each labelled as a product example rather than a verified client success story, and may follow one to its page.
6. The client reaches the complete product collection, grouped by customer need, with all five working links available without JavaScript, and may filter the list if filter controls are present.
7. The client reads the service engagement section — custom applications, workflow automation and reporting, plus Google Workspace work — and the explanation of when to customize a product versus design a workflow from scratch.
8. The client reads the delivery process: discovery → process mapping → system design → build/test → handover/support, with what a client participates in and receives, and with support scope agreed rather than unlimited by default.

9. The client reads the reasons to enquire, presented as an approach rather than performance claims, and the short FAQs on customization, working with existing tools, handover/support, and how scope and pricing are determined.
10. The client reaches the enquiry section, sees the agency email as selectable text, the GitHub link https://github.com/deep4kk and the LinkedIn link https://linkedin.com/in/deep4kk, and reads the brief "Tell us what your team keeps doing by hand."
11. The client activates "Discuss your project". Their mail client opens a message to flowmative@gmail.com with subject Flowmative project enquiry. They send it.
12. Failure and recovery. If their mail client does not open, the agency email remains visible as selectable text so they can copy it manually. If they are not ready to enquire, they can return to the product directory or the FAQs and leave with an accurate understanding of what Flowmative builds and how a project runs.

Flow 2 — Prospective DelegationDesk customer evaluates the page and requests a demo

1. The prospective DelegationDesk customer opens delegationdesk.html by double-clicking it from file://, or visits it on a static host. No account, login, or gate is involved.
2. The hero renders on a charcoal ground: the headline "BIG PLANS. ACTUAL FOLLOW-THROUGH." with the final word underlined by a lime rule, the supporting sentence "You hired a team. You shouldn't have to be its reminder app.", a short explanation, the lime "Request a demo" button, and the secondary "See how it works" link.
3. The customer reads the task-board illustration beside the headline: four task rows with title, named owner initials, deadline chip and status chip, one row visibly escalated with a lime rule and the label "escalated to Dana", and a muted "Illustrative data" label.
4. The customer scrolls into the daily problem section and recognises unclear ownership, manual chasing and uncertain completion described in their own language.
5. The customer reaches the "What changes" block and reads the three-column ledger: each confirmed capability, its operational benefit, and its business outcome, with the outcome column set in lime.
6. The customer reaches "How it works" and selects a stage tab — assign responsibility, track and follow up, or review the outcome. The panel crossfades to the selected stage; under reduced motion it swaps instantly.
7. The customer reads the FAQs: how this differs from a task list, what reminder setup requires, and what the realistic limits are. They note that background triggers and notification settings must be configured during deployment, and that automatic WhatsApp messaging is not included by default.
8. The customer reaches the closing CTA, sees the brief note about the Google Apps Script and Google Sheets foundation, and activates "Request a demo".

9. Their mail client opens a message to mr.deep4k@gmail.com with the subject DelegationDesk demo enquiry. They send it.
10. Failure and recovery. If their mail client does not open, the address remains visible as text on the page so they can copy it manually. If they are not ready to request a demo, they can return to the workflow explanation or re-read the FAQs and leave with an accurate understanding of the product and its limits.

Flow 3 — Prospective DelegationDesk customer checks the workflow before committing

1. The prospective DelegationDesk customer opens the page and reads the hero.
2. Instead of activating the demo CTA, they activate the secondary on-page link to the workflow explanation.
3. The page scrolls to "How it works".
4. They step through the three stages — assign responsibility, track and follow up, review the outcome — using the accessible tabs, with keyboard arrow navigation available.
5. They continue to the FAQs and read the differentiation from a task list, the reminder setup requirements, and the realistic limits.
6. They reach the closing CTA and either activate "Request a demo" or leave with an accurate understanding of the product.

Flow 4 — Prospective Orbit CRM customer evaluates the page and requests a demo

1. The prospective Orbit CRM customer opens crm.html from file:// or a static host. No account, login, or gate is involved.
2. The left-aligned editorial hero renders with overlapping account and conversation records and the headline direction "Keep the whole relationship in view."
3. The customer reads the purposeful visual: one customer account linked to contacts, a deal and recent activities, using fictional sample records.
4. The customer reads the problem/outcome narrative about customer context split between individual messages and isolated deal lists.
5. The customer reads the capability-to-outcome stories: connected records → context survives hand-offs → more coherent customer conversations; deal stages and expected close dates → clearer prioritization → better pipeline discussions; activity history → fewer repeated questions → more prepared sales teams.
6. The customer reads the workflow: connect the account → record the conversation → progress the deal.
7. The customer reads the FAQs and notes the boundaries: no automatic email sync, no call recording, no AI forecasting claim; any forecast or probability is configured or entered information, not a guarantee.
8. The customer activates "Request a demo". Their mail client opens a message to mr.deep4k@gmail.com with an Orbit CRM-identifying subject. They send it.
9. Failure and recovery. If their mail client does not open, the address remains visible as selectable text. If they are not ready, they can return to the workflow or the FAQs.

Flow 5 — Prospective Inventory ERP customer evaluates the page and requests a demo

1. The prospective Inventory ERP customer opens inventory.html from file:// or a static host. No account, login, or gate is involved.
2. The editorial split hero renders with an architectural stock illustration and ledger-inspired margins, carrying the headline direction "Know what you have. Decide what comes next."
3. The customer reads the purposeful visual: a warehouse stock position with received, reserved/dispatch context only where supported, batch/expiry and reorder level. Reservation functionality is not invented.
4. The customer reads the receipt-to-dispatch strip and the near-expiry example.
5. The customer reads the problem/outcome narrative about teams disagreeing about stock availability, with purchasing and dispatch lacking a shared record.
6. The customer reads the capability-to-outcome stories: warehouse ledger → shared quantity history → better availability decisions; batch/expiry tracking → clearer dispatch choices → less avoidable expiry exposure; purchasing and receipts → connected buy-to-stock records → better replenishment context.
7. The customer reads the workflow: purchase and receive → track, transfer and count → dispatch and review.
8. The customer reads the FAQs and notes the boundaries: physical stock checks and accurate entries remain necessary; e-invoice support includes export and acknowledgement capture, with no claim of automatic portal filing or statutory compliance guarantees.
9. The customer activates "Request a demo". Their mail client opens a message to mr.deep4k@gmail.com with an Inventory ERP-identifying subject. They send it.
10. Failure and recovery. If their mail client does not open, the address remains visible as selectable text. If they are not ready, they can return to the workflow or the FAQs.

Flow 6 — Prospective LeadFlow customer evaluates the page and requests a demo

1. The prospective LeadFlow customer opens leadflow.html from file:// or a static host. No account, login, or gate is involved.
2. The centered professional hero renders with a wide pipeline preview, carrying the headline direction "Good leads deserve a great next step."
3. The customer reads the purposeful visual: a lead record connected to a named owner, stage and scheduled follow-up, with illustrative records.
4. The customer reads the narrow lead-to-next-action ribbon and the asymmetric benefit sections.
5. The customer reads the problem/outcome narrative about enquiries arriving without consistent fields, owners or next actions.
6. The customer reads the capability-to-outcome stories: configured capture → more consistent records → better hand-offs; assigned owners and follow-ups → clearer next actions → more consistent customer contact; stage visibility → less guesswork → better sales reviews.
7. The customer reads the workflow: capture and assign → schedule next step → review pipeline and outcomes.
8. The customer reads the FAQs and notes the boundaries: a configured nightly sweep can flag missed follow-ups, but universal automatic outbound messaging is not implied; no conversion gains are promised; this configurable lead workflow is distinct from Orbit CRM's accounts/contacts/deals emphasis.
9. The customer activates "Request a demo". Their mail client opens a message to mr.deep4k@gmail.com with a LeadFlow-identifying subject. They send it.
10. Failure and recovery. If their mail client does not open, the address remains visible as selectable text. If they are not ready, they can return to the workflow or the FAQs.

Flow 7 — Prospective Expense & Reimbursement customer evaluates the page and requests a demo

1. The prospective Expense & Reimbursement customer opens expense.html from file:// or a static host. No account, login, or gate is involved.
2. The page renders with a single receipt transforming into an approval trail, alternating employee, manager and finance perspectives, and a compact, orderly closing section.
3. The customer reads the purposeful visual: an illustrative claim showing receipt, category, approval remark and reimbursement status.
4. The customer reads the problem/outcome narrative about receipts arriving across chats and employees unable to see where a claim is stuck.
5. The customer reads the capability-to-outcome stories: structured claims → fewer missing details → easier review; visible decisions → less status chasing → clearer employee expectations; reimbursement records → traceable closure → better finance hand-offs.
6. The customer reads the workflow: submit with evidence → review with context → record reimbursement.
7. The customer reads the FAQs and notes the boundaries: recording reimbursement does not transfer money; email delivery depends on permissions and configuration; no automatic bank integration or fraud-detection guarantee.
8. The customer activates "Request a demo". Their mail client opens a message to mr.deep4k@gmail.com with an Expense-identifying subject. They send it.
9. Failure and recovery. If their mail client does not open, the address remains visible as selectable text. If they are not ready, they can return to the workflow or the FAQs.

Flow 8 — Prospective customer navigates between the six pages

1. The prospective customer is reading any of the six pages.
2. They follow a relative link — a product page link from the homepage directory, a featured product story link, or the "by Flowmative" link from a product page.
3. The destination page loads from the same local folder or static host, with no backend, fetch, module or framework dependency.
4. They continue reading the destination page and may follow another relative link.
5. Failure and recovery. If a relative link does not resolve because the six files are not together, the customer can open the intended file directly from the same folder; the pages remain readable individually.

6. Visuals Colors and Theme

The creative direction is authoritative for the DelegationDesk page. Each product page carries its own distinct design language; the homepage carries its own.

DelegationDesk — charcoal and lime, editorial swagger

The muse is Tobias van Schneider; the headline direction is editorial swagger — bold black type, one hot accent, asymmetric confidence.

Palette (dark mode)

• Background: #151515 (charcoal) — dominant ground for the hero, the daily problem section, how it works, FAQ and closing CTA.
• Surface: #1E1E1C — used only for the task-board card on charcoal, so it reads as a lifted plane without borders.
• Text: #FAF9F3 (warm white).
• Primary: #C2F547 (lime) — the single hot accent: CTAs, the underline under key words, the escalation rule, the active tab indicator, the focus ring.
• Accent: #FAF9F3 (warm white).
• Muted: #8A8A82 — metadata, captions, the "Illustrative data" label.

Light block

• The "What changes" section inverts to a warm white #FAF9F3 ground with charcoal #151515 type, giving the page a hard editorial cut rather than a gradient transition. Hairline rules on light are rgba(21,21,21,0.14); on dark they are rgba(250,249,243,0.14).

Rules

• Never use lime for body text. Never use more than one accent hue. Blue, indigo and violet are forbidden anywhere on the page, including links, focus rings and hover states.

Typography

• Headings: Anton, all-caps, ultra-condensed, at extreme display sizes with tight leading (0.88–0.92) and slight negative tracking (-0.01em). Headlines are the composition: they occupy full column width, wrap deliberately, and use lime as a single highlighted word or a lime underline rule rather than coloured headings.
• Sub-headings: Archivo 700 uppercase with 0.08em tracking at 14–16px as section labels.
• Body: Archivo.
• Scale: 1.333 modular — 96 / 72 / 48 / 32 / 22 / 18 / 16.
• Display headline: clamp(48px, 11vw, 168px). Section headline: clamp(34px, 6vw, 84px). Sub-head: clamp(22px, 2.4vw, 32px). Body: 18px desktop / 17px mobile, line-height 1.55, max measure 62ch. Labels: 13px uppercase, 0.1em tracking.
• Font fallbacks: Anton, "Arial Narrow", Impact, sans-serif for headings; Archivo, "Helvetica Neue", Arial, sans-serif for body. Inter, Roboto, Helvetica, Poppins and system-ui are not used as the heading or body face.

Shape language

• Sharp corners everywhere — 0px radius on cards, buttons, tabs and the task board. Structure comes from 1px hairline rules. Lime appears as solid fills, as a 3px underline rule under emphasised words, and as a 6px square bullet. No blobs, no pill buttons, no soft shadows. The one soft element is the task-board card's very subtle drop shadow on charcoal, used to lift it a single plane.

Layout

• 12-column asymmetric grid, max-width 1440px with 40px gutters desktop / 20px mobile. Hero is a two-zone composition: a 7-column stacked headline on the left, a 5-column task-board illustration on the right. Sections alternate ground: dark hero → dark daily problem with a full-width lime rule → light "What changes" block → dark "How it works" with the tab column on the left and the panel on the right → dark FAQ in a narrow 8-column measure → dark closing CTA with the headline spanning the viewport. Horizontal rules separate every section; no decorative dividers.

Imagery

• No photography, no stock people, no emoji, no abstract gradients. The only illustration is a hand-built inline-SVG/CSS task board showing four real-looking rows: task title, named owner avatar-initials, deadline chip, status chip, and one row visibly escalated with a lime "escalated to Dana" rule. A second small inline SVG shows the ownership chain (Responsible / Accountable / Consulted / Informed) as a horizontal rule diagram. Everything is labelled "Illustrative data" in muted 12px type.

index.html — premium independent software studio meets business consultancy

• Ink #142527, soft white #F5F7F4, controlled vermilion #E45C3A accent.
• Confident editorial sans-serif headings with one restrained serif accent if useful; strong alignment and alternating light/dark chapters.
• Distinguishable from every individual product page.
• No more gradients, glowing borders and cards as the primary device.

crm.html — ink, ivory and plum

• Ink #302C36, ivory #FAF8F4, plum #713D62.
• Editorial serif headlines paired with clean sans-serif body text.
• Left-aligned editorial hero with overlapping account and conversation records; a relationship map rather than another kanban-board hero.

inventory.html — midnight green, ivory and copper

• Midnight green #171E1D, ivory #F3F0E7, copper #CE9B75.
• Refined serif accents with legible neutral sans-serif.
• Architectural stock illustration, ledger-inspired margins, editorial split hero, receipt-to-dispatch strip and near-expiry example.

leadflow.html — white, navy and cobalt

• White #FFFFFF, navy #152741, cobalt #2459EE.
• Precise modern sans-serif with restrained typography and crisp rules.
• Centered professional hero with a wide pipeline preview; narrow lead-to-next-action ribbon; asymmetric benefit sections.

expense.html — deep blue, white and soft mint

• Deep blue #213B59, white #FFFFFF, soft mint #D7EBDF.
• Calm finance typography on clean document-like surfaces; the quietest, most orderly of the six.
• A single receipt transforming into an approval trail; alternating employee/manager/finance perspectives; compact, orderly closing section.

7. Signature Design Concept

The DelegationDesk public entry is the hero. Its signature is a full-bleed charcoal #151515 ground carrying an oversized Anton headline set across three stacked lines in the left 7 of 12 columns: "BIG PLANS. ACTUAL FOLLOW-THROUGH." The final word is underlined by a 6px lime rule that runs the width of the word and 8px past it on the right — the single most memorable element on the page.

Below the headline, one sentence in Archivo 18px warm white at 58ch: "You hired a team. You shouldn't have to be its reminder app." Below that, a lime-filled rectangular button "Request a demo" with charcoal text and sharp corners, and a text link "See how it works →" with a lime hover underline.

To the right, the task-board illustration sits on a #1E1E1C plane, cropped so its right edge bleeds off the viewport, with a small muted "Illustrative data" label at its top-right. The board shows four task rows with title, named owner initials, deadline chip and status chip, and one row visibly escalated with a lime rule and the label "escalated to Dana".

A 1px hairline rule runs the full width above the hero content and a lime 3px rule runs below it, cutting the hero off from the problem section. The composition is asymmetric, left-weighted, and reads as an editorial spread rather than a centred SaaS hero.

The homepage carries its own signature: a bespoke before/after process visual in which disconnected enquiry, approval and spreadsheet work becomes an owned, traceable workflow, set against ink #142527 with a controlled vermilion #E45C3A accent and alternating light/dark chapters.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief (DelegationDesk)

• Focal subject: the oversized Anton headline "BIG PLANS. ACTUAL FOLLOW-THROUGH." with its lime underline rule, paired with the task-board illustration on its lifted #1E1E1C plane.
• Input → transformation → outcome thesis: as the page loads, the headline lines reveal with a 40ms stagger and a 12px upward translate over 480ms cubic-bezier(0.2,0.8,0.2,1), settling into the composed editorial frame; the task board is present from the first frame and does not animate. The outcome is a page that arrives with intent and then holds still.
• Motion vocabulary: one purposeful entrance per section — headline lines reveal with a 40ms stagger and a 12px upward translate, 480ms cubic-bezier(0.2,0.8,0.2,1). Tab switching crossfades the panel in 200ms. Hover on links swaps the underline from warm white to lime in 120ms. No parallax, no cursor followers, no marquees.
• Composed first frame: charcoal ground, hairline rule above, headline stacked on three lines with the lime underline already drawn under "FOLLOW-THROUGH", supporting sentence, lime CTA button, secondary text link, and the task board on its lifted plane to the right with the "Illustrative data" label.
• Reduced-motion state: all motion is disabled under prefers-reduced-motion. The headline appears fully composed with no stagger or translate; the tab crossfade becomes an instant swap; hover underline swaps remain instantaneous colour changes.

Other pages

• The homepage, Orbit CRM, Inventory ERP, LeadFlow and Expense & Reimbursement pages follow the same restrained tempo: one purposeful entrance per section, no parallax, no cursor followers, no marquees, and all motion disabled under prefers-reduced-motion.
• The homepage's before/after process visual is a static composition; it does not animate between states.
• The Expense & Reimbursement receipt-to-approval-trail composition is a static composition; the alternating perspectives are laid out as sections, not as an animated sequence.

9. Non-Functional Requirements

NFR-1 — Portability. Each page must open by double-clicking from file:// and must work on any ordinary static host. No local fetch or module imports. Provenance: explicit. Rationale: the user requires portable standalone deliverables.

NFR-2 — No build step or framework. Plain HTML/CSS/vanilla JavaScript only. No React, JSX, Next.js, Vue, routing framework, Tailwind runtime, npm, build step, backend or platform runtime. Provenance: explicit. Rationale: the user requires framework-free source.

NFR-3 — Clean export. No 8080 injected preview scripts, telemetry, data adapters or editor dependencies in the final export. Provenance: explicit. Rationale: the user requires a clean, portable export.

NFR-4 — Responsive layout. Correct at 360, 390, 768, 1024 and 1440px with no clipped headlines, overflow or overlapping badges. Provenance: explicit. Rationale: the user requires these widths.

NFR-5 — Accessibility and zoom. WCAG AA text contrast, keyboard access, visible focus, reduced-motion support, body text at least 16px, accessible mobile navigation and tabs, and legibility at 200% zoom. Provenance: explicit. Rationale: the user requires accessible behavior.

NFR-6 — Asset independence. Optional images and fonts must be licensed local assets with relative paths and font fallbacks; no temporary asset URLs; SVG/CSS illustrations used where appropriate. Provenance: explicit. Rationale: the user requires portability without external dependencies.

NFR-7 — Section and word budget. Roughly 5–7 sections and 450–750 words per app page; the homepage may be longer; each section advances the buying decision. Provenance: explicit. Rationale: the user requires focused pages.

NFR-8 — Distinct design language. Different composition, typography, palette, product illustration and section rhythm per product, not just accent colours; a small "by Flowmative" link on every app page. Provenance: explicit. Rationale: the user requires distinguishable pages.

NFR-9 — Honest claims. No repeated disclaimer paragraphs, artificial scarcity, invented testimonials, clients, figures, guarantees or prices; illustrative product records labelled as sample data; no fake booking forms, payment features or coming-soon alerts; never claim an email was sent merely because the mail app opened. Provenance: explicit. Rationale: the user requires honest marketing.

NFR-10 — Product-specific boundaries. DelegationDesk reminders require background triggers and notification setup, and automatic WhatsApp API delivery is not included by default; Orbit CRM has no automatic email sync, call recording or AI forecasting claim; Inventory ERP requires physical stock checks and accurate entries, and e-invoice support covers export and acknowledgement capture without automatic portal filing or statutory compliance guarantees; LeadFlow's configured nightly sweep can flag missed follow-ups without implying universal automatic outbound messaging; Expense & Reimbursement records reimbursement without transferring money, and email delivery depends on permissions and configuration. Provenance: explicit. Rationale: the user requires these qualifications to be stated.

NFR-11 — Scope discipline. Build only the page named in each brief; do not generate all pages at once; do not deploy, buy anything, provision hosting or generate backend tasks; do not spend credits rebuilding previously completed pages. Provenance: explicit. Rationale: the user requires a review gate and bounded spend.

NFR-12 — Preview versus export. If preview mode uses React internally, clearly distinguish that from the required final plain HTML export; if framework-free source cannot be exported, explain this before generation rather than pretending the preview is the deliverable. Provenance: explicit. Rationale: the user requires an honest deliverable.

NFR-13 — Packaging. The final deliverable is a ZIP of six HTML files plus assets, README and manifest, requested after all six page prompts; the exported designs and code will be independently refined before production use. Provenance: explicit. Rationale: the user requires a complete package.

10. Tech Stack

• Markup and styling: Plain HTML5 with CSS in a single inline <style> block per page. No CSS framework, no Tailwind runtime.
• Scripting: Minimal vanilla JavaScript in a single inline <script> block per page, used only for accessible interactive elements such as the DelegationDesk "How it works" tab set and any reduced-motion handling. No modules requiring a server.
• Illustration: Inline SVG and CSS. No external image dependencies; if images become necessary, licensed local assets in an assets folder referenced by relative paths.
• Typography: DelegationDesk uses Anton for headings and Archivo for body with the fallback stacks specified in Section 6. Each other page uses its own specified typefaces with fallbacks. Fonts are loaded in a way that does not break file:// operation; if a webfont cannot be loaded, the fallback stack carries the page.
• Favicon: Inline SVG data URI or a small local asset referenced by relative path, per page.
• Delivery: Six files — index.html, delegationdesk.html, crm.html, inventory.html, leadflow.html, expense.html — openable from file:// and deployable to any static host, packaged as a ZIP with assets, README and manifest.
• Explicitly excluded: React, JSX, Next.js, Vue, routing framework, Tailwind runtime, npm, build step, backend, database, server-side routing, local fetch, module imports, 8080 injected preview scripts, telemetry, data adapters, editor dependencies, temporary asset URLs.

11. Assumptions and Constraints

Assumptions

• The six pages are the complete deliverable; no other apps are created.
• The mailto: links are the complete conversion mechanism on every page; no form, booking system, checkout, or trial is needed or permitted.
• Inline SVG and CSS illustrations are sufficient product visuals; no photography or external imagery is required.
• The homepage's technology credibility section is small and does not make the homepage read like a developer résumé.
• All six pages are anonymous and public; no account, login, or gated content is involved.
• The exported designs and code will be independently refined before production use.

Constraints

• Work in one project with exactly six final marketing pages: index.html, delegationdesk.html, crm.html, inventory.html, leadflow.html, expense.html. Do not create the other apps. Only these six pages belong in the final navigation and export.
• Preserve existing work as reference; do not delete unrelated files or projects.
• Do not rebuild the actual applications; these are marketing pages.
• Each page must be complete standalone HTML5 with inline CSS and minimal vanilla JavaScript, semantic content present without JavaScript, and relative links to the other five files.
• No React, JSX, Next.js, Vue, routing framework, Tailwind runtime, npm, build step, backend or platform runtime.
• No 8080 injected preview scripts, telemetry, data adapters or editor dependencies in the final export.

• Must work by opening the HTML file directly (file://). No local fetch or module imports.
• Optional images and fonts must be included as licensed local assets with relative paths and font fallbacks. No temporary asset URLs.
• Responsive at 360, 390, 768, 1024 and 1440px; no clipped headlines, overflow or overlapping badges.
• Check 200% zoom, WCAG AA text contrast, keyboard access, visible focus and reduced-motion settings. Body text at least 16px. Mobile navigation and tabs must be accessible.
• Use roughly 5–7 sections and 450–750 words per app page; the homepage can be longer.
• Different design language for each product: change composition, typography, palette, product illustration and section rhythm, not just accent colours. Keep a small "by Flowmative" link on every app page.
• DelegationDesk must keep its original charcoal/lime bold direction.
• No repeated disclaimer paragraphs, artificial scarcity, invented testimonials, clients, figures, guarantees or prices. Illustrative product records must be labelled as sample data. No fake booking forms, payment features or coming-soon alerts.
• Never claim an email was sent just because the mail app opened.
• Show normal credit estimates. Do not deploy, buy anything, provision hosting or generate backend tasks.
• If preview mode uses React internally, clearly distinguish that from the required final plain HTML export. If framework-free source cannot be exported, explain this before generation rather than pretending the preview is the deliverable.
• Do not spend credits rebuilding previously completed pages.

• index.html: remove or rewrite unsupported material from the original — "10+ projects", "50+ processes", "3+ years", "100%", "dozens of production systems", guaranteed 24-hour responses, "nothing missed", absolute error elimination and sector-wide compliance claims. Do not invent testimonials, client logos, case-study outcomes or live demos. Replace alert('Demo coming soon!') links with actual product pages or enquiry links. Keep unfinished or private project references out of the proof section unless their status is explicit.
• index.html: the referenced Flowmative Final Logo.png was not supplied — use a tasteful text wordmark and a simple favicon; do not ship a broken image or pretend a new symbol is the supplied logo.
• index.html: do not imply all five products already integrate automatically; do not promise compatibility without discovery; support scope is agreed, not unlimited by default; do not make the homepage read like a developer résumé.
• index.html: do not create a sixth product or links to products outside the six-page project scope.
• delegationdesk.html: reminders require background triggers and notification setup. No automatic WhatsApp API delivery by default. Do not guarantee that no task will ever be missed. Avoid presenting employee scores as an objective measure of personal worth.
• crm.html: no automatic email sync, call recording or AI forecasting claim. Any forecast or probability is configured or entered information, not a guarantee.
• inventory.html: physical stock checks and accurate entries remain necessary. E-invoice support includes export and acknowledgement capture; do not claim automatic portal filing or statutory compliance guarantees. Do not invent reservation functionality.
• leadflow.html: a configured nightly sweep can flag missed follow-ups; do not imply universal automatic outbound messaging. Do not promise conversion gains. Distinguish this configurable lead workflow from Orbit CRM's accounts/contacts/deals emphasis.

• expense.html: recording reimbursement does not transfer money. Email delivery depends on permissions and configuration. No automatic bank integration or fraud-detection guarantee.
• Every page: do not literally show instructions such as "read left to right", "capability earns its place" or "illustrative answers". Keep setup qualifications in a relevant FAQ. Do not turn the page into technical documentation.
• Every page: use relative links only to index.html, delegationdesk.html, crm.html, inventory.html, leadflow.html and expense.html.
• Do not generate all pages at once; build only the page named in each brief, save it in the project, and wait for the next brief.
• Visual direction for DelegationDesk: charcoal #151515, warm white #FAF9F3, lime #C2F547 with restrained supporting neutrals; bold oversized typography, strong contrast, Spotify-inspired confidence without copying Spotify branding or assets.
• Avoid generic pastel cards, decorative gradients, excessive badges, repetitive feature grids and emoji icons; product visuals should illustrate actual task ownership and follow-up, not random analytics.
• Keep paragraphs readable and concise; use large headings responsibly on mobile; all important text must remain legible at 200% zoom.
• Reference headline "BIG PLANS. ACTUAL FOLLOW-THROUGH." and supporting message "You hired a team. You shouldn't have to be its reminder app." may be improved while retaining purpose and honest claims.
• Background triggers and notification settings must be configured during deployment.

12. Glossary

• Flowmative: A custom software and automation agency in Panipat, India, working remotely; services are custom web applications, business systems, workflow automation, Google Workspace automation and reporting dashboards.
• DelegationDesk: The existing task and delegation management application marketed by delegationdesk.html.
• Orbit CRM: The existing CRM application marketed by crm.html, covering accounts, contacts, deals and activities.
• Inventory ERP: The existing inventory application marketed by inventory.html, covering stock, purchasing and warehouse records.
• LeadFlow: The existing lead management application marketed by leadflow.html, covering configurable lead capture, assignment and follow-up.
• Expense & Reimbursement: The existing expense application marketed by expense.html, covering claims, approvals and reimbursement records.
• Responsible owner: The person who performs the task.
• Accountable owner: The person ultimately answerable for the task's outcome.
• Consulted participant: A person whose input is sought before or during the task.
• Informed participant: A person kept aware of the task's progress or outcome.
• Authority level: The scope of decisions a person can make on a task without returning the question to the owner.
• Acceptance criteria: The stated conditions that define what completion means for a task.
• Escalation: A multi-level rule that surfaces approaching deadlines and overdue work to appropriate people.
• Reminder: A configurable notification rule; background triggers and notification settings must be configured during deployment.

• Recurring task template: A repeat-work definition that generates routine tasks.
• Risk indicator: A signal that helps managers identify blockers.
• Task history: The record of a task's execution, used to review outcomes with context.
• Team dashboard: A manager-facing view of team execution.
• Relationship map: The Orbit CRM visual linking one account to its contacts, deal and recent activities.
• Stock ledger: The Inventory ERP record of quantity history across receipts, issues, transfers and adjustments.
• Cycle count: A periodic physical stock check recorded against the stock ledger.
• Lead-to-next-action ribbon: The LeadFlow visual connecting a lead to its owner, stage and scheduled follow-up.
• Approval trail: The Expense & Reimbursement record of a claim's decisions, remarks and status changes.
• Advance: An Expense & Reimbursement payment made before a claim is settled.
• Sample data: The label applied to any illustrative product record or visual on the pages to make clear its records are not real.
• Standalone file: A single HTML file with inline CSS and JavaScript that opens from file:// and works on any ordinary static host.
• ZIP deliverable: The final package of six HTML files plus assets, README and manifest, requested after all six page prompts.