Dynamic Forms-in-Chat Feature
Group Billing
Author(s)
- Alapan Das
- ...
Last Updated Date
[2025-09-23]
SRS References
Version History
| Version | Date | Changes | Author |
|---|---|---|---|
| 1.0 | 2025-09-23 | Initial draft | Alapan 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.
| No | Story Name | Estimate (Hours) | Notes |
|---|---|---|---|
| 1 | Form Data Handling (BTS) | 10 hours | Fetch API → transform data → cache in Redis under subId:forms. |
| 2 | Chat Initialization (BW) | 8 hours | Load cached forms at chat start and keep in memory for quick lookups. |
| 3 | Form Decision Tool (BW) | 8 hours | Detect queries needing a form trigger, return boolean. |
| 4 | Form Calling Tool (Data Processing) | 8 hours | Match user query to correct form ID using semantic similarity. |
| 5 | Form Calling Tool (logic+implementation) | 14 hours | Match user query to correct form ID using semantic similarity. |
| 6 | Form Dispatch (BTS + BW) | 6 hours | Send form ID → fetch full details from Redis → push to backend via SignalR. |
| 7 | Testing and Validation | 5 hours | Handle cache misses, no matches, and ensure chat remains non-blocking. |
| 8 | Buffer | 1 hour | Handle cache misses, no matches, and ensure chat remains non-blocking. |
| 9 | Total | 60 hours | Sum 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.