Portal Help Centre

Overview

The FMAC portal is now the main operating system for the centres. It handles instructor registers, student and family records, prospects, online payments, SmartPay imports, graduations, blackbelt tests, equipment packs, summer challenge tickets, lesson planning, content publishing, emails, texts, database checks and disaster recovery visibility.

Daily workflow

The simplest daily routine is: check the dashboard, load the day, use the Daily Plan, book or mark attendance, then finish with payment and communication checks.

1. Open Instructor Dashboard and confirm the correct centre and date.
2. Open Daily Plan to see the money target, planned asks, prospects due in, graduation/payment/equipment asks and follow-ups.
3. Use Quick Booking for students using the old site, students who ring ahead, or walk-ins before class starts.
4. Use the class register to mark attendance once the lesson happens.
5. Record Daily Plan results: Paid, Asked, Not in, Follow up, Joined or No.
6. Open Payment Reconciliation if online payments, graduation payments or refunds look out of step.
7. Open Communication Centre or Communication Queue to check emails/texts due, sent or failed.

Daily Plan and Sales Desk work best together. If a person is due to be asked for graduation, equipment, paid in full, instructor programme or another item, open Sales Desk from that row so the student and item are already in context.

Login and permissions

Instructor access is controlled by staff login, role and centre permission. Passwords are hashed and cannot be read back. Email/SMS sending passwords are separate SMTP secrets because the portal must decrypt them to send messages.

Centre access

• CanView: user can see the centre's data.
• CanEdit: user can edit centre/student data.
• CanTransferIn and CanTransferOut: user can move students between permitted centres.
• System/admin access: user can use full setup, health and migration tools.

Student portal family login

Both parent emails can have their own portal password. If a second parent cannot log in, check the family login records and password reset flow for that email rather than asking them to use the first parent's address.

Dashboard and navigation

The dashboard is the main instructor screen. It shows centre/date controls, register actions, key working pages and a compact admin menu. The menu starts minimised so the day-to-day register stays cleaner, and instructors can expand it when they need the wider admin tools.

Main pages

What the dashboard numbers mean

Dashboard income and target widgets are grouped by centre and revenue stream. If a payment appears under the wrong centre, first check whether the student trains at another permitted centre, then check Payment Information and Stripe route/webhook data in Payment Reconciliation.

Centre setup

Centre Setup controls billing, feature switches, Stripe keys, prices, paid-in-full options, instructor-training prices, pro-shop, graduations, merit badges, staff and migration templates. Most pages should use the selected centre rather than a global default.

Key setup areas

• Centre settings: centre name, contact details and portal defaults.
• Cross-centre booking: controls which centres students can see for class booking. Their primary centre should be prioritised, with allowed partner centres shown after it.
• Features: enables or hides pages per centre.
• Stripe keys: stores centre-specific Stripe configuration so one centre does not accidentally route through another centre.
• Prices: tuition, membership, paid in full and programme prices.
• Graduations: graduation events, locations, times and rank/session mapping.

Use global defaults only as a starting point. Once Bolton, Farnworth and Hindley are wired, centre-specific Stripe/pricing/settings should be preferred for live payments.

Students and families

The student list and student detail pages are the main place to inspect and repair individual records. Family-linked students can share payments, portal logins and subscription records, but each student still needs their own rank, training status, graduation records and attendance history.

Family rules

• Family tuition income should be counted once for the family, not once per student.
• Family tuition renewal dates should update together when a family tuition payment is taken.
• Membership/insurance renewal dates should also move together where the family paid together.
• Shared Stripe customers or subscriptions are not automatically a problem when they are genuine family links.

Rank corrections

If a rank is corrected manually in the Students table or on a student screen, check the next graduation target afterwards. The portal should use the current rank on the student record and calculate the next eligible graduation rank from the rank sequence, not from an old graduation row.

Transfers

Use Student Transfer to move a student between centres you own or manage. Moving the centre record does not cancel a Stripe subscription by itself, but you should still check the Stripe/customer details and centre-specific reporting afterwards.

Quick booking and attendance

Quick Booking is for current students who need to be booked quickly without using the student-facing booking flow. Use it for old-site bookings, people who ring ahead, students training at another centre, or walk-ins before the lesson has started.

How to use it

1. Select the centre and class date.
2. Search for the current student by name, email or mobile.
3. Choose the centre they are actually booking into if they train across multiple locations.
4. Use Book in before the class starts, or Walk-in attended once they have arrived.

Summer Challenge link

