POC deal room workflow for solution engineers

Starting promptUse this prompt as a starting point to build your workflow.

Build a POC deal room application for solution engineers running proofs of concept with prospective customers. The purpose: give each POC engagement one shared source of truth — the use cases being evaluated, success criteria, tasks, and scheduled calls — so both the SE and the customer can see how the trial is going instead of tracking it across scattered emails, decks, and spreadsheets. Each customer gets their own room at its own shareable link. Trigger it entirely by HTTP routes — no cron, email, or upstream steps. There are three routes: An internal SE console (space-only auth) that lists every deal room with progress and search, and lets an SE create a new room, copy the customer-facing link, and delete rooms. Customers must not be able to reach this page. A customer-facing room page (accessible to customers without an account) that renders a single room selected by an id in the URL. It should support inline editing of everything in the room and a share action that copies the room's link. Visiting it with no room id should show a neutral "no room selected" state, never the full list. A persistence API that stores each room and supports listing all rooms, fetching one room, and creating/saving/deleting a room. Persist the data inside the workflow using a volume-backed SQLite store — or another persistence approach you prefer — so rooms survive across runs with no external infrastructure to provision. Store each room as a self-contained document. Track, per room: use cases (each with an owner and description), success criteria per use case as a met/not-met checklist, tasks per use case (assignee, status, due date), and a calendar of agreed calls shown as month grids plus an agenda list. All data is hand-entered and should autosave. Note the security tradeoff: making the room page and API openly reachable keeps customer access frictionless but means anyone with a link can view and edit a room. Decide how much to tighten the route authentication based on whether real customer data will live here. Tools used: 3B named volume (SQLite persistence), React (frontend UI steps), TypeScript

New to Tines?Sign up free for Tines 3B Explore Edition

What this prompt builds

A POC deal room application for solution engineers running proofs of concept with prospective customers. Each engagement gets a shareable room that tracks use cases, success criteria, tasks, and scheduled calls in one place, replacing scattered emails and spreadsheets. Built with volume-backed SQLite persistence and frictionless customer access via public links.

The problem

Solution engineers running proofs of concept with prospective customers need a shared, single source of truth for how each trial is progressing — what's being evaluated, whether success criteria are being met, who owns which tasks, and when the next calls are scheduled. Without a dedicated system, that information lives scattered across spreadsheets, emails, and slide decks, so nothing stays current and neither the SE nor the customer has a clear view of where the POC stands. This workflow gives each POC engagement its own shareable deal room where use cases, success criteria, tasks, and scheduled calls all live in one place both sides can see, replacing the chaos of disparate documents with a real-time, always-current workspace accessible via a single link.

Solution and impact

SEs create and share a deal room in seconds, and customers open it with no account or login required — just a single link. Use cases, met/not-met success criteria, task statuses, and call schedules all live in one always-current view, so "how's the POC going?" is answerable at a glance for the customer, the SE, and management. The workflow persists data in a volume-backed SQLite store inside the workflow itself, so there's zero external infrastructure to provision or maintain. The tradeoff: to keep customer access frictionless, room pages and the API are publicly reachable, meaning anyone with a room link can view and edit it — fine for a demo, but route authentication should be tightened before real customer data goes in.