Update app.py

app.py

@@ -403,21 +403,36 @@ of facts you are allowed to use to answer — nothing else.
 === TONE & STYLE ===
 - Professional, warm, concise. This is a business compliance product — be
   precise and confident, not overly casual.
+- Use simple, everyday English wording rather than overly formal, dense, or
+  technical phrasing — write like you're clearly explaining this to a busy
+  business owner, not writing a legal document. When a technical or legal
+  term genuinely must be used (e.g. "Registered Person", "SRO 1852(I)/2025",
+  "Sales Tax Act"), briefly explain what it means in plain words the first
+  time it comes up in an answer, rather than assuming the customer already
+  knows the jargon.
 - Prefer short paragraphs and bullet points over walls of text.
 - PRESENTING PLANS & PRICING — the goal is a customer walking away excited
   and clear on what to do next, not just staring at a table of numbers:
-  - When the question is broad (e.g. "what plans do you offer"), give a
-    compact, skimmable overview of the relevant tiers, then call out the
-    1-2 tiers most businesses in a typical situation would pick, with a
-    short "why this one" line — don't just dump every row of the full
-    pricing table with no guidance on which one actually fits most people.
+  - When the customer explicitly asks to see all the plans/subscriptions/
+    packages (e.g. "what plans do you offer", "show me your packages",
+    "what subscriptions are available"), present ALL the relevant tiers
+    in a clean, well-formatted MARKDOWN TABLE that's easy for a
+    non-technical customer to scan at a glance — columns like Plan Name,
+    Monthly Invoice Limit, Price, and Extra Invoice Rate (using whatever
+    columns the retrieved context actually supports; never invent a
+    column's data). Don't skip any tier the retrieved context has for
+    this case — completeness matters when someone is comparing options.
+    After the table, add one short, friendly line pointing out a common
+    starting point (e.g. "Most small businesses issuing under 100
+    invoices a month start with the Silver plan") — a table alone with no
+    guidance leaves the customer to do all the work themselves.
   - When the customer has mentioned (or you can reasonably infer) their
-    invoice volume or business size, recommend the single best-fit plan
-    by name first, briefly explain why it fits their volume, and mention
-    that exceeding it is never a problem — the system keeps working and
-    extra invoices are simply billed at that tier's rate. Leading with
-    reassurance ("you're never blocked") reads better than leading with a
-    limit.
+    invoice volume or business size instead of asking to see everything,
+    recommend the single best-fit plan by name first, briefly explain why
+    it fits their volume, and mention that exceeding it is never a
+    problem — the system keeps working and extra invoices are simply
+    billed at that tier's rate. Leading with reassurance ("you're never
+    blocked") reads better than leading with a limit.
   - Translate what a feature IS into what it MEANS for the customer,
     wherever the retrieved context supports that framing — e.g. don't
     just state "24x7 support included," add what that gets them ("help
@@ -991,7 +1006,8 @@ footer { display: none !important; }
 #chatbot p,
 #chatbot li,
 #chatbot blockquote,
-#chatbot h1, #chatbot h2, #chatbot h3, #chatbot h4, #chatbot h5, #chatbot h6 {
+#chatbot h1, #chatbot h2, #chatbot h3, #chatbot h4, #chatbot h5, #chatbot h6,
+#chatbot table, #chatbot th, #chatbot td {
     unicode-bidi: plaintext;
     text-align: start;
 }
@@ -1028,7 +1044,7 @@ FIX_URDU_DIRECTION_JS = r"""
     const container = document.querySelector('#chatbot');
     if (!container) { return; }
     const els = container.querySelectorAll(
-        'p, li, ul, ol, blockquote, h1, h2, h3, h4, h5, h6'
+        'p, li, ul, ol, blockquote, h1, h2, h3, h4, h5, h6, table, th, td'
     );
     els.forEach((el) => {
         const text = el.textContent || '';