Soroush Neyestani

Software Engineer

Application Architect

Enterprise Application Developer

Technical Author & Educator

Telegram-Based Custom Name Jewelry Ordering Bot

Executive Summary

The project was commissioned by a jewelry store that produced personalized name-based jewelry.

Traditionally, this type of order required the customer to:

  • explain the desired name,
  • discuss possible lettering styles,
  • wait for visual examples,
  • choose one manually,
  • and then continue the purchase through direct communication.

The goal was to convert this into a repeatable digital workflow inside Telegram.

The bot allowed a customer to type a name and immediately receive multiple visual versions of that name using predefined Persian and English decorative/calligraphic styles.

The customer could then select the preferred option by sending the corresponding number.

After payment through card-to-card bank transfer, the selected design was used by the jewelry store as the reference for physical production.

Conceptually:

Customer
   ↓
Telegram Bot
   ↓
Enter Name
   ↓
Generate Multiple Visual Styles
   ↓
Customer Selects Design Number
   ↓
Payment Instructions
   ↓
Order Confirmation
   ↓
Jewelry Production

Business Problem

Custom name jewelry is a highly visual product.

The main challenge is that a customer cannot make a confident purchase decision from plain text alone.

For example, the same name can look very different depending on:

  • Persian calligraphic style,
  • English script style,
  • letter proportions,
  • decorative treatment,
  • overall silhouette.

The jewelry store therefore needed a way to show customers multiple style options before production.


Why Telegram

Telegram was a practical customer interface because users were already comfortable with conversational interaction.

Instead of forcing customers into a traditional e-commerce form, the experience could remain simple:

Type Name
→ Receive Designs
→ Choose Number
→ Pay
→ Order

This reduced the interaction barrier for a product that depended heavily on visual selection.


Core User Journey

The customer flow was designed to be minimal.

Step 1 — Start Bot

The user opened the Telegram bot.


Step 2 — Enter Name

The user entered the desired name.

Examples:

Sara
سارا
Niloofar
نیلوفر

Step 3 — Generate Visual Variants

The system generated visual previews of the entered name using six predefined style options.

The styles covered Persian and English decorative/calligraphic presentation.

The exact historical font/style names should only be listed where source material is available.

Conceptually:

Input Name
   ↓
Style 1
Style 2
Style 3
Style 4
Style 5
Style 6
   ↓
Rendered Images

Dynamic Image Generation

The important technical point is that the bot did not simply return six static images.

The images were generated dynamically based on the customer-entered name.

Conceptually:

Customer Text
   ↓
Text Rendering Engine
   ↓
Style Template
   ↓
Image Output

The same system could therefore generate previews for any supported name.


Personalized Rendering

The system transformed plain user input into a visual product preview.

This is a form of mass personalization.

The structure remained fixed:

Six Styles

while the content changed:

Customer Name

This is the same architectural principle used in many personalized-generation systems:

Static Template
+
Dynamic User Data
=
Personalized Output

Persian & English Support

The project supported both Persian and English names.

This introduced additional rendering considerations because:

  • Persian uses right-to-left script,
  • English uses left-to-right script,
  • character joining differs,
  • typography behaves differently,
  • decorative fonts can have different bounding-box behavior.

A robust renderer therefore needs to account for:

Direction
Glyph Joining
Font Metrics
Canvas Size
Alignment

The historical implementation details should be documented from source if needed.


Calligraphic Presentation

The requested output was not intended to look like normal office typography.

The purpose was to present names in visually attractive styles suitable for jewelry production.

Therefore the system emphasized:

  • decorative lettering,
  • calligraphic appearance,
  • visual balance,
  • production suitability,
  • clear differentiation between style choices.

Why Multiple Styles Were Necessary

For personalized jewelry, style preference is subjective.

A single generated preview would force the customer into a yes/no decision.

Providing six options changed the decision model to:

Which design do you prefer?

rather than:

Do you like this design?

That improves conversion and reduces manual back-and-forth.


Option Numbering

Each generated style was associated with a number.

Example:

1
2
3
4
5
6

The customer could simply respond with the desired number.

This is an effective conversational UX pattern because it avoids:

  • free-text ambiguity,
  • spelling mistakes,
  • long menu commands.

Selection Workflow

Conceptually:

Bot:
Here are your designs:

[1] Preview
[2] Preview
[3] Preview
[4] Preview
[5] Preview
[6] Preview

