CASE SUMMARY

The system does not predict stocks. It turns time-sensitive signals, member permissions and notification workflows into a consistent, traceable operating service.

The client previously opened TradingView charts one by one, checked a proprietary indicator, organised signals by sector and answered members. As coverage and membership grew, intraday, lunch break, close, overnight and duplicate signals became difficult to handle consistently.

The project moved to native alerts and webhooks for structured events, then used the same state for Telegram queries, membership tiers, personal watchlists, usage analysis and issue reporting.

Manual chart checking works at small scale, but not for signal freshness and growing member queries.

Staff recorded signal colours and levels, decided whether a signal had expired or been replaced, compared current prices with risk levels and answered single-stock or multi-stock questions. The same data was checked repeatedly.

The project first tested browser automation and visual recognition, but login state, page updates, loading speed and image interpretation affected reliability. Native TradingView events allowed direct storage of time, price and source.

Every webhook is stored as an event before market sessions, validity and later signals determine the current state.

The system normalises Hong Kong leading zeros, US symbols and message formats while retaining raw input. During trading hours, recent events determine whether a signal remains active; lunch, close and overnight periods use session-specific retention rules.

Same-colour continuation, signal changes, historical finalisation and duplicate webhooks have explicit rules. Changes are replayed against history, then validated in staging and shadow mode before affecting live results.

Telegram queries, membership tiers and watchlists share one permission model and current state.

When a member enters one or more symbols, the system reads the latest signal, sector data, price and restrictions before returning a structured response. Missing data is stated rather than replaced with an inferred event.

Standard members do not see restricted functions, and manually entered commands are still rechecked by the server. Eligible members can save personal watchlists, with a baseline created on activation to prevent a flood of old alerts.

Telegram asks for acknowledgement first, with unconfirmed events considered for a restricted phone escalation.

When a new, complete watchlist signal appears, the workflow sends a message with an acknowledgement button. Only an unconfirmed event is considered for phone escalation, and connection, busy, failure, cancellation, unknown result, acknowledgement or disabled monitoring stops further attempts.

The phone flow has been designed, integrated and validated under control, but real calls remain behind safety gates, an emergency stop, quotas and shadow checks. It is not presented as generally available to all members.

The system provides operating automation and decision support. It does not place trades.

The case does not measure investment returns, win rates or predictive accuracy. Outputs remain educational and are not investment advice.

Live functions, safety-gated functions and shadow validation are stated separately.

01

In live use

Webhook signal processing, Telegram single and multi-stock queries, member permissions, admin analysis and issue reports.

02

Connected with safety gates

Personal watchlist pages, list storage, new-signal evaluation and acknowledgement flow.

03

Shadow or controlled validation

General member monitoring, live calls after non-acknowledgement and production approval for manual signal corrections.

The client estimated about an 80% improvement across monitoring, organisation, responses and exception investigation.

The client's internal estimate is roughly 60 staff hours saved each month. Members can retrieve consistently formatted results, while administrators manage members, usage trends and issue reports in one interface.

The 60-hour and 80% figures should be checked against at least one full month of before-and-after records. They describe operating efficiency only and do not indicate investment performance.

RELATED SERVICE

Member, notification and operations automation

View the full page ↗
MONITORING

Use safety gates, alerts and manual fallback to reduce risk

View the full page ↗
PHASED DELIVERY

The project path from testing and acceptance to launch

View the full page ↗

Frequently asked questions

Does the system trade automatically?

No. It receives and organises the client's own indicator events for member queries and alerts. It does not place orders.

Are phone alerts fully launched?

No. The flow has been integrated and validated under control, but live calls remain restricted by safety gates, quotas and shadow checks.

How does a new watchlist avoid sending old alerts?

Activation records existing signals as a baseline. Only new, complete and valid events can then create an alert.

EXPERT AUTOMATION CONSULTATION

Does your team have a repetitive, error-prone workflow?

Tell us how the process works today, its monthly volume and the common exceptions. We will identify the part worth automating and define a testable first phase.