Feedback process

Your feedback is the main reason the design partnership exists. This page explains how to give feedback that is easy to act on and what happens once you send it.

What makes feedback useful

The most actionable feedback ties a specific behavior to a specific expectation. Tell us what you were doing, what you expected, and what happened instead. When a score or recommendation surprised you, name the capability and the maturity and criticality values behind it. Because FIS is deterministic and explainable, we can almost always trace a surprising result back to its inputs, and that trace is often the fastest path to a fix or a clarification.

Separate three kinds of feedback so we can route them correctly:

• Defects: something produced a wrong or inconsistent result.

• Friction: the outcome was correct but the path to it was confusing or slow.

• Gaps: a capability or workflow you need that does not yet exist.

What happens next

Feedback is reviewed on a regular cadence and weighed against what other partners are reporting. We will tell you whether something is planned, under consideration, or out of scope, and we will explain the reasoning rather than leave you guessing.

If a result looks wrong, capture the capability name and its current and target maturity before anything changes. That snapshot makes the issue reproducible.

For anything blocking your day-to-day use, route it through the support process instead, since that path is faster for urgent issues.