Customer:
3

The system could then treat:

Selected Style = 3

as a structured order attribute.


Order Data

A personalized order could conceptually contain:

Customer
Name
Language
Selected Style
Selected Preview
Order Status
Payment Status
Production Status

The exact persisted fields depend on the original implementation.


Manual Payment Model

Payment was completed through a manual card-to-card bank transfer.

This is an important distinction.

The project should not be described as having an online payment gateway unless one existed separately.

The accurate workflow is:

Design Selected
   ↓
Payment Instructions
   ↓
Customer Transfers Payment
   ↓
Payment Verification
   ↓
Production

Why Manual Payment Was Acceptable

For a small custom-production jewelry workflow, payment automation was not necessarily the central requirement.

The business value was primarily in:

  • automating visual design presentation,
  • reducing repetitive customer communication,
  • standardizing style selection,
  • simplifying order intake.

Payment remained operationally manual.


Order Handoff to Jewelry Production

After the customer selected a style and payment was confirmed, the selected design became the production reference.

Conceptually:

Customer Name
+
Selected Style
+
Generated Preview
=
Production Reference

The jewelry store then manufactured the physical name piece according to that design.


Digital-to-Physical Workflow

This project is interesting because it connected a digital conversational system to physical production.

The lifecycle was:

Digital Input
   ↓
Generated Design
   ↓
Customer Selection
   ↓
Commercial Order
   ↓
Physical Manufacturing

This makes the project more than a simple Telegram bot.

It was effectively a lightweight product configurator.


Product Configurator Perspective

A product configurator lets customers customize a product before ordering.

In this case the configurable variables were:

Name
+
Writing Style

The output was:

Personalized Jewelry Design

That makes the project comparable in principle to:

  • custom engraving tools,
  • personalized gift configurators,
  • monogram generators,
  • custom typography products.

Conversational Commerce

The project can also be categorized as a conversational commerce solution.

Instead of a traditional website flow:

Product Page
→ Form
→ Cart
→ Checkout

the customer experience happened through conversation:

Message
→ Preview
→ Select
→ Pay
→ Order

Technical Architecture

At a high level:

Telegram User
      ↓
Telegram Bot
      ↓
Conversation Handler
      ↓
Name Input
      ↓
Image Rendering Service
      ↓
Six Style Outputs
      ↓
Selection Handler
      ↓
Order Record
      ↓
Payment Instructions
      ↓
Manual Verification
      ↓
Jewelry Production

Main Components

The system can be logically separated into:

Bot Interface
Rendering Engine
Style Library
Order Workflow
Payment State
Production Handoff

1. Bot Interface

Responsible for:

  • starting conversations,
  • asking for names,
  • sending generated previews,
  • receiving numeric selections,
  • displaying payment instructions.

2. Rendering Engine

Responsible for:

  • receiving the input name,
  • selecting the appropriate font/style,
  • rendering the text,
  • sizing and aligning the result,
  • exporting image previews.

3. Style Library

The six available designs formed a small style catalog.

Conceptually:

Style 1
Style 2
Style 3
Style 4
Style 5
Style 6

Each style had:

  • typography,
  • visual characteristics,
  • rendering configuration.

4. Order Workflow

Responsible for tracking where the customer was in the process.

Possible states:

WAITING_FOR_NAME
GENERATING_PREVIEWS
WAITING_FOR_SELECTION
WAITING_FOR_PAYMENT
PAYMENT_CONFIRMED
READY_FOR_PRODUCTION
COMPLETED

These are a clean conceptual state model; exact historical states should be verified from source if needed.


5. Payment State

Because payment was manual, the system only needed to model the business status.

For example:

Pending
Paid
Rejected

The actual bank transfer happened outside the bot.


6. Production Handoff

The selected preview needed to be clearly associated with the order.

This prevented ambiguity during production.

A good order record should preserve:

Exact Name
Exact Selected Style
Exact Generated Preview

so the physical product matches the approved visual.


Image Rendering Challenges

Dynamic text-to-image generation has several practical challenges.

Variable Length

Names can be short or long.

Example:

Ali
Alexandra
عبدالرحمن

The rendering system needs to adapt.


Canvas Sizing

A fixed image width can produce:

  • clipping,
  • excessive empty space,
  • inconsistent centering.

A better renderer calculates dimensions from text metrics.