Summer Challenge tickets and attendance are linked. If a student earns an attendance ticket for a week and has no matching booking, the portal can backdate the likely attendance so the same job does not need doing twice.

Open quick booking

Timetable and lesson planner

The timetable provides the structure for class sessions, booking eligibility and lesson planning. The Lesson Planner uses lesson times from the timetable so instructors can plan around real class lengths.

Timetable manager

• Create and edit class schedule patterns.
• Generate future sessions.
• Close a week or deactivate a session.
• Set centre, day, time, capacity and eligibility.

Lesson planner

Use the Lesson Planner to build structured class plans covering warm-up, basics, kicks, punches, strikes, forms, self-defence, fitness, mat chats and finishers. It is designed so any instructor can open the plan and know what to teach for that session.

Prospects and SMS

The prospect dashboard tracks enquiries, trial bookings, attendance, joining and follow-ups. It now includes quick SMS helpers that open the local messaging app with a centre/programme-specific message.

Suggested SMS routes

• Tiger Tots: for children aged 3 to 6, using the selected centre's Tiger Tot timetable and instructor/contact details.
• Blackbelt Leadership: for beginner/positive-start prospects, using the selected centre's beginner timetable and centre contact details.

What should be centre-specific

Centre name, instructor name, phone number, class days/times and school wording should come from the selected centre/timetable rather than a fixed Hindley or Bolton message.

Open prospects

New student signup

New Student supports classroom signup, public signup, normal monthly signups, paid-in-full signups, free tuition/free membership codes and contract signing.

Classroom General Information

The classroom mode is the in-person general information form. It should validate important details before saving, including student name, date of birth, parent/contact name, email, phone and address. Codes can be used internally for Free Tuition for a Month or Free Membership, but the codes should not be shown to students.

Starting ranks

New starters should be created with the correct starting rank for their programme. Standard Blackbelt Leadership students should normally start at 10th Gup White Belt; Tiger Tots should start on the Tiger rank route. Old income placeholder rows such as room hire or SmartPay.uk should not be treated as normal students in checks.

Paid-in-full signup

If a new starter chooses a paid-in-full tuition option, the signup should use the paid-in-full price setup, record the income under Savings, set the correct paid-through date and load the paid-in-full contract for signing.

Contracts and paid in full

Contracts store what the family agreed to at the time of signup, upgrade or paid-in-full purchase. The signed agreement should be retained as a snapshot so future price changes do not alter the original terms.

Contract routes

• New business: new student signups should create or send the contract as part of the signup flow.
• Sales Desk: if tuition, paid in full or instructor programme is sold from Sales Desk, the correct contract should be loaded for signing.
• Paid in full: send a welcome/thank-you email confirming the number of months saved and include the paid-in-full contract.
• Instructor programmes: AIT, JIT and CIT paid-in-full or payment plan sales should use the relevant instructor programme agreement.

Downpayment then monthly

For Stripe plans with a downpayment and monthly payments, the first payment should be only the downpayment. The monthly subscription should start one month later and cancel when the agreed term is complete.

Instructor programmes

Instructor training covers JIT, AIT and CIT routes. Centre Setup stores the available plans, centre-specific prices, Stripe price IDs, whether approval is needed and whether each option is visible on the student portal.

Sales Desk route

When a student signs up to AIT/JIT/CIT through Sales Desk, the income should be added to the correct totals, the student should show on the eligible course route, and the correct contract should be loaded for signing. Paid-in-full instructor course payments should also send the correct confirmation email and contract copy.

Student portal route

Student-facing instructor programme options should only show where the centre has enabled them and where the student is eligible. If approval is required, the portal should track that status before treating the student as fully enrolled.

Training dates

Future instructor training dates should be managed centrally and attached to the relevant centres so students and instructors see the correct date, time, venue and address.

Payments and reconciliation

Payments are recorded across Stripe, SmartPay/FuturePay, manual payment rows and the main Payment Information table. Because several systems can create rows, Payment Reconciliation should be used daily when live payments are active.

Payment Reconciliation checks

• Stripe payments not matched to student records.
• Graduation payments paid online but not marked paid.
• Graduation forms/payment flags not fully applied.
• Refunds that have not reduced totals.
• SmartPay imports missing from monthly or yearly stats.
• Duplicate Payment Information rows after webhook/manual repair.
• Overpayments that may need a future store credit.

Income stream rules

New starter payments should be New Business unless they are genuine tuition renewals or membership/insurance renewals. Second-month tuition payments should be Tuition. Paid-in-full tuition should use Savings so reports match the older records.

