BeddyDocs Uploader

Automation agent designed to receive guest documents through Telegram, connect them to the correct booking context, and upload them into the Beddy property management workflow through structured browser automation.

Document-handling automation layer built to reduce manual check-in friction inside a real hospitality operation.

BeddyDocs Uploader is a focused operational system created to simplify a repetitive and sensitive hospitality workflow: collecting guest documents, matching them to the correct reservation, and inserting them into the management platform without manual handling at every step.

The project is built as a practical orchestration flow between messaging input, booking context, and browser-based execution.
Its value lies in transforming a document-upload task into a structured and repeatable operational process.

What it does

• Receives guest document inputs through a Telegram-based interaction flow
• Associates incoming documents with the correct booking or room context
• Opens the Beddy management workflow through browser automation
• Navigates the relevant guest/document upload flow inside the platform
• Uploads the selected documents into the correct reservation context

System structure

• Input layer
  Telegram acts as the operational entry point for document submission and run activation.

• Run management layer
  The system stores and organizes the run context, including booking reference and attached files.

• Browser automation layer
  An automated workflow enters the management platform and navigates the required document-upload steps.

• Execution layer
  Documents are uploaded into the correct booking flow inside the platform interface.

System flow

The system operates as a messaging-driven document upload workflow:

1. A document package is received through the Telegram bot.
2. A command parser interprets the incoming request and extracts the operational instructions.
3. The run manager creates and stores the execution context in a temporary run layer.
4. A run watcher monitors the execution state and hands control to the Beddy worker.
5. The Beddy worker coordinates authentication, session reuse, and upload execution.
6. If authentication requires verification, an OTP bridge handles the recovery path through Telegram.
7. The Playwright browser opens the Beddy environment and navigates the upload workflow.
8. The upload flow inserts the guest documents into the correct booking path.
9. Telegram notifications report execution progress and final status.
10. Session storage preserves browser state for continuity across runs.

Architecture diagram

Operational proof

This system was designed as a real hospitality document-upload workflow, not as a conceptual prototype.
It receives operational commands through Telegram, preserves run context, reuses session state, handles OTP recovery when needed, and executes browser-based document upload into the booking workflow inside the management platform.

Input / Output

Input

• Telegram-based upload commands
• Guest document packages
• Booking-related upload context
• Session and authentication state

Intermediate outputs

• Parsed command instructions
• Temporary run-state files
• Session persistence data
• Execution notifications and status updates

Final output

• Guest documents uploaded into the correct booking workflow
• Telegram notifications confirming progress, success, or failure

Component roles

• Telegram Bot
  Receives incoming document-upload requests and starts the workflow.

• Command Parser
  Interprets the request and extracts operational parameters.

• Run Manager
  Creates and stores the execution context for the current upload cycle.

• tmp_runs / run.json Storage
  Preserves temporary run-state information during execution.

• Run Watcher
  Monitors workflow status and coordinates handoff to the execution layer.

• Beddy Worker
  Orchestrates authentication, browser control, and upload execution.

• Credentials Layer
  Provides the required authentication inputs.

• Session Storage
  Preserves browser/session continuity across runs.

• Playwright Browser
  Opens and navigates the target management platform.

• OTP Bridge
  Handles verification recovery when login requires OTP confirmation.

• Telegram Notify
  Sends progress and outcome notifications back to Telegram.

Why this architecture exists

This system is structured as a layered workflow because document upload in a live hospitality environment is not a single action, but a coordinated sequence involving command intake, execution state, session continuity, browser automation, verification fallback, and reporting.

The separation between parsing, run management, worker execution, OTP handling, session storage, and Telegram notifications creates a more stable and recoverable architecture.
Instead of relying on one monolithic upload script, the workflow preserves execution context and isolates fragile steps into dedicated layers.

This makes the system easier to supervise, debug, and evolve over time.

Real-world constraints

This project was designed around real operational constraints, including:

• Telegram-based operational triggering
• booking-context preservation across runs
• session persistence for continuity
• OTP-based login recovery
• browser-driven interaction with a live management platform
• file upload reliability
• clear operational feedback to the human operator

Because of these constraints, the architecture prioritizes recoverability, modularity, and controlled execution over simplistic one-step automation.

Project structure

The repository is organized as a layered operational system, with separate modules for command intake, parsing, run-state handling, browser execution, OTP recovery, notification delivery, and session continuity.

The structure reflects the workflow described above: messaging logic, execution logic, and recovery logic remain separated so the system can reliably process upload requests while preserving context and reducing manual friction.

Why it matters

Manual document handling in hospitality operations is slow, repetitive, and easy to mismanage when done across multiple bookings and guests.
This project exists to reduce that friction by creating a structured document-upload pipeline connected to a real operational workflow.

Its value is not just speed, but consistency: the system reduces manual overhead while making a sensitive process more repeatable and easier to supervise.

Operational logic

BeddyDocs Uploader works as a bridge between incoming guest documents and the booking-management environment where those documents must be inserted.

Its operational sequence is simple but high-value:

• receive documents
• preserve booking context
• open the correct workflow
• upload into the correct reservation path

This makes the project a strong example of applied workflow automation in a real hospitality setting.

Status

Active internal project with functioning Telegram input flow, run-context handling, and browser-based upload logic connected to the management workflow.
The system is already operational as a practical document-handling automation layer.

Scope

This project is designed as a focused internal workflow automation system for a specific hospitality process.
It is not intended as a general SaaS document platform, but as a custom operational architecture built around booking context, file handling, and structured upload execution.