Acquisition & onboarding
Public product pages and guided setup turn a service business's requirements into a usable starting configuration.
Selected work
Owner-built product · SwiftBookPro
Building an AI receptionist that connects the call to the operation.
Call-dependent service businesses cannot treat each inbound conversation as an isolated interaction. After-hours demand, qualification, booking, and emergency routing all need to connect to the way the operation actually works.
- Built by
- DENEGRI
- Posture
- Owner-built product
- Boundary
- Conversation through operator workflow
Zero to oneOne product boundary
Public experience · telephony · AI orchestration · scheduling · operations
01
The starting condition
Answering the phone is only the visible edge of the problem.
A useful receptionist product has to understand why someone is calling, apply the business's rules, reach the right scheduling or routing tool, and preserve enough context for the operator. The product therefore had to span the customer-facing moment and the systems behind it.
Design premise
The call is not the outcome.The outcome is a consistent next step connected to the operation.02
The product boundary
The architecture follows the work from first contact to operator oversight.
SwiftBookPro joins multiple technical surfaces without pretending they are one simple feature. Each layer has a defined role, while the product experience keeps the handoff coherent.
Telephony ingress
Inbound calls enter a controlled communications path before conversational logic decides what the caller needs.
Conversation orchestration
AI and bounded tools coordinate qualification, service context, emergency routing, and the next appropriate action.
Scheduling connections
Calendar and scheduling integrations connect the conversation to availability and the booking workflow.
Operator surfaces
Separated operational storage, APIs, and dashboards give the business a place to configure and oversee the system.
03
Architecture in practice
Keep the interfaces clear. Keep sensitive operations behind the boundary.
The public experience, server proxy, orchestration services, integrations, storage, and operator tools have different responsibilities. That separation makes the product easier to reason about without publishing private implementation detail.
Public surface
Next.js product and onboarding experienceApplication boundary
Server-hosted proxy between the browser and operator APIsOrchestration boundary
Node and TypeScript services coordinating telephony, AI, tools, and schedulingOperating boundary
Separated storage and dashboards for configuration and oversight04
Bounded evidence
Observed 05 August 2026 · 18:24 UTC
The public application path and backend health route each returned HTTP 200.
The observation was an unauthenticated request at one recorded instant. The backend response identified ai-receptionist-backend, version 1.0.0.
What this establishes
Availability at that instant.It does not establish uptime, call quality, latency, booking success, revenue, customer adoption, or commercial traction.What this work demonstrates
Product judgment across the whole operating path.
Building SwiftBookPro required product definition, interface work, systems architecture, provider integration, data boundaries, and operator tooling to stay connected. It is an owner-built demonstration of how DENEGRI approaches a communication-heavy workflow from zero to one—not a claim about a client result.
Start with the workflow
Where does communication stop connecting to the operation?
Bring the call flow, handoff, scheduling path, or operator process that needs to work as one system. The first conversation is about understanding the boundary and choosing the right move.
Talk through the problem