Python Applications · 2022
LemonBee
Customer Care Management System. My first major Python project, a terminal application for customers, products, orders, support tickets, reports and messaging, built on Pandas and CSV files.
- Role
- Creator and developer
- Period
- 2022 (repository created August)
- Status
- Historical project; current maintenance status not confirmed
- Type
- Independently developed customer-service management application
- Category
- Python Applications
- Technologies
- Python · Pandas · NumPy · Matplotlib · Colorama · CSV · SMTP · Regular Expressions · difflib
Links

LemonBee is a terminal-based customer care management system for e-commerce operations, and my first major Python project. It brings customer records, products, orders, support tickets, reporting, data visualization and customer messaging into one menu-driven application. I keep it as an early engineering milestone, not as an example of my current architecture.
Context and problem#
Support teams manage information spread across customers, products, orders and service requests. Without a central workflow, tracking issues and keeping records consistent gets repetitive. I built LemonBee to see how Python could automate that, and it became my first chance to work with structured data, write an interactive application and connect several business processes in one program.
What it does#
- A custom menu-driven terminal interface, with separate administrator and customer workflows.
- Customer records: insertion, modification, deletion and validation.
- Products (categories, manufacturers, stock, ratings, return policies) and orders linking customers to products, with order status.
- Support tickets with categories, status tracking and customer-service metrics.
- Search, filtering and sorting across datasets.
- Reports over daily, weekly, monthly, yearly and custom periods, with Matplotlib charts.
- Customer messages, message templates, and email for selected communication and account-recovery flows.
- Terminal formatting with Colorama and ASCII-art headings.
Architecture overview#
Engineering challenge: interconnected datasets without a database#
Customers, products, orders, tickets and messages each live in their own CSV file and are loaded into DataFrames. Unique identifiers link the records: orders point to customers and products, and tickets point to customers and orders. Inserting, updating, filtering and deleting are DataFrame operations, and changes are written back to CSV. Because the application keeps these relationships in code, it taught me directly about consistency and persistence.
Engineering challenge: reusable search and filtering#
Instead of writing separate search code for each dataset, I wrote a reusable CustomSearcher class. It finds records by identifier, exact value or string match, filters numeric fields by range and date fields by date range, filters by predefined options, and plugs into the administrator search menus. It runs on in-memory DataFrames. It is not a full-text search engine and has no indexing.
Engineering challenge: support ticket workflows#
A ticket ties together customers, orders and products. Creating one validates that the order belongs to the selected customer. Issues are categorized (damaged product, missing component, incorrect delivery), and the ticket records creation and closure dates, status, description, response information, and satisfaction and response metrics. Customers can create and review their tickets, and administrators can manage them. When an entered category doesn’t match, Python’s difflib suggests similar valid ones.
Engineering challenge: reporting and visualization#
Pandas filtering and aggregation produce ticket reports for daily, weekly, monthly, yearly and custom periods. They cover summary statistics, first-response times, satisfaction values, and issue and product categories, with Matplotlib charts. The metrics are computed from the supplied records. I haven’t independently validated their accuracy, and I make no claim that they improved any support outcome.
Engineering challenge: the terminal interface#
With many features in a command-line program, navigation has to stay understandable. Menu definitions are kept apart from the operations they trigger, menus are hierarchical, and the output is colored with Colorama. Input prompts and error displays are reusable, and potentially destructive actions ask for confirmation.
Engineering challenge: validation and communication#
Shared utilities validate email addresses, phone-number formats, dates and timestamps, numeric input and predefined options, using regular expressions and custom functions. They also detect missing or duplicate identifiers and re-prompt when input is invalid. I wouldn’t call the validation comprehensive or fully tested. Messaging stores message records against tickets, offers template-based and custom messages, lets customers see their history, and uses SMTP for selected email operations including password recovery.
Lessons and evolution#
LemonBee made me move from single scripts to an application with several interacting modules. Working with CSV storage showed me the problems of record relationships, validation, keeping datasets in sync and persistence, and building the terminal interface showed me why navigation should be organized and separated from reusable utilities. Those lessons fed later work with relational databases, graphical interfaces and backend services, such as Pinnacle Dynamo.
I have no verified figures for development dates, code size, users, performance or test coverage.


