Useful technical feedback isolates a reproducible issue with exact steps, system environments, and observed behaviours. Providing structured technical notes directly through the portal allows our Technology department to diagnose, reproduce, and resolve defects without administrative delays.
What to supply with every technical issue
When reporting an anomaly, defect, or unexpected system behaviour during development or staging reviews, every item must contain five specific data points:
1. Exact location: The staging URL, screen name, or specific build identifier where the issue occurs. 2. Steps to reproduce: A sequential numbered list detailing the precise user actions taken from page load to failure point. For example: "Log in, click billing tab, select quarterly cycle, press save." 3. Observed versus expected behaviour: A plain statement describing what actually occurred (such as a 500 error page or an unformatted modal) contrasted with what the agreed specification stated should occur. 4. System and environment details: Operating system (e.g. macOS Sonoma 14.4), browser and version (e.g. Chrome 124.0), viewport resolution, and whether the issue occurred on desktop, tablet, or mobile. 5. Evidence: Full-screen screenshots, brief screen recordings, or exported browser developer console logs showing network errors or failed JavaScript executions.
General statements such as "the form is broken" or "the page will not load" cannot be resolved without multiple clarification cycles that consume project time.
The technical review workflow
Technical feedback must be submitted consolidated into a single structured batch per milestone or review cycle via the Ask Xylo chat on this portal. This creates a clean operational log that prevents contradictory requirements.
Once logged, work follows a defined route:
- Triage: Operations & Client Services log the ticket, verify the completeness of the report, and assign it to the Technology department.
- Acknowledgment: Our initial reply target is within 24 hours during standard studio hours (Monday to Thursday, 09:00 to 17:00 GMT).
- Reproduction: An engineer attempts to reproduce the defect inside an identical test environment based on your reported steps.
- Remediation: If the defect reproduces and lies within the agreed technical scope, it is scheduled into the active build cycle and patched.
- Verification: The fix is deployed to staging, and you are notified to verify the outcome against the original reproduction steps.
Defects versus scope changes
Technical reviews frequently blur the line between a broken functional requirement and a change in system architecture. Maintaining clarity between these two categories ensures budgets and schedules remain stable.
- Defects: A feature documented in your agreed scope fails to operate according to the signed specification, fails across supported standard browsers, or throws an unhandled database error. Defects are remediated within the project budget.
- Scope changes: A request that introduces new validation rules, alters data schema requirements, adds unsupported device considerations, or modifies user permissions outside the original agreement.
When feedback requests architectural alterations or functional enhancements, we pause the relevant component and prepare a bespoke quote. Bespoke quotes are delivered within 48 hours of receiving a complete technical brief. Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site.
Common technical reporting failures
Technical triage frequently halts due to three preventable reporting issues:
- Local cache conflicts: Testing updates without performing a hard refresh (clearing cached static assets or testing within an incognito session) often produces false bug reports when older client-side scripts clash with updated server code.
- Piecemeal delivery: Sending individual messages or sporadic screenshots over multiple days rather than submitting a single unified technical punch-list. Piecemeal comments cause duplicate triage and context switching.
- Unstated environmental variables: Attempting to run builds within unlisted legacy browsers or heavily restricted corporate proxy networks without informing the development team in the original scope.
Technical feedback checklist
Run through this sequence before sending technical feedback via Ask Xylo:
- [ ] Hard-refresh the browser or test the staging build in an incognito window.
- [ ] Reproduce the issue twice following the exact same sequential steps.
- [ ] Note down the target URL, exact route, and input parameters used.
- [ ] Capture the browser name, release version, and device operating system.
- [ ] Open developer tools to check for red console warnings or failed network responses.
- [ ] Package screenshots or screen recordings that show the entire viewport, including the system clock and address bar.