Feature Requests

When uploading photos the photos don't always show up in chronological order. Can we have the system default to using the metadata timestamp to orgnaize the photos in the order the photos were taken in. But also have the ability to sort and to re-organize inside the folder.

occasionally i will send a prompt i didn't mean to either with incorrect information or for whatever reason. i have to wait for brelly to stop processing to resolve that situation. having the ability to stop brelly processing a response to a prompt that isn't needed or wanted would be a great help

Icontents has a program where you can upload photos with noted descriptions, age and condition and it will look the item up and match it, or give some to choose from and then price it and put it in an excell spreadsheet or you can print it in a PDF format as well. Can brelly do that, or would you be interested in adding that feature? It also allows you to just upload a list of data and it seaches for matches and gives it a price. this is for Contents salvageable and non salvageable item.

When uploading to a claim file or to the library I'd like the ability to drag and drop an entire folder.

I’d like to request that the thread list display the date of the most recent activity for each conversation. Right now, it can be difficult to tell which thread is the most current or which one to return to, especially when several threads have similar names or cover related topics. Showing the date of the latest message or update next to each thread would make it much easier to identify recent conversations and decide which thread to open.

I’d like to request a feature that adds clickable quick-reply buttons when the AI asks a direct question or gives the user a defined set of options. The simplest version would be Yes / No buttons when the AI asks a yes-or-no question. A more expanded version would allow the AI to turn a short list of options into clickable buttons. Instead of requiring the user to type, speak, or copy the answer manually, the user could simply click the appropriate response button at the bottom of the AI message. Ideally, these buttons would appear near the existing message actions, such as thumbs up, thumbs down, copy, etc. The buttons could be shown only when the AI is clearly asking for a specific response or presenting a limited list of choices. This would make the interaction much faster and more efficient, especially when using the AI repeatedly throughout the day. It would also reduce unnecessary typing, prevent misunderstood responses, and make the AI feel more like an interactive workflow tool instead of only a chat window. The attached images show two example use cases: The light-mode screenshot shows a situation where the AI presents three specific options. Each option could become its own clickable button at the bottom of the message. The dark-mode screenshot shows a situation where the AI is effectively asking whether the user wants the AI to proceed. That could be handled with simple buttons such as Yes / No / Not sure. This would be especially useful for confirmations, destructive actions, file choices, search choices, workflow decisions, and any situation where the AI already knows the likely valid responses.

I previously submitted a feature request for the ability to stop Co-Pilot while it is processing a response. I would like to follow that up with a closely related request that complements it and creates a much more efficient workflow. THE REQUEST: Add the ability to edit and regenerate the most recent prompt after it has been submitted. It is common to realize after pressing Enter that a prompt was incomplete, contained incorrect information, was worded poorly, or did not ask what was intended. Other times, the response finishes before the mistake is noticed. In either case, the current workaround is to submit another prompt explaining the correction or start a new conversation. Instead, the user should be able to edit the most recent prompt and resubmit it. EXPECTED BEHAVIOR: If Co-Pilot is still processing: It should immediately cancel the current response, discard any work being performed on the original prompt, and begin processing the edited prompt instead. If Co-Pilot has already completed its response: Editing and resubmitting the prompt should disregard the previous response entirely and generate a brand-new response based only on the edited prompt. IMPORTANT CLARIFICATION: In both cases, the edited prompt should replace the original prompt as though it had been submitted correctly the first time. The original response should not remain part of the conversation or influence the new response. WHY THIS MATTERS: This feature would save time, reduce unnecessary processing and token usage, prevent correction-only follow-up prompts, keep conversation threads cleaner, and create a more forgiving workflow when prompts need to be corrected or refined. FINAL NOTE: This would be a natural companion to the Stop Processing feature request. Together, they would allow users to quickly recover from prompt mistakes without cluttering the conversation or wasting time.

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.