Skip to main content
Version: ChatLead

Dynamic Forms-in-Chat Feature


Group Billing

Author(s)

  • Alapan Das
  • ...

Last Updated Date

[2025-09-23]


SRS References


Version History

VersionDateChangesAuthor
1.02025-09-23Initial draftAlapan Das
............

Overview

The Dynamic Forms-in-Chat Feature enables the Bot to serve dynamic forms in chat for individual subscribers and product types via an automated tool. This tool provides the most accurate form id based on the user query extracted from a sliding context window, based on user context and intent, bot dynamically decides which form is to be opened, improving user engagement and lead collection effectiveness.

Legend

  • BotProxyService BPS
  • BotWorker BW

Workflow

  • Backend provides available form details through an API.

  • BotProxyService (BPS) fetches the API response, transforms it into a custom format, and stores it in Redis under subId:forms.

  • Botworker (BW) starts a chat session and retrieves the subscriber’s cached forms from Redis.

  • Form Decision Tool (BW) analyzes the user query and returns a boolean indicating if a form should be triggered.

  • Form Calling Tool (BW) matches the query against cached forms using semantic similarity and identifies the correct form ID.

  • Botworker (BW) sends the matched form ID to BPS.

  • BPS retrieves full form details from Redis using the form ID.

  • BPS pushes the complete form payload to the Backend via SignalR.

  • Backend renders and displays the appropriate form to the User without interrupting the chat flow.

Advantages

Seamless user experience

  • forms are triggered inside the chat flow without breaking the conversation.

Faster response times

  • cached forms in Redis reduce backend calls and improve performance.

###Personalized interactions

  • user queries are matched to the most relevant forms (e.g., test drive, service booking).

Operational efficiency

  • standardized tools (decision + calling) simplify handling multiple form types across subscribers.

Scalability

  • modular design with Redis and SignalR supports high traffic and multiple subscribers simultaneously.
NoStory NameEstimate (Hours)Notes
1Form Data Handling (BTS)10 hoursFetch API → transform data → cache in Redis under subId:forms.
2Chat Initialization (BW)8 hoursLoad cached forms at chat start and keep in memory for quick lookups.
3Form Decision Tool (BW)8 hoursDetect queries needing a form trigger, return boolean.
4Form Calling Tool (Data Processing)8 hoursMatch user query to correct form ID using semantic similarity.
5Form Calling Tool (logic+implementation)14 hoursMatch user query to correct form ID using semantic similarity.
6Form Dispatch (BTS + BW)6 hoursSend form ID → fetch full details from Redis → push to backend via SignalR.
7Testing and Validation5 hoursHandle cache misses, no matches, and ensure chat remains non-blocking.
8Buffer1 hourHandle cache misses, no matches, and ensure chat remains non-blocking.
9Total60 hoursSum of all above estimates.

Implementation Notes

  • Ensure proper validation and security for the update endpoint.
  • Support multi-line prompts and special characters.
  • Log changes for audit and troubleshooting purposes.