Change delivery and operational consistency Working prototype
ChangeMap
One decision can leave five different versions of the truth behind.
The problem
The announcement changed. The old instruction did not disappear.
A team approves a new deadline, eligibility rule or process. The main page changes, but a form, confirmation email, downloadable guide or front-desk script may still carry the old version. Staff think the work is complete while customers continue to encounter conflicting instructions.
Who it may help
A recognizable operating problem.
Admissions teams, service operations, growing companies and product teams coordinating changes across customer-facing channels and internal guidance.
Picture the handoff.
A school extends its application deadline. The website shows the new date, but the application form still closes early and the confirmation email repeats the old one. A staff member needs to know every affected place, who owns it and whether anyone checked the actual experience after the update.
What we want to learn
What could improve if it fits?
- Map the footprintList affected pages, forms, messages, documents and staff instructions in one change record.
- Give each update an ownerMake responsibility and current progress visible instead of relying on scattered messages.
- Check the current versionRecord a reviewer note and reopen checks whenever the approved decision changes.
These are outcomes to test with teams, not measured results from customers.
Working scope
What you can try today.
The working browser demo includes fictional admissions data. You can create a decision, map touchpoints, change their progress, record verification notes, revise or withdraw the decision, review its history and export JSON. Data stays in that browser. It does not connect to your website, discover every affected page, notify owners or independently prove publication.
Try it yourself.
- Open the fictional admissions change and find the form that is updated but not yet verified.
- Record a reviewer and what you inspected, then add another affected touchpoint.
- Revise the approved instruction and watch previous verification reopen.
Engineering evidence
The implementation behind the demo.
JavaScript decision model, browser localStorage, responsive interface, JSON export, automated rule tests and GitHub Pages deployment.
The linked repository includes the code, local setup instructions and automated tests. The GitHub Pages site runs the safe browser demonstration.
Pilot boundary
What the demo does not prove.
The verified count covers only mapped touchpoints and is based on user-entered notes. It is not an independent audit or a production approval system.
A shared deployment would require team authentication, role-based permissions, persistent audit records and integrations appropriate to the organization.
Free guided pilot
Test one case with your team.
Choose one recent policy or process change and map the places your team would need to review. We can use safe example information and learn whether this view catches a handoff that the current process misses.
No fee and no obligation to adopt. A production build would be discussed and scoped separately.