Purpose of This Document
This is a living alignment tool between TSH and Symph for the Support & Maintenance phase (Apr 2025 - May 2027). It captures the current platform status, new feature requests, and pending decisions that need Finance alignment.
Use this to track what's been requested, what it costs in dev effort, and what needs approval before work can begin.
Platform Context
TSH uses SimplyBook as its booking engine, integrated with Strapi CMS, 24K facility management, Microsoft Dynamics F&O, Stripe payments, and SharePoint. After 6 months in production, operational requirements have pushed SimplyBook beyond its intended capabilities.
- 24 known platform items with documented workarounds and resolution paths
- 12 change requests pending approval or scoping, totalling 66+ man-days
- Build 1.14 (next release) addresses 3 high-frequency issues, awaiting TSH approval
How to Use This
- Issues & Solutions ↗ - Current platform limitations, their workarounds, and what it would take to fix them. Filter by category, type, or frequency.
- Requested Changes ↗ - New features and changes with man-day estimates, status, and impact. These are the items that need approval or scoping decisions.
- Next Steps ↗ - Consolidated timeline of actions, risk flags, and open questions requiring alignment.
- Finance Focus ↗ - Strategic summary of all finance-related needs, our plan for each, and decisions needed.
- All Comments ↗ - Feedback and notes from reviewers, linked to specific items.
| # | Issue | Type | Category | Frequency | Dev Required | Version |
|---|
| Change Request | Group | Man-Days | Systems Affected | Requested By | Status |
|---|
Loading...
Finance Alignment - Where We Stand
This is a summary of all finance-related platform work: what's already been scoped, what's in progress, and where we need alignment before moving forward. Everything below maps directly to items Finance has raised over the past 6 months of production.
1 What Finance Has Raised
These are the five core finance-related needs identified through production operations over the past 6 months.
Payments today are spread across Stripe (card/PayNow), GL invoices (bank transfers), and off-platform records. Finance needs a single view for reconciliation and audit.
Ability to charge guests after a booking (damages, cleaning fees, overtime). Zero incidents so far, but TSH wants this proactively. Three technical options have been proposed.
Bank transfers and invoiced payments currently require manual dev intervention to update booking status. Volume is growing and needs to be automated.
The GST toggle is already built but has never been turned on. Activation impacts refund calculations, pricing display, and fee handling across all booking types.
Only full refunds are currently supported. Partial refunds require manual calculation. This gets significantly more complex once GST is active.
2 Our Plan - Item by Item
Here is what we plan to do for each Finance need, the estimated effort, and what's required to move forward.
🏦 Alternative Payment Methods View in Requested Changes ↗
Ready to Execute| Effort | 2 - 3 man-days |
| Systems | SimplyBook, Strapi, Dynamics F&O |
| Requested by | Finance / Operations |
SimplyBook Pay (SB Pay) already supports marking payments as received for non-Stripe methods. Finance confirms the payment in SB Pay, which generates an invoice. We update the invoice-handling API to automatically trigger booking status updates and 24K sync - the same flow that currently only works for Stripe webhooks. This eliminates the need for dev intervention on every alternative payment.
💳 Central Payment Visibility View in Requested Changes ↗
Two Options - Needs Decision| Effort | 2 - 5 man-days (depends on option) |
| Systems | Stripe, Dynamics F&O, SimplyBook, Strapi |
| Requested by | Finance |
Finance confirms payment transactions in SB Pay. The existing F&O Transactions table in the CMS can be reused to show these. Lower effort, faster delivery. Best if SB Pay confirmation is the standard process.
Build a new table that pulls from all payment sources: Stripe (card/PayNow), Dynamics F&O (GL invoices), and external records. Single unified view. Higher effort, but gives Finance one place for everything.
🧾 GST Activation View in Requested Changes ↗
Ready to Execute| Effort | 2 man-days |
| Systems | SimplyBook, Strapi, Stripe, Dynamics F&O |
| Requested by | Finance / Zhi Kin |
The GST toggle is already built in the system. Activation involves: toggling the GST setting on, verifying it applies correctly to all payment types and booking categories, validating refund behavior, checking fee absorption rules, and updating email templates. Similar rollout approach to the hotdesk launch.
📄 Extra Charges / Post-Booking Billing View in Requested Changes ↗
Awaiting Decision Since Sep 2025| Effort | 23 - 96 man-days (depends on option) |
| Systems | SimplyBook and/or Strapi, Stripe, Dynamics F&O |
| Requested by | Finance |
- Add extra charges to bookings after they are confirmed (cleaning fees, damages, AV equipment, overtime)
- Send payment links to members for these additional charges
- Track all extra-charge payments properly for reconciliation
Zero incidents in 6 months of production, but TSH wants this proactively before charges arise.
- SimplyBook already has a lot of steps to process or modify a booking - adding extra charges will create even longer workflows and more things for staff to manage
- Each customization we add to work around SimplyBook's limitations creates more instability. Webhook failures are increasing.
| What Matters | Option 1: SimplyBook | Option 2: Strapi | Option 1.5: Hybrid ★ |
|---|---|---|---|
| System Stability | ❌ Poor (webhook issues) | ✅ Good (reliable) | ✅ Good (reliable) |
| Single View (Accuracy) | ✅ All in SimplyBook | ⚠ Split systems | ✅ Data syncs back to SimplyBook |
| Reports / List View | ❌ None (check per booking) | ✅ List of all charges | ✅ List of all charges |
| Daily Staff Experience | ❌ Harder (more clicks) | ✅ Easier | ✅ Easier |
| Fix Payment Failures | ❌ Need dev help | ✅ Can retry | ✅ Can isolate & retry |
| Human Error Risk | ⚠ Medium | ⚠ Medium | ⚠ Medium |
How it works: Staff adds extra charge in SimplyBook via "Products for Sale", updates status, system sends payment link. All data stays in SimplyBook.
Downsides: When webhook errors happen, payment links fail and cannot be resent without IT help. No list view of charges (need to check each booking individually). Webhook timeouts already increasing with current usage. Wide effort range because scope depends on how many edge cases need handling.
How it works: Staff creates extra charge in Strapi (new page), Strapi sends payment link, member pays. Data stays in Strapi only.
Downsides: Admins must check two separate systems (extra charges in Strapi, original booking in SimplyBook). No direct connection between them.
Upside: Cleaner, faster, fewer errors, easier to see a list of all additional charges.
How it works: Staff creates extra charge in Strapi (reliable entry). Strapi sends payment link. Member pays. All data automatically copies back to SimplyBook.
Why this is best:
- Can see everything in SimplyBook (single view preserved)
- Staff gets a reliable system for data entry (Strapi)
- If errors happen, easy to isolate which part failed and fix it
- Adding extra charges in Strapi does not impact existing SimplyBook workflows
- Better UI/UX, cleaner, faster, fewer errors
↩️ Partial Refunds
Needs Scoping| Effort | TBD - depends on GST decision |
| Systems | Stripe, SimplyBook, Strapi |
Only full refunds are currently supported. Partial refunds require manual calculation by the team. Once GST is activated, partial refund calculations become significantly more complex (need to recalculate GST on the remaining amount). We recommend scoping this after the GST activation decision is made, since the approach depends on whether GST is active.
⚠️ Stripe Fee Leakage on Refunds
Platform Limitation - No FixWhen a refund is processed, Stripe does not return its processing fee. TSH absorbs this cost on every refund. This is a Stripe platform limitation with no technical workaround. The best mitigation is to reduce refund volume - for example, by allowing booking modifications instead of requiring cancel-and-rebook (which is part of the Build 1.14 release).
3 Immediate Next Release (Build 1.14) - Finance Relevant
Build 1.14 is the next scheduled release, currently awaiting TSH approval. These items directly reduce Finance-related operational overhead.
Reduces cancel-and-rebook cycle, which directly reduces Stripe fee leakage on refunds.
Reduces no-shows, which reduces refund requests and associated Stripe fee losses.
Eliminates expired payment link issues for membership bookings.
4 What We Need From Finance
These are the open decisions that are blocking progress. Each one has a recommendation from Symph.
Three options proposed. SOW for Option 1 sent September 2025, unsigned. Symph recommends the Hybrid approach (Option 1.5) for reliability. This decision unblocks several downstream Finance items.
Option A reuses the existing F&O table (2 MD, faster). Option B builds a new consolidated view (5 MD, more complete). Depends on whether SB Pay confirmation becomes the standard process for alternative payments.
Toggle is built and ready. We need a target date to schedule impact analysis, testing, and rollout. Also determines when we can scope partial refunds.
7 items scoped at 32 man-days total. Includes booking modifications, reminder emails (reduces no-shows), and several UX improvements. Ready to start once approved.
5 Recommended Sequence
If all decisions are made, here is the order we recommend tackling finance items based on impact, dependencies, and effort.
Immediate operational improvements. Reduces refund volume and admin overhead.
Quick win. Removes dev dependency for bank transfers. Enables SB Pay confirmation flow.
Depends on Phase 2 decision. If SB Pay works well, Option A is faster. Otherwise Option B.
Needs target date from TSH. Impact analysis required before activation.
Scoping depends on GST decision. Logic changes significantly with GST active.
Largest item. Blocked on option decision since Sep 2025. Can run in parallel with Phases 4-5 once approved.
Loading comments...