Requests

1In one sentence#

The Request module is LumosCRM's service-delivery engine: every job your agency does for a client — "book the yacht charter," "arrange the private jet," "secure the Michelin table for eight" — is captured as a Request that moves through a clear lifecycle, is assigned to staff, broken into tasks, sourced to vendors, tracked against a deadline with a live SLA countdown, and recorded end-to-end with communications, files, and a complete audit trail.

If the Client module answers "who is this client and what do they want?", the Request module answers "what are we doing for them right now, who's on it, and are we on time?"

2Who it's for#

3The core idea: a request is a living workspace#

A Request is far more than a to-do line. It's a structured workspace that pulls together everything needed to deliver a piece of service:

                         ┌──────────────────────────────┐
                         │          REQUEST              │
                         │  REQ-104872 · for a Client    │
                         │  status · priority · SLA clock │
                         │  brief · budget · sensitivity  │
                         └───────────────┬──────────────┘
                                         │
   ┌──────────────┬──────────────┬───────┴───────┬──────────────┬──────────────┐
   │              │              │               │              │              │
  Tasks       Vendors      Communications      Files       Participants     Audit
 (checklist,  (source →    (logged calls,    (uploads +    (watchers,      trail
  blocking,    confirm →    emails, msgs,      promote to    approvers,    (every
  due dates,   pay, with    inbound/out)       Document      escalation     change,
  assignees)   pricing)                        Vault)        targets)       forever)

Each request is permanently anchored to one client and to the staff member who raised it — both fixed at creation so the record's ownership and origin can never drift.

4Capabilities at a glance#

5The request lifecycle#

Status — where the request is in its journey#

Priority#

Low · Normal · Urgent · High · Critical — drives ordering and visual urgency in the queue. New requests default to Normal.

How a request arrives (channel)#

Each request records how it came in: client portal, staff portal, WhatsApp, email, phone, in person, or API.

Category#

Out of the box: dining, travel, accommodation, events, lifestyle, transportation, gifting, wellness, security, legal, medical, real estate, yacht, aviation, other — with an optional free-text sub-category.

Note for marketing: Statuses, priorities, channels, and categories are configurable option-sets (Settings → Requests). The lists above are the shipped defaults; an agency can rename or extend them to fit its own language and service lines.

Cancellation#

Requests are never hard-deleted. Cancelling a request records who cancelled it, when, and why, sets its status to Cancelled, and removes it from the active queue — while keeping the full record and audit trail intact for the future.

6The SLA clock — on-time service, made visible#

LumosCRM treats timeliness as a first-class feature. Every request can carry a deadline, and the product turns that into a live SLA countdown that appears in three places:

• On each row of the work queue
• In the header of the request detail page
• In the request's context rail

The countdown updates automatically (every 30–60 seconds) and is color-coded:

• Green — comfortably on time
• Amber — less than 24 hours remaining ("at risk")
• Red, pulsing — past the deadline ("breached")

The queue header surfaces these as live KPIs — Open, SLA Breached, At Risk (< 24h), Awaiting, Completed (7 days) — so a team lead can see the health of the whole operation in one glance and act before a breach happens.

7Screen-by-screen walkthrough#

7.1The Request queue (index)#

The operational home of the module — a live, filterable list built for people working tickets all day.

Header & KPI strip: live counts for Open (and how many unassigned), SLA Breached, At Risk, Awaiting (client/vendor), and Completed this week. A tagline reminds users that SLA timers refresh continuously and sensitive items are hidden from non-assignees.

Views (tabs): Live Queue · Assigned to Me · Unassigned · SLA Breached · Awaiting · Completed · All — each with a live count.

Filters: free-text search (title, code, client), priority chips, a status menu, and a category menu, with a one-click "clear all."

The table shows, per request: a priority bar, the title + request code + channel icon (with sensitive/NDA badges), the client (avatar, name, tier dot, code), category, status badge, vendor summary, assignee, the live SLA pill, and an activity summary (tasks done/total, participant count, communications count). Rows can be selected for bulk actions (assign / escalate), and each row has quick edit/delete actions.

Paging: 20 requests per page. A New Request button and an export action sit in the header.

7.2Creating a request#

Creation uses a guided, multi-section form with a left-hand section navigator, a completion ring showing how complete the request is, and a live preview card. Real-time validation flags problems as the user types.

The sections:

1. Client & origin (required) — choose the client, the submitting staff member, the intake channel, and an optional source detail (e.g. "discussed at Mayfair lunch")
2. Identity & brief (required) — an optional external reference, the title, and a full brief & objective
3. Classification (required) — category, optional sub-category, and priority
4. Schedule — requested-for date, hard deadline, a service window (from/to), one or more locations, and party size (adults / children / notes)
5. Client context — codename, PA/contact, a privacy-protocol toggle (no social posting, discreet vendors), and an "on behalf of" block (name, relation, note)
6. Budget & billing — estimated cost, budget cap, actual cost (each with currency), billing entity, and payment terms
7. Assignment — assign to a staff member and/or a team
8. Vendors — add one or more vendors inline, each with a role, status, reference, and proposed/agreed pricing
9. Sensitivity & compliance — sensitive, NDA-required, redact-in-exports, internal-only toggles, plus GDPR lawful basis and a classification label
10. Tags & flags — free-form labels
11. Internal notes — private staff context
12. Review & submit — a summary with a clear "ready to submit" or "required fields missing" state

Minimum to create: a client, a title (more than a few characters), and a category. Everything else can be added now or later. The Submit button stays disabled until those essentials are set, and on error the form scrolls to the first issue.

Each request is automatically assigned a unique, human-readable request code (e.g. REQ-104872) at creation. It never changes and is used in all references.

7.3The Request detail page (show)#

The handler's cockpit for a single request.

Header (sticky): external reference (if any), sensitive / NDA / privacy-protocol badges, the title and brief, a meta strip (category, channel, created-time), and a set of tiles for Status, Priority, and the live SLA countdown (with the deadline beneath). Header actions: copy link, open the client, edit, and more (delete/cancel).

Tabs (each permission-gated):

Context rail (right): a client card, an SLA card, the assignment card (assignee + team), a participants card (watchers/approvers/escalation contacts), a sensitivity card (sensitive, NDA, privacy protocol, GDPR basis, classification), and quick-jump actions.

Almost everything is editable in place through drawers — update the brief, add a task, log a call, attach a file, engage a vendor — without leaving the page. Heavier data loads on demand for speed.

7.4Editing a request#

The edit screen mirrors the create form (minus the Client & origin section, since the client and submitter are locked). It shows the read-only request code, exposes the status field, and tracks changes — the Save button activates only when something has actually changed.

8Feature deep-dives#

8.1Tasks — the request broken into steps#

Turn a request into an ordered checklist. Each task has a type — action, approval, vendor booking, client confirmation, document collection, payment, follow-up, or quality check — a status (pending, in progress, completed, cancelled, skipped, blocked), an optional assignee and due date, and a "blocking" flag for steps that must finish before the request can complete. Marking a task done automatically stamps its completion time; the request's overview shows live progress (e.g. "3 / 7 complete").

8.2Vendors — sourcing and engagement pipeline#

Attach the suppliers working on a request and move each through a full engagement pipeline: sourced → enquired → proposal received → negotiating → confirmed → (rejected / cancelled) → completed → invoiced → paid. Each vendor has a role (primary, secondary, backup, sub-contractor, specialist), proposed and agreed pricing (each with currency), a booking/quote reference, and private internal notes. Status changes automatically stamp their timeline (enquired, confirmed, cancelled, completed). The vendor itself is locked once linked, so the engagement history stays accurate.

8.3Communications — a complete contact record#

Log every interaction tied to a request — inbound, outbound, or internal — across channels (email, call, WhatsApp, SMS, and more), with a subject, body, timestamp, and file attachments (up to 25 MB each). Each entry can be flagged sensitive or client-visible. Communications are write-once — a faithful, tamper-resistant record of what was said and when.

8.4Files & the Document Vault#

Attach files by type — document, confirmation, contract, invoice, image, itinerary, ticket, proposal, receipt — up to 25 MB each, with client-visible and sensitive flags. Any attachment can be promoted into the central Document Vault with a category, a classification level (public, internal, confidential, restricted, top-secret), and a GDPR lawful basis — so a booking confirmation captured on a request becomes a governed, searchable document across the whole CRM.

8.5Sensitivity, privacy & compliance controls#

Built for discreet, high-profile work:

• Sensitive requests are hidden from staff who aren't assigned to them.
• NDA-required gates external sharing.
• GDPR lawful basis (contract, legitimate interest, consent) is captured on the request.
• The brief and internal notes are encrypted at rest.
• A privacy protocol mode, codename, and "on behalf of" context support ultra-discreet handling.
• Redact-in-exports and internal-only flags control how a request appears downstream.

8.6Budget tracking#

Capture three money figures per request — estimated cost (the staff estimate), budget cap (the client's ceiling), and actual cost (the final number) — each in its own currency, feeding cost visibility on the overview and the queue.

8.7Participants — the stakeholders around a request#

Beyond the single assignee, a request surfaces its participants — people in roles such as watcher, CC, approver, escalation target, observer, or secondary handler — shown in the context rail so everyone knows who's in the loop. Each participant carries notification preferences for events like status changes, SLA breaches, escalations, vendor confirmations, and completion.

8.8Audit trail & timeline#

Every meaningful action on a request is recorded with the actor, their role, what changed (before and after), and the time, IP, and session. The log is permanent and unchangeable — the backbone for accountability and compliance. A parallel, append-only timeline captures lifecycle milestones (created, acknowledged, assigned, vendor confirmed, SLA breached, escalated, completed, and more), some of which can be made client-visible.

9Security & access control#

• Granular, role-based permissions govern every area: the record itself (view / create / update / delete), tasks, vendors, communications, and files each have their own permission set.
• Per-user record scoping (self-scoping): self-scoped users see only the requests assigned to them or raised by them. The ownership rule is enforced both in the underlying queries and in the access policy, so a handler can't reach a colleague's confidential request. Broader roles (e.g. operations leads) see the full queue.
• Sensitive-item shielding: sensitive requests drop out of lists for non-assignees automatically.
• Encryption & GDPR: encrypted briefs and notes, NDA gating, and lawful-basis capture are built in.

10Search & integration#

• Global search (⌘K): find any request by its code, title, or the client's name; results show the status as a badge and link straight to the request. Results respect each user's scope.
• Request pickers across the CRM: other modules can attach a request through a smart picker, filterable by status, priority, category, and client — including a "briefable" filter (open requests with no vendors yet) used by the vendor-brief workflow.
• Cross-module ties: a request links to its client (and appears on the client's Requests tab), engages vendors (and appears on each vendor's Requests tab), and can push files into the Document Vault — keeping the whole CRM joined up.

11Use cases & scenarios#

Use case A — A request lands by WhatsApp#

A client messages their concierge to arrange a private dinner. The handler clicks New Request, picks the client, sets the channel to WhatsApp, writes the brief, chooses category Dining and priority High, sets a deadline for Friday, and assigns it to themselves. A request code is issued and the SLA clock starts. The whole thing takes a minute.

Use case B — Working the queue against the clock#

A team lead opens the SLA Breached and At Risk views first thing. Two requests are amber. They reassign one to a free handler and escalate the other — all before either breaches. The live KPIs update instantly.

Use case C — Sourcing vendors for a yacht charter#

For a charter request, the coordinator adds three vendors, marks one primary, and moves each through enquired → proposal received → negotiating. When the client picks one, that vendor becomes confirmed with an agreed price; the others are marked rejected. The status timeline records every step.

Use case D — Keeping a discreet brief discreet#

A high-profile client's security request is marked sensitive and NDA-required, with a codename and privacy-protocol mode on. It disappears from the queue for everyone except the two assigned handlers, its brief is encrypted, and it's flagged to be redacted from exports.

Use case E — A clean paper trail for delivery#

Across a complex travel request, the handler logs every call and email, attaches the flight confirmation and itinerary, and promotes the contract into the Document Vault as Confidential. When the client later asks "what exactly was booked?", the full record — communications, files, tasks, and timeline — is right there.

Use case F — Proving who did what#

A dispute arises over a cancelled booking. Compliance opens the request's Audit tab and reads the immutable history: who changed the status, when, from what to what, and from which session — case closed.

12Permissions reference (simplified)#

Roles are assembled from these permissions in the RBAC module, so each agency controls exactly what each team member can see and do.

13Platform foundations (built into the data model)#

The Request module ships with deeper infrastructure already designed into its data foundation. These power the shipped experience and/or are ready to be surfaced — worth knowing for the product roadmap story, but not all are exposed in the current UI:

• SLA policy engine. Beyond the simple per-request deadline that drives today's live countdown, the platform models full SLA rules — acknowledgement, response, and resolution targets that vary by client tier × category × priority, with breach escalation, client-notification, and effective-dating — plus per-request SLA snapshots that record each target's deadline, breach, and resolution. This is the foundation for fully policy-driven SLAs.
• Request templates. Reusable request blueprints (with pre-defined task lists, default priority/team, estimated duration, and relative due-date offsets) are modeled, so common request types can be spun up complete with their checklist — and optionally offered to clients to self-select.
• Structured feedback & NPS. A post-delivery feedback model captures overall, service, communication, and vendor scores, an NPS rating (promoters/detractors), and written highlights — with publish permission derived from the client's consent record.
• Stakeholder notifications. Participants carry per-event notification preferences, the basis for automated watcher/approver alerts.

For marketing: treat the Sections 5–12 features as the shipped, demonstrable product. The items in this section are platform strengths and roadmap-ready foundations — describe them as "built to support" rather than as live screens, unless confirmed shipped.

14Glossary#

This document describes the Request module as currently built. Statuses, priorities, channels, and categories, and other configurable option-sets, can be tailored per deployment in Settings → Requests. Items in Section 13 are platform foundations; confirm UI availability before presenting them as live features.