Feature Requests

THE REQUEST: Add the ability to upload an existing PDF and use it as the foundation for a Brelly Docs template. The goal is to take an existing contract, authorization, inspection form, report, or any other professionally formatted PDF and convert it into a reusable Brelly Docs template by placing configurable fillable fields on top of the document. CURRENT ISSUE: Brelly Docs allows documents to be created, but I do not see a way to upload an existing PDF and build fillable fields on top of it. Many companies already have professionally designed documents with company branding, logos, legal language, formatting, spacing, and layouts that they do not want to recreate from scratch. EXPECTED BEHAVIOR: A user should be able to upload a PDF into Brelly Docs and then place configurable field blocks anywhere on the document where information needs to be inserted. Each field should allow configuration such as: Field name or token name. Position on the page. Width and height. Font family. Font size. Font style. Text alignment. Underline or other basic formatting. Required or optional status. Auto-filled or manually entered values. CLAIM DATA TOKENS: Where information already exists within the claim, the user should simply be able to select that field from a list and place it on the PDF. Examples include: Policyholder first name Policyholder last name Loss address Claim number Policy number Insurance company Date of loss Email address Phone number Contractor or company name Estimate amount Deductible Mortgage company Any other claim information already stored in Brelly This could function as a token selector or drag-and-drop field library similar to other document automation platforms. CUSTOM FIELDS: Not every document contains information that already exists within the claim. For those situations, users should be able to create custom fields that are completed manually when generating the document. Examples include: Custom dollar amounts Special instructions Scope descriptions Payment terms One-time notes Any other document-specific information SUGGESTED WORKFLOW: Upload an existing PDF. Choose "Create Template." Place fillable field blocks where information belongs. Assign each field to either a Brelly claim data token or a custom manual-entry field. Save the completed layout as a reusable template. Generate future documents using automatically populated claim data along with any required manual inputs. Export the completed document as a PDF. WHY THIS MATTERS: Many businesses already have documents that are exactly the way they want them, including branding, formatting, legal language, and spacing. Recreating those documents inside Brelly Docs is unnecessary and may never perfectly match the original. Allowing users to upload an existing PDF and simply place intelligent fillable fields on top of it would make Brelly Docs dramatically more powerful while requiring very little redesign of existing company documents. This would be valuable for: Contracts Work authorizations Direction-to-Pay forms Certificates of completion Inspection forms Claim intake forms Customer agreements Internal company forms Any recurring document containing variable claim information FINAL NOTE: The closest comparison would be a PDF form designer such as those found in document automation platforms. The uploaded PDF remains the visual foundation of the document. The user simply overlays configurable fields that either pull data directly from the claim or are completed manually when generating the document. This would allow companies to convert their existing documents into intelligent, reusable Brelly Docs templates without rebuilding them from scratch.

One feature I think would add significant value to Brelly is a Shared Conversation area that allows invited collaborators (such as the contractor and policyholder) to communicate directly within the claim. Today, each user has their own private Co-Pilot conversations, which is exactly how it should be. However, there is currently no way for collaborators to communicate inside Brelly, forcing them to switch to email, text messages, or phone calls. This fragments the workflow and moves important claim-related communication outside the platform. Rather than implementing a live chat system, I envision something much simpler: an asynchronous conversation thread attached to the claim. (1) Suggested Features: • Dedicated Shared Conversation tab. • Available only to invited collaborators on that claim. • Threaded conversations. • Searchable message history. (2) Communication and Notifications- A major purpose of Shared Conversation would be to prevent important claim communication from being delayed, missed, or buried in outside communication channels. For this feature to be successful, notifications should be considered a core part of the design rather than just an added feature. Whenever a new message is posted, the other collaborator should receive a notification through available methods such as email, in-app notifications, and mobile push notifications. The goal is not to create a real-time chat application, but rather a reliable asynchronous communication tool that keeps the claim moving without requiring users to constantly check Brelly for new messages. (3)Separation from Co-Pilot- I believe the most important design principle is that Shared Conversation should be completely independent from Co-Pilot. Messages exchanged in this area should: • Never become part of claim memory. • Never be analyzed by Co-Pilot. • Never influence AI responses. • Never appear as context in any user's Co-Pilot conversations. To make this clear, I would recommend displaying a notice such as: "Shared Conversation is for communication only. Messages exchanged here are not analyzed by Co-Pilot, are not added to claim memory, and do not influence AI responses." This creates a clear separation between human communication and AI assistance, giving users confidence that their conversations remain private between collaborators and are not incorporated into the AI's understanding of the claim. (4) Handling Files and Photos- Although the conversation itself should remain separate from claim memory, uploaded files should not. If a user uploads a photo, document, estimate, or any other attachment through Shared Conversation, Brelly should automatically add that file to the claim's Files section exactly as if it had been uploaded there directly. The message itself remains only a communication between collaborators, while the uploaded file becomes part of the official claim record and is available throughout Brelly for claim management, document organization, and Co-Pilot analysis. This creates a clean distinction: • Conversation = Communication between people. • Files = Official claim evidence and documentation. (5) Why This Matters- This approach keeps communication and claim evidence separate while allowing each to serve its intended purpose. It would: • Keep all claim-related communication inside Brelly instead of relying on scattered emails and text messages. • Reduce delays through timely notifications. • Allow homeowners and contractors to collaborate without leaving the platform. • Preserve a clear distinction between AI interactions and human conversations. • Avoid legal and compliance concerns by ensuring conversations are not analyzed or retained as AI memory. • Ensure that any uploaded evidence immediately becomes part of the official claim record without requiring duplicate uploads. I believe this provides users with a simple and intuitive mental model: • Co-Pilot = Talk to AI. • Shared Conversation = Talk to people. • Files = The official claim record and evidence. Each serves a distinct purpose, eliminating ambiguity while creating a much more seamless collaboration experience.