> ## Documentation Index > Fetch the complete documentation index at: https://docs.replit.com/llms.txt > Use this file to discover all available pages before exploring further. # Turn customer feedback into working improvements > Turn customer feedback into a focused repository change with Replit, test the improvement in a development preview, and prepare a pull request for team review. Customers keep missing a required field in your signup form. Instead of stopping at a support ticket or feature request, work with Replit to understand the current behavior, propose a focused improvement, and try it in a development preview. When the result is ready, prepare a pull request for your team to review. The same workflow can help with an unclear error message, a broken help link, or a larger improvement that needs your expertise. Start with one problem and a clear way to check whether the change addresses it. ## Best for * Support specialists who want to turn a recurring customer issue into a proposed fix. * Product managers who want to evaluate an improvement against the existing implementation. * Designers and engineers who want to iterate on a real workflow before submitting changes for review. ## Connectors You can use GitLab instead of GitHub. A support connector is optional: you can start with a sanitized summary of the feedback, or point Replit to a source you have connected and are authorized to read. ## Before you start You need access to repository-based development in your workspace and permission to read the repository. Opening a pull request also requires permission to push a branch or use your team's approved fork workflow. Choose a specific issue and identify the repository that implements the affected experience. Remove personal customer information from examples. Use test data and development credentials when trying the app, not real customer accounts. For connection instructions, see [Connect your repository](https://docs.replit.com/build/code/connect-your-repository.md). ## Prompt Replit Customers report that they cannot tell which required signup field they missed. Review \[feedback source or sanitized summary] and inspect the signup flow in \[repository URL]. Explain the current behavior and propose a focused improvement using our existing form components. Keep validation rules unchanged. Ask me to confirm the approach before editing, then show me a development preview and relevant test results. Do not commit, push, or open a pull request until I ask. ## What to expect ```mermaid theme={null} flowchart LR A["Customer feedback"] --> B["Understand the existing code"] B --> C["Agree on a focused change"] C --> D["Preview and verify"] D --> E["Propose it for team review"] ``` **1. Understand the problem** Replit reads the feedback you provide or authorize it to retrieve, then examines the relevant implementation. Review whether the proposed explanation matches the customer problem. A few reports are not proof that every customer is affected, and source code alone does not establish production behavior. **2. Agree on the improvement** Decide what should change and what must stay the same. For this example, the goal is clearer required-field errors, not new signup requirements. Ask Replit to reuse existing components and keep unrelated changes separate. **3. Try the change in a preview** Replit prepares a development setup, makes the agreed change, and starts the app where the setup supports it. Open the preview, submit the form with a required field empty, then correct it. Give specific feedback about the error message, layout, and interaction. If setup needs credentials, enter limited development credentials through the secure secrets flow. If you approve a mock service, keep that limitation explicit rather than treating it as a test of the real integration. **4. Check the result** Ask Replit to run relevant checks and report passed, failed, and blocked tests. Inspect the diff and confirm that existing validation behavior remains intact. Include keyboard navigation and narrow-screen behavior where relevant. Screenshots can help explain a visual change, but do not replace tests or review. **5. Prepare the pull request** Once you are satisfied with the result and understand its limitations, ask: Open a draft pull request for this improvement. Follow the repository's contribution guidelines. Describe the customer problem without including private customer details, explain the change, and include relevant test results and visual evidence. Clearly state anything we could not verify. For GitLab, ask for a draft merge request. Your team reviews the proposed change through its existing process. Opening the request does not merge or deploy it. You end up with a focused contribution that connects the customer problem to an implementation and its verification evidence. Confirm that the change has actually been released before telling customers the issue is fixed. ## Make it work for you Check whether an open issue or pull request already addresses this feedback before we start. If it does, summarize that work and suggest how I can contribute without duplicating it. The feedback is about a typo in the signup confirmation, not the signup logic. Correct only that text, preserve the existing styling, and show me the result. This improvement needs a business rule confirmed by our product specialist. List the unresolved decisions before implementing anything. Keep confirmed behavior separate from assumptions. ## Troubleshooting > **The feedback is too vague to reproduce** > > Ask for the affected step, expected behavior, and observed behavior. Use > sanitized examples. Have Replit separate possible explanations from findings > supported by the code and development tests. > **The preview cannot run** > > Ask Replit to inspect the repository's setup instructions and identify the > missing dependencies, services, or permissions. Report the blocker in the > handoff rather than claiming the behavior was tested. > **The proposed fix is becoming too large** > > Return to the original problem and ask for the smallest useful change. > Separate broader redesigns or new requirements into follow-up work. > **The reviewer requests changes** > > Ask Replit to assess the feedback and update the existing open request where > appropriate. Recheck the affected behavior after corrections. If the request > has already merged, handle further work as a new contribution. ## Related > **[Analyze customer feedback](https://docs.replit.com/use-cases/analyze-customer-feedback.md)** > > Identify recurring themes before choosing an improvement to work on. > **[Code with Replit](https://docs.replit.com/build/code/code-with-replit.md)** > > Understand repository-based development and get started with your team.