SmartPay imports

SmartPay Billing imports the monthly workbook, stores the remittance, matches rows to students and feeds monthly/yearly stats. If an import says PHP ZipArchive is missing, the PHP extension must be enabled on the server running the import.

Daily, monthly and yearly stats

The planning and stats pages help forecast, record and verify centre performance. They should always be viewed by centre first before comparing across the full school group.

Daily Plan

Shows today's money target, planned asks, actual taken, still needed and people left to speak to. Prospects due in today, students due in today, monthly-plan rows, graduations and payments should all be visible where relevant.

Monthly Plan

Lets instructors plan New Business, Upgrades, Events/Seminars, Instructor Programme upgrades, Savings/Paid in Full, Monthly Tuition, Graduations, Pro-Shop sales and Other. Each income stream can be selected in bulk, and equipment pack rows should not duplicate the same item twice. New Business target amount can auto-fill from the recent average monthly amount per new student, but can still be overridden manually.

Monthly and yearly stats

Stats pages show income, new students, lapsed students, prospect conversion and stream totals by centre. Family tuition should be counted once for the family, and SmartPay/Stripe/manual records should all feed into the correct period totals.

Graduations

Graduation flow covers the student portal form, online payment, email reminders, instructor/student detail actions, the graduation register and automatic roll-forward to the next grading.

Student portal graduation payment

Students should be able to see their upcoming graduation, confirm the form, see the date/time/location, and pay online where Stripe is configured for that centre. The portal should show rank text, not raw rank IDs.

Email rules

• Form/payment chase emails should only go to students who have not filled the form in or have not paid.
• The week-before reminder should go to students who have submitted forms, reminding them of time, date and venue.
• Plain-text email versions should include the payment/form link, not just the HTML button.
• Email templates should not show internal names such as dbo.[Graduation Dates].

Graduation register

The register shows who is graduating and lets instructors edit attendance, where, belt size, target grade and student links. The Graduation Status should show the actual stored "Where" value rather than guessing it.

Graduation refresh

Database Health includes a graduation refresh preview. It creates missing future graduation rows for active students, recent signups and students who completed the previous grading. It does not change the student's current rank. It should set the next available future graduation date, not recreate old events.

After a graduation

Once a normal graduation is completed, successful students should be rolled forward to their next available grading list. Use the register filters for "not completed yet" or "not emailed yet" to narrow down students after class.

Blackbelt test route

Blackbelt testing is separate from normal colour-belt graduations. The system should only offer blackbelt assessment/prep/test routes to students on the final route toward 1st Dan, 2nd Dan or 3rd Dan as appropriate.

How the route works

• Students attend a Blackbelt Assessment day before the main test.
• Payment is due before the assessment day.
• If they fail the assessment/test, a retest should not require another payment.
• If they pass and have not already bought it, they should be prompted for a Blackbelt Pack.
• Free Dan Prep days should only be offered to the relevant final ranks, not to ordinary colour-belt graduation candidates.

Blackbelt test fees

The family pricing rule is: first person £150, second person £150, then £75 for each extra person after that.

Open blackbelt test register

Campaigns and equipment packs

Campaign Planner, Summer Challenge and equipment packs help manage seasonal activity, pro-shop sales and required kit purchases without sending unnecessary duplicate emails.

Summer Challenge

Students can see their ticket total, instructors can approve activities, and the school can export a CSV at the end of the campaign. Attendance tickets can also help backfill missing attendance bookings for the week.

Pack rules

• Tiger Tot Pack: for Tiger Tots Level 0 and above who have not already bought a Tiger pack.
• Basic Pack: for 10th, 9th, 8th and 7th Gup students who do not already have a recorded pack purchase.
• Leadership Pack: normally sold at 6th Gup Green Belt; students over red belt can be assumed to have already bought previous leadership packs where historic data is incomplete.
• Blackbelt Pack: for students about to hit blackbelt or newly promoted to 1st Dan who have not already bought it.

Pack purchase history

Use purchase markers to record packs bought before the portal had enough data. This prevents extra reminder emails. Blackbelts can be assumed to have already bought leadership and blackbelt-required packs unless the record says otherwise.

Pro-shop images

When adding or editing pro-shop/equipment items, use the existing image library where possible so images uploaded for one centre can be reused rather than uploaded again. This keeps pack setup faster and avoids mismatched product pictures across centres.

Student/family portal

The student portal lets families book lessons, view family members, see progress, handle graduations, make payments, access the pro-shop and view account details. It should prioritise the student's primary centre but can show other permitted centres for cross-centre training.

Make payments clearer

• Payment cards should clearly say what the payment is for before checkout starts.
• One-off tuition top-ups should be separate from normal monthly tuition.
• Upgrade options should show the current package and only show valid upgrades, not downgrades.
• Short-term one-month upgrades should charge only the difference between the current and next package.

Family portal access

Both parent emails can have their own student portal password/login. Families should not have to share the first parent's email address if a second parent needs access.

Learning resources

The student portal can provide terminology, Tang Soo Do history, downloadable Dan Manual access and links to relevant FMACTV YouTube videos for the forms, self-defence or training theme a student is working on.

Dan Manual

The Dan Manual PDF is a paid resource. The download should be charged at £5 and only released after payment has been confirmed.

Videos

Videos should be mapped by rank, form, self-defence or monthly lesson focus. Use the official FMACTV channel links and keep the content relevant to what the student is currently working on.

Content and SEO

Content SEO lets you write useful martial arts articles inside the portal and publish or schedule them to the WordPress-backed sections of the Bolton and Hindley sites.

Publishing targets

• Bolton site starts at https://www.boltonmartialarts.co.uk/studentportal/.
• Hindley site starts at https://www.hindleymartialarts.co.uk/StudentPortal/.
• Do not assume the WordPress area is at the root of the domain.

Good article topics

Prioritise helpful local content: what to expect at a first lesson, martial arts for confidence, Tiger Tots, beginner Tang Soo Do, school holiday activity, grading preparation, self-defence basics, family classes and how martial arts supports focus and discipline.

Open content SEO

Emails and communication safety

Email delivery uses the shared mail system and encrypted SMTP secrets. Communication Centre is the safety screen for anything due, sent or failed across graduation reminders, prospect flows, welcome emails, password resets, equipment pack emails and membership/insurance reminders.

Membership and insurance emails

Membership renewal emails should populate family name, correct family fee and due date. If tokens such as {FamilyName}, {Fee} or {DueDate} appear in the sent message, the template/token data needs repairing before sending the next batch.

Email logo

Transactional emails should include the FMAC logo where the template supports HTML. Plain-text fallbacks should still include the important link and payment/form details.

Duplicate prevention

Bulk graduation and pack emails should dedupe by email/family where appropriate and respect whether a form/payment/purchase has already been recorded.

Database health and DR

Database Health checks whether the portal is connected, whether failover is ready, whether backups are fresh, whether data is joined up and whether the database has the main performance indexes it needs.

Main health panels

• Primary, standby and backups: shows active database, standby readiness, backup marker, backup size and free space.
• Optimisation: checks core and phase-two indexes, table size, stale statistics and fragmented indexes.
• Portal cohesion: checks missing graduation rows, payment/webhook issues, family renewal dates, timetable issues and failed emails.
• Migrations: shows which SQL scripts have been tracked as applied.

Backup/DR rules

Keep database backups on the server's F: drive rather than C: so critical Windows/IIS tasks still run if backups grow. Old hourly backups can normally be deleted once a newer backup has been confirmed, but keep enough history for recovery. The backup process should also write a marker file so Database Health can show last successful backup, size and folder free space.

Optimisation script

Run sql/372_portal_database_optimisation_phase2.sql during a quiet period to add safe phase-two indexes. If Database Health later shows stale statistics, set @UpdateStatisticsAfterIndexing = 1 in that script and rerun during a quiet period.

Open database health

Bug reporting

Use Bug Reports when a page errors, saves the wrong thing, shows unexpected data or needs a small improvement logged. Reports capture the page URL, browser details, screen size, logged-in user and centre where available.

Good bug report detail

• What page you were on.
• Which centre and student/family/payment was involved.
• What you expected to happen.
• What happened instead, including any error text.

Open bug reports

Hosting and domain

The portal is hosted on IIS and can be reached through the current dynamic-DNS site and the newer student portal domain. Because the server does not have a static IP, DNS should avoid fixed public A records where possible and use the chosen workaround/redirect route.

SSL certificates

Use win-acme to create/renew IIS certificates for the portal host names. Include the host names that IIS will serve, usually the root portal host and the www version where both are bound.

Emailing students the new address

When the portal address changes, send students the updated URL and refresh password/reset links for anyone who has not yet set a password. Password links should point at the current live domain.

Open domain setup notes

Troubleshooting

Admin reference

These are the main admin areas and data flows to remember when repairing or checking the portal.