Conceptually:

Measure Text
   ↓
Calculate Canvas
   ↓
Render Centered

Font Metrics

Decorative fonts often have unusual:

  • ascenders,
  • descenders,
  • kerning,
  • glyph overlap.

Bounding boxes therefore matter.


Right-to-Left Rendering

Persian rendering requires:

RTL Direction
+
Correct Character Shaping
+
Font Support

If the rendering library does not correctly shape Persian text, individual letters may appear disconnected.


Output Quality

Because the preview influenced a physical jewelry order, generated images needed to be clear enough for:

  • customer decision-making,
  • store interpretation,
  • production reference.

UX Simplicity

One of the strongest aspects of the project is that the technical process remained invisible to the customer.

The customer only experienced:

Send Name
↓
See Designs
↓
Send Number

This is good product design.


Reduction of Manual Work

Without the bot, staff might need to:

  • receive each name,
  • open a design tool,
  • type it in several fonts,
  • export previews,
  • send them manually,
  • wait for a reply,
  • identify the selected style.

The bot automated the repetitive part.


Before Automation

Customer sends name
↓
Employee creates 6 previews manually
↓
Employee sends images
↓
Customer replies
↓
Employee records selection

After Automation

Customer sends name
↓
Bot generates 6 previews
↓
Customer sends selection number
↓
Order is recorded

This significantly reduces operational friction.


Standardization

The bot also standardized how options were presented.

Every customer saw the same structured process.

This reduces differences between employees and prevents inconsistent sales handling.


Business Value

The system created value in several ways:

Faster Response

Customers could receive previews immediately or much faster than manual preparation.

Reduced Labor

Employees no longer needed to generate the same six visual options manually for every customer.

Fewer Errors

The selected design could be stored directly with the order.

Better Customer Experience

Customers could compare styles visually before purchasing.

Scalability

The store could handle more personalized requests without increasing manual design effort at the same rate.


Portfolio Positioning

This project demonstrates experience in:

  • Telegram bots,
  • conversational workflows,
  • dynamic image generation,
  • multilingual text rendering,
  • Persian RTL handling,
  • product customization,
  • order-state management,
  • mass personalization,
  • digital-to-physical commerce workflows.

Strong Portfolio Description

I developed a Telegram-based ordering bot for a jewelry store that generated personalized name previews in six Persian and English calligraphic styles. Customers entered a name, received automatically generated visual options, selected a preferred design by number, completed payment via bank transfer, and the selected preview was then used as the production reference for manufacturing the custom jewelry piece.


Short Website Version

Telegram Custom Name Jewelry Bot

Developed a Telegram-based personalized ordering workflow for a jewelry store. Customers entered a name and received six automatically generated Persian and English calligraphic previews. They selected the preferred design by number, completed payment through a manual bank transfer, and the chosen preview became the reference for physical jewelry production.


Technical Website Version

Built a Telegram product-configurator bot that transformed user-entered names into dynamically rendered image previews across six predefined Persian and English calligraphic styles. The bot managed the conversational ordering state, captured the selected design, provided payment instructions, and preserved the chosen preview as the manufacturing reference for the jewelry store.


CV Version

Telegram Personalized Jewelry Ordering Bot

Developed a Telegram bot for custom name jewelry ordering, including dynamic Persian/English text-to-image rendering across six calligraphic styles, numeric design selection, order-state management, and production handoff.


Technical CV Version

Telegram Bot · Dynamic Image Rendering · Personalized Product Workflow

Implemented a conversational product configurator that rendered customer-entered names into six predefined visual styles, handled design selection through Telegram, and converted the selected preview into a structured jewelry production order.


Interview Story

Situation

A jewelry store sold custom name-based jewelry and needed to repeatedly show customers different lettering options before manufacturing each order.

Task

The store wanted to automate the preview and selection process using Telegram.

Action

I developed a Telegram bot where the customer entered a name.

The system rendered that name dynamically in six predefined Persian and English calligraphic styles and returned the previews.

The customer selected a design by sending its number.

The bot then moved the order into the payment stage.

Payment itself remained a manual card-to-card bank transfer.

After confirmation, the selected preview became the manufacturing reference.

Result

The jewelry store no longer needed to manually prepare multiple visual previews for every customer, and the ordering process became faster, more consistent, and easier to scale.


Architecture-Oriented Interview Answer

“I treated the bot as a small state machine. The user moved from name input to generated previews, then to design selection, payment pending, and production. The rendering layer was kept separate from the conversational logic, so the same input name could be passed through six different typography configurations and returned as image options.”


Personalization-Oriented Interview Answer

“The reusable part was the style catalog; the variable part was the customer’s name. That made the problem a mass-personalization workflow rather than a static chatbot.”


Digital-to-Physical Product Flow

This project is a strong example of connecting software to a real-world manufacturing process.

TEXT INPUT
    ↓
DIGITAL RENDERING
    ↓
CUSTOMER APPROVAL
    ↓
PAYMENT
    ↓
PHYSICAL JEWELRY PRODUCTION

Modern V2 Architecture

A modern rebuild could use:

Telegram Bot
   ↓
Application Service
   ↓
Rendering Service
   ↓
Order Service
   ↓
Database
   ↓
Admin Dashboard

Modern V2 — Rendering Service

The renderer should expose something like:

render(name, style)

and return:

Preview Image

This keeps rendering independent from Telegram.


Modern V2 — Style Configuration

Instead of hardcoding six styles, define them as data:

Style
├── ID
├── Name
├── Font
├── Direction
├── Size
├── Alignment
├── Padding
└── Output Settings

This makes styles configurable.


Modern V2 — Order Aggregate

Conceptually:

Order
├── Customer
├── Name
├── Language
├── Selected Style
├── Preview File
├── Payment Status
├── Production Status
└── Timestamps

Modern V2 — Admin Panel

A jewelry store dashboard could show:

New Orders
Waiting for Payment
Paid
In Production
Ready
Delivered

This would turn the bot into a complete lightweight order-management system.


Modern V2 — Online Payment

If desired, the manual bank transfer step could be replaced by:

Payment Gateway

with automatic status confirmation.

That was not part of the original workflow.


Modern V2 — Preview Approval

A useful enhancement would be an explicit:

Approve Design

step.

This creates a clear production authorization record.


Modern V2 — Order ID

Each request should have a unique order ID.

This simplifies:

  • payment matching,
  • production tracking,
  • support,
  • delivery.

Modern V2 — File Preservation

The exact approved preview should be archived with the order.

This provides traceability if the customer later disputes the produced design.


Modern V2 — Security

Important considerations include:

  • validating Telegram user identity,
  • rate limiting,
  • limiting arbitrary file generation,
  • validating text length,
  • preventing malicious input,
  • secure storage of order details.

Modern V2 — Rendering Queue

If many users request images simultaneously, rendering can be moved to a queue:

User Request
   ↓
Queue
   ↓
Render Six Styles
   ↓
Send Results

Modern V2 — Cache

Repeated names could optionally reuse generated previews if:

same name
+
same style version

produce identical output.

This can reduce processing.


Modern V2 — Versioned Styles

A style should have a version.

If the jewelry store changes a font or layout later:

Style 3 v1
Style 3 v2

existing orders still preserve the original approved design.


Modern V2 — Multilingual Expansion

The same architecture could support additional scripts if suitable fonts and shaping engines are available.

For example:

Arabic
Latin
Persian

The historical system should only be described as supporting the languages actually implemented.


What This Project Was Not

It was not:

  • an automated jewelry manufacturing machine,
  • an online banking/payment platform,
  • an AI image-generation system,
  • a generic Telegram chatbot.

Its core value was the combination of:

Personalized Text Rendering
+
Conversational Product Selection
+
Order Workflow
+
Physical Production Handoff

Main Engineering Insight

The central insight was:

If the product is personalized but the customization rules are finite, generate the preview automatically instead of designing every order manually.

That turned a repetitive human design step into a reusable system.


Final Portfolio Statement

The project transformed a manual custom-jewelry sales workflow into a lightweight conversational product configurator.

Customers could enter their name directly in Telegram, receive six automatically generated Persian and English calligraphic previews, select the preferred option numerically, complete payment, and have the selected visual passed to the jewelry store as the production reference.

The architecture separated:

Customer Interaction
+
Dynamic Rendering
+
Design Selection
+
Order State
+
Production Handoff

which made the process significantly more consistent and scalable than manually preparing previews for every customer.


Final One-Line Summary

Built a Telegram-based personalized jewelry configurator that dynamically rendered customer names in six calligraphic styles and converted the selected visual into a production-ready custom order.