Made with Tertin · 5 slides
Project Meridian: Service Portal Launch
A five-slide fictional internal kickoff, with pilot scope, a six-week delivery plan, owners, risks and launch criteria.
Published
About this example
Fictional project and organization. The portal screen, schedule, responsibility map and acceptance criteria are illustrative planning materials, not an actual launched system or achieved result.
Reviewed example created with Tertin. Prepared for public demonstration.
Open the reviewed presentation
Open or download the reviewed HTML presentation to inspect the slides in your browser. The published slide previews were rendered from this reviewed copy.
Every slide, with its text
Open a preview to see it at full size. Read the text from the published presentation beside each image to explore the content as well as the design.
1. One front door for internal service requests
Text from the published presentation
PROJECT MERIDIAN / INTERNAL KICKOFF
One front door for
internal service requests
Make request ownership and status visible across a fictional organization.
MERIDIANPORTALREQUESTORSERVICE TEAMOWNER QUEUESTATUS SIGNALsubmit / searchtriage / resolveroute / assignopen / active / donesingle intake layer
FIG 01 / SYSTEM INTENT / REV 0.1
FICTIONAL DEMONSTRATION
2. Agree what the pilot includes
Text from the published presentation
02 / PILOT BOUNDARY
Agree what the pilot includes
IN SCOPE / SHIP THE LOOP
01 REQUEST INTAKE
Find a request type, submit the details.
02 ASSIGNED OWNER
Show who is accountable for the next move.
03 STATUS UPDATES
Let requestors see open, active and done.
OUT OF SCOPE / HOLD THE LINE
PAYMENTS
EMPLOYEE RECORDS
EXTERNAL CUSTOMER ACCESS
MERIDIAN / REQUESTS● PILOT MODE
NEW REQUEST
Access a shared workspace
REQUEST TYPE
Workspace access ⌄
DETAILS
Add a short description...
OWNER / WORKPLACE OPSSUBMIT REQUEST
Status appears here after submission: OPEN
FIG 02 / PILOT CONTRACT / ILLUSTRATIVE UI
FICTIONAL DEMONSTRATION
3. Six weeks, three linked workstreams
Text from the published presentation
03 / DELIVERY SEQUENCE
Six weeks, three linked workstreams
A compact path from agreed flow to pilot evidence.
WEEKS
01
02
03
04
05
06
DESIGN
FLOW + SCOPE
map request journey
BUILD
PORTAL LOOP
intake, owner, status
PILOT + REVIEW
EVIDENCE LOOP
script, observe, adjust
GATE A / DESIGN APPROVAL
GATE B / PILOT READINESS
FIG 03 / DEPENDENCY MAP / ILLUSTRATIVE DATA
FICTIONAL DEMONSTRATION
4. Every decision has an owner
Text from the published presentation
04 / GOVERNANCE + RISK
Every decision has an owner
RESPONSIBILITY TABLE / ILLUSTRATIVE DATA
DECISION AREAACCOUNTABLE OWNER
PrioritiesSPONSOR
Interaction designDESIGN LEAD
ImplementationENGINEERING LEAD
Pilot feedbackOPERATIONS LEAD
RISK MAP / FICTIONAL RISKS
R01 UNCLEAR ROUTING
Requests stall between service teams.
MITIGATION
Agree a request-owner list before build starts.
R02 SLOW FEEDBACK
Pilot findings arrive too late to act.
MITIGATION
Schedule a weekly review with evidence in hand.
FIG 04 / OWNER MODEL + RISK CONTROLS / ILLUSTRATIVE DATA
FICTIONAL DEMONSTRATION
5. Launch only when the pilot is ready
Text from the published presentation
05 / DECISION TO CLOSE
Launch only when
the pilot is ready.
The team earns launch by showing the loop works, not by finishing a screen.
ACCEPTANCE CHECKLIST / ILLUSTRATIVE DATA
✓12 scripted request scenarios pass
✓Every request type has an owner
✓Pilot users can find request status
CLOSING DECISION
Confirm the operating contract.
Scope is fixed for the pilot.
Owners accept their decision areas.
Weekly review time is booked.
NEXT MOVE / ALIGN TODAY
PROJECT MERIDIAN / REV 0.1
FICTIONAL DEMONSTRATION