The context
When a global company rolls its template system out to a new market, someone has to check every global user story against that market's rules. On my last DMS rollout I reviewed 200+ global user stories for fit in two markets, then wrote gap analysis and Key Design Decision (KDD) documents for business sign-off.
That review is careful, repetitive work. I already used Microsoft Copilot to speed up analysis and documentation on that project. This concept designs a more structured, repeatable version.
The problem
Fit-gap review is slow, and most of it repeats for every market:
- Every story is read by hand against tax, invoicing and legal rules for each market.
- Gaps, reasons and decisions sit in spreadsheets that drift out of date.
- KDDs and localisation stories are written from scratch each time.
- The same review starts again for every new market.
What I did
- Built the review approach from my own fit-gap and KDD work.
- Designed a market rule library and the assistant's output format.
- Defined review steps so the BA owns every decision.
- Wrote a sample of the assistant's output and the BA's decisions.
The process, before and after
Each column is a team or system. Numbered badges point to where time is lost today, and how the design saves it.
Scroll sideways to see the whole diagram →
- 1Each story is checked by hand against tax, invoicing and legal rules for every market.
- 2Gaps, reasons and decisions sit in spreadsheets that drift out of date.
- 3Key Design Decisions are written from scratch for each gap.
Scroll sideways to see the whole diagram →
- 1Each story is compared with a written library of market rules.
- 2Every suggestion quotes the rule behind it.
- 3The BA makes every call. Suggestions are only a starting point.
- 4Draft KDDs and Gherkin stories are prepared for the BA to edit.
What changed, step by step
| Step | Before | After |
|---|---|---|
| Checking stories | Read one by one against the rules | Assistant suggests fit or gap with the rule quoted |
| Recording gaps | Spreadsheets | One log with suggestion, decision and reason |
| KDDs and stories | Written from scratch | Drafted for the BA to edit |
| Next market | Start again | Reuse the rule library and past decisions |
The approach
- 1Build a market rule libraryWrite each market's rules for tax, invoice and credit-note numbering and legal reporting as plain sentences.
- 2Compare story by storyThe assistant compares each global story with the rule library and suggests fit, partial fit or gap.
- 3Quote the reasonEvery suggestion quotes the rule behind it, so the BA can check it in seconds.
- 4Let the BA decideThe BA accepts, edits or rejects each suggestion. Nothing is final until the BA decides.
- 5Draft the paperworkFor each agreed gap, the assistant drafts a KDD and a localisation story with Gherkin acceptance criteria for the BA to finish.
- 6Reuse for the next marketThe rule library and past decisions carry over, so the next rollout starts ahead.
Sample work: sample fit-gap output
| Global story | Market rule | Suggestion | BA decision |
|---|---|---|---|
| Invoices follow one global number sequence | Invoices must follow a locally approved number series | Gap: numbering format | Agreed: configure per market |
| A credit note can be raised without a reference | A credit note must reference the original invoice | Gap: mandatory reference | Agreed: localisation story |
| Tax is shown as one total per invoice | Tax must be shown on each line | Partial fit: print layout | Changed: layout change only |
| Sales report by salesman | No statutory requirement | Fit | Agreed: no change |
Illustrative rows written for this portfolio. They do not describe any real market's rules.
Expected outcomes
- A faster first pass through large global backlogs.
- Every fit and gap decision recorded with its reason.
- KDDs and localisation stories start from a consistent draft.
- The next market rollout starts from what was already decided.
Design principles
- The assistant suggests; the BA decides.
- Quote the rule, or the suggestion is useless.
- Write the rules in plain sentences first. AI can only check what is written down.
Concept case study written during my 2026 sabbatical. It is not a deployed client solution. Examples are generic.
Next case study · AI-05Catching master data problems before go-live, not after