MASOUD BAHRAMIAI-NATIVE PRODUCT DEVELOPER
CASE / 012SUBSCRIPTION / OPERATIONS

PENNY TUNNELPenny Tunnel

A service-delivery and subscription-management system for secure connectivity, from payment and renewal to user-status control.

ROLEPRODUCT · BOT · OPERATIONS
STATUSBOT AVAILABLE
VISIBILITYPUBLIC BOT / PRIVATE OPERATIONS
OUTPUT07 DELIVERABLES
PUBLIC SYSTEM MAP / SANITIZEDCASE/012
PRIVACY BOUNDARY

To protect data and infrastructure, a functional diagram replaces a real screenshot.

ModelSubscription services
User interfaceTelegram bot
OperationsPayment, renewal, and user control
Detail levelLimited public disclosure
FUNCTIONAL SYSTEM MAP

How does the project work?

The four stages below show the product’s primary flow without exposing sensitive data or details.

  1. 01 / 04

    Selecting a service

    The user sees the appropriate option and their subscription status.

  2. 02 / 04

    Payment and activation

    The transaction connects to the service-delivery flow.

  3. 03 / 04

    Lifecycle control

    User status, duration, and access are managed in the system.

  4. 04 / 04

    Renewal and support

    Before the period ends, the user reaches a renewal or follow-up path.

01
PRODUCT FRAME

Selling a subscription is not merely delivering access

A subscription service has a lifecycle: selection, payment, activation, use, period end, renewal, and support. If these stages are managed separately, human error and response time increase.

Penny Tunnel was built to connect that lifecycle in a conversational interface and management layer.

02
SELF SERVICE

Users should know their status without a manual message

The bot is the user’s access point for purchase, status, and renewal. Information users can see themselves should not remain dependent on a manual support conversation.

This self-service flow must transparently handle failed payments and expired subscriptions while remaining simple.

03
PAYMENT FLOW

The transaction must connect to service status

A successful payment has value only when its result is recorded in the operating system and the related service is activated. The product flow must create consistency between the financial event and user status.

Gateway names, account details, and fraud-control mechanisms are not published in the public version.

04
LIFECYCLE

Renewal is a predictable event

The end of a period should not be sudden or unclear. The system should track time status and make a renewal path available at the appropriate point.

This logic reduces manual operational pressure and creates a more continuous subscription experience.

05
ADMIN CONTROL

User control without direct infrastructure manipulation

The management layer turns user status and related operations into controllable work. The goal is to separate daily tasks from scattered commands and direct system intervention.

Connectivity-infrastructure details and security information are deliberately kept outside the case study.

06
CURRENT STATE

Public experience in the bot, operations behind a security boundary

The bot is public, but the panel and service-delivery logic are private. No sales data, user count, or transaction amount is published on this page.

A specialist product presentation is possible with a controlled demo and synthetic data.

DELIVERED SURFACE

What was built within the project scope.

This list is based on project outputs that can be stated publicly—not speculative features or unverified technology.

  1. 01Subscription lifecycle design
  2. 02User bot
  3. 03Payment integration
  4. 04Activation and status
  5. 05Renewal
  6. 06User control
  7. 07Support operations
CAPABILITY SIGNAL
  • SUBSCRIPTION SYSTEM
  • TELEGRAM BOT
  • PAYMENT FLOW
  • OPERATIONS AUTOMATION
NEXT SIGNAL

Do you have a similar challenge?

If your project sits between web, operations, content, and automation, we can first clarify the problem and the shortest path to build it.

Start a conversation on Telegram