REQUEST - Senior Full-Stack Developer (NON GREENFIELD)
Worldwide
Revision Note — v1.4 (identity & tracking — a first-class citizen). Made explicit that a service_request is a first-class object in the shared operational object model (Library/Board v1.5 §2), carrying the platform-standard identity ( uuid VARCHAR(36) + human-readable reference_id , exactly as organizations/hotels do per migration 010), tenant scope, lifecycle, immutable provenance, and relationship links — defined once, reused, never a parallel identity or tracking scheme. Added §11A Tracked with everything else — toward outcomes: requests correlate to the guest stay, room/asset, property, and time so reactive-work performance reports alongside all operational data and rolls up toward guest-experience outcomes (OHI). Object model, audit, and milestones updated. Revision Note — v1.3 (notifications & delivery, reconciled to Communications Layer v4). Added §7B Notifications & delivery — an event-based model where Requests emits its lifecycle events and subscribes to Comms intent events, never reaching into the Comms layer (Comms v4 §23 anti-rewrite spine). Channels: live voice announce, push via the Thin Native Container (Comms §20), in-app, email, SMS fallback — with delivery owned by Comms/the container, not Requests. Reuses Comms addressing resolvers (presence / department / position / area / board) instead of inventing routing. Adds a configurable settings matrix (event × channel × role, org/property defaults, shift-aware quiet hours, escalation ladder, safety override). §9 corrected: Comms transcribes + classifies + emits the intent event; Requests is the consumer (the one Comms v4 says is "built later in Agenda/PDEE"), with acknowledge ↔ request correlation so a spoken "taking it" can't drift from an open request. Dependencies, milestones, audit updated. Revision Note — v1.2 (communication intelligence + share + view receipts). Per direction, the request's communication is treated as a first-class data source — not just a thread to read later. Added: share (give someone visibility without making them an owner — a viewer grant via the existing chat participant role); view receipts (delivered → viewed → acknowledged, reusing messages_seen + last_read_at , with unviewed-by-assignee surfaced for accountability); voice notes transcribed into the searchable thread; and Intelligence over the thread (§8) — theme/asset extraction ("TV remote again"), sentiment/guest-impact flags, thread summaries for handoff, and resolution-knowledge capture that mines how a request was fixed and drafts it into the Library. All advisory, tenant-scoped, and functional with Intelligence disabled. Revision Note — v1.1 (collaboration added). A gap was caught: v1.0 covered evidence-on-close but not the live, day-to-day team interaction on a request — comments, responses, adding people, and attaching photos/files mid-flight — which the legacy system had. §7A is added to specify request collaboration, built entirely on existing infrastructure: the tie-message thread pattern ( message_model ), the chat participant model ( Chat_model — add/remove people, search), and the governed media spine ( Media_attachment / Media_file / Media_link ). No second chat system is built. Object model, dependencies, milestones, and audit updated to match. Revision Note — v1.0 (code-audit reconciliation). The develop branch was audited against this scope. Most dependencies check out and are richer than assumed; several findings changed this document so the developer builds onto existing infrastructure instead of reinventing it. Confirmed present (reuse, don't rebuild): the Foundations spine — organization , hotels , hotel_branches (hotel locations), and user_hotel_location_assignments + user_active_hotel_location for portfolio scoping; the inventory_usage / inventory_adjustment / inventory_restock ledger (a mature subsystem); the NotificationService library (the single notification entry point — the legacy ticket even disabled its own writes in favor of it); the ai_governance_* layer plus ai_structured_output_model (ideal for voice → structured draft); per-user language preferences + the translation layer; immutable audit_logs triggers. Findings that changed the scope: (1) scoping resolves through hotel_location_id (org → hotel → location), not hotel_id alone — corrected
$750.00
Fixed-price- IntermediateExperience Level
- Remote Job
- One-time projectProject Type
Skills and Expertise
Activity on this job
- Proposals:5 to 10
- Last viewed by client:2 days ago
- Interviewing:8
- Invites sent:12
- Unanswered invites:3
About the client
- United StatesHollywood5:27 AM
- $4.6K total spent90 hires, 13 active
Explore similar jobs on Upwork
How it works
Create your free profileHighlight your skills and experience, show your portfolio, and set your ideal pay rate.
Work the way you wantApply for jobs, create easy-to-by projects, or access exclusive opportunities that come to you.
Get paid securelyFrom contract to payment, we help you work safely and get paid securely.
About Upwork
- 4.9/5(Average rating of clients by professionals)
- G2 2021#1 freelance platform
- 49,000+Signed contract every week
- $2.3BFreelancers earned on Upwork in 2020
Find the best freelance jobs
Growing your career is as easy as creating a free profile and finding work like this that fits your skills.
Trusted by