Mako Engine — Product Blueprint
A high-fidelity redesign of the full Mako experience: a conversion-ready onboarding flow, a customer request-tracking portal, an admin workspace for the team fulfilling requests, and a super-admin console for the business. Use the navigator on the left, the arrows, or ← → keys. Each screen carries a spec of what it contains and why.
Onboarding
Contact-first, 5-step flow that ends in payment and a live account — the leak that currently loses every lead.
Customer portal
Request quota, status lifecycle, threaded updates, real reports and self-serve billing.
Admin portal
A triage queue with SLAs, a request workspace, and per-client context for the team doing the work.
Super admin
MRR and churn, subscription management, and control of users, admins and their roles.
Onboarding · Contact & business
The redesigned flow opens by capturing who the lead is — the single biggest gap in the current form, which collected brand preferences but no name, email or phone.
What's on this screen
- Name, work email, phone, company — the identity fields the current form never asks for.
- Optional current-website field so the team can review what exists today.
- Persistent 5-step progress bar so people know how much is left.
- Brand panel restating the core promise (7 days, $0 upfront, managed) to hold motivation.
Why it changed
- The live form submits to a free email relay and asks zero contact details — a completed submission today is unreachable.
- Contact-first also lets Mako recover abandoners (save & resume by email).
- Every field is validated inline with a specific message, not one generic "complete all fields" error.
Onboarding · Goals & style
Keeps the two genuinely good ideas from the current form — the "one headache" question and the visual style picker — and tightens them into one step.
What's on this screen
- Multi-select goals that map directly to the modules the build team drops in (store, bookings, lead form…).
- The open "one headache" question, kept verbatim — it's the strongest part of the current form.
- Four style swatches with real colour/vibe previews rather than text-only labels.
Why it changed
- Goals + style were two separate steps; merging them cuts the flow to a length people finish.
- Selected goals pre-configure the request categories the customer sees later in the portal.
- Answers now persist per step, so a refresh or a "Back" never wipes earlier input.
Onboarding · Brand assets & domain
Where files and the domain decision are captured — reliably stored this time, not attached to an email that may never arrive.
What's on this screen
- Own-a-domain yes/no, and — critically — a field to actually enter the domain plus a DNS/SSL reassurance.
- Drag-and-drop uploads for logo, business photos and team shots, with clear size/format limits.
- Optional brand colour picker so designers start from the right palette.
Why it changed
- The current form asks "own your domain?" but never lets you say which domain.
- Uploads route through a free relay today — attachments are size-capped and often lost. Here they're stored on the account and visible to the build team.
- Everything is optional with a graceful "our designers will handle it" path, so no one stalls.
Onboarding · Plan & checkout
The step that turns a lead into revenue. The current flow ends by "selecting a plan" and emailing it — no payment, no customer. This closes the funnel.
What's on this screen
- Three plans with the monthly-request count front and centre — the mechanic the whole model is built on.
- Monthly / annual toggle to lift average contract value.
- A live order summary and Stripe card form; the CTA creates the subscription.
Why it changed
- Today the funnel ends without taking payment — a "customer" is just an email. This is the single highest-impact fix.
- Plan names are unified to Basic / Growth / Scale everywhere (the portal currently calls them Starter/Standard/Pro).
- Successful payment provisions the account, so onboarding and the portal are finally connected.
Onboarding · Build kickoff
The moment the current product doesn't have at all: a confirmed account, a clear 7-day timeline, and a door straight into the portal.
What's on this screen
- Confirmation that payment succeeded and the account exists.
- A 7-day timeline with concrete milestones, setting expectations for the managed build.
- A primary route into the portal and an optional kickoff-call booking.
Why it changed
- Today's success screen is a dead end ("we'll get back to you") with no account and no next step.
- A visible timeline reduces "is anything happening?" support pings during the build.
- Confirmation and welcome emails fire here — the start of the customer relationship.
Customer portal · Overview
The subscriber's home base. Leads with the one number the plan is sold on — requests used this cycle — and the real status of their site.
What's on this screen
- Quota meter ("5 of 8 used", resets in 9 days) — the plan's core mechanic, made visible for the first time.
- KPI row: open requests, real site status & uptime, average turnaround.
- Recent requests with true status pills, and a right rail for quota and site health.
Why it changed
- The live dashboard shows invented analytics ("Indonesia 1,025", "Male 70% / Female 30%") — removed entirely.
- Customers currently can't see how many requests they have left; churn risk when they feel they're "not getting value".
- UI now uses Mako's green brand instead of a stock blue admin theme.
Customer portal · Submit a request
The core recurring action. Structured enough for the team to act without back-and-forth, light enough that customers actually use their quota.
What's on this screen
- Category & priority so the team can triage and route work automatically.
- Affected-page field and rich description to kill the usual clarification round-trip.
- A running "uses 1 of your requests" note plus a live quota card and a "what counts" explainer.
Why it changed
- The current form is only Title / Description / Screenshot — no category, priority, page, or quota context.
- Showing quota at the point of submission sets fair expectations and nudges upgrades honestly.
- Save draft lets customers capture an idea without spending a request immediately.
Customer portal · Request detail
Where a request lives its life: a clear status lifecycle and a threaded conversation with the team — instead of a row that's forever stuck on "Open".
What's on this screen
- A 5-stage lifecycle (Submitted → Reviewed → In progress → Your review → Done) shown as a progress bar.
- A threaded conversation with the assigned team member, including file attachments both ways.
- A details rail: assignee, category, priority, which request-of-quota it counts as, affected page.
Why it changed
- Today every request is permanently "Open" with no way to converse — customers email or DM instead.
- A visible "Your review" stage gives customers an explicit approval step before a change ships.
- Each status change triggers an email/notification, so people don't have to keep checking.
Customer portal · Reports hub
Keeps the one genuinely working feature of the current portal — the live uptime check — and surrounds it with the real analytics and care reports that justify the subscription.
What's on this screen
- Live uptime / response / SSL checks (the current portal's one working feature, kept and elevated).
- Real visitor analytics from an integration (Plausible/GA) with top pages — not template filler.
- Downloadable monthly care reports the team publishes, giving tangible proof of the subscription's value.
Why it changed
- Today's charts show fabricated numbers and a "gender split" no small business tracks — a credibility risk.
- Care reports are the retention hook: a monthly artefact that reminds customers what they're paying for.
- All figures are labelled with their source and last-checked time so nothing looks invented.
Customer portal · Billing
Self-serve plan management with real invoices and cycle usage — matched to the plan names used everywhere else.
What's on this screen
- Current plan with request allowance, renewal date, and self-serve change/cancel.
- Payment method management and a clear next-charge line.
- A populated invoice history with downloadable PDFs.
Why it changed
- The live billing page shows "No invoices yet" and the Stripe test card — it isn't a real integration.
- Plan tier reads Growth, matching marketing and checkout (the portal currently says "Standard").
- Self-serve cancel is both a trust signal and a way to capture a save/downgrade offer at the right moment.
Admin portal · Request queue
The team's command centre — every client request in one triageable queue with owners and SLAs, replacing an inbox full of relay emails.
What's on this screen
- Every request across all clients in one sortable queue, with client, priority, assignee, due date and status.
- Triage KPIs: unassigned, due-today and overdue counts so nothing slips.
- Quick filters (Mine / Unassigned / Urgent / by tier) and an SLA countdown per row.
Why it changed
- There is no admin side today — requests land as emails to info@ with no ownership, status or SLA.
- Colour-coded priority and overdue flags let the team see what needs attention at a glance.
- Assignment routing can key off the request category captured in the customer form.
Admin portal · Request workspace
Where an agent actually works a request: full client context, status controls, internal notes, and time tracking alongside the customer thread.
What's on this screen
- A tabbed panel splitting client-facing replies from internal team notes on the same request.
- A status control, assignee, SLA and time-logging in the right rail.
- Client context at a glance: plan, requests used this cycle, tenure — so agents prioritise correctly.
Why it changed
- Internal notes keep coordination out of the customer's view — impossible with the current email flow.
- Time tracking and SLA give the business real data on cost-to-serve per plan.
- Seeing a client is near their quota (6/8) helps agents flag upgrade conversations at the right moment.
Admin portal · Clients
The book of business for the ops team — every client's plan, quota usage, open work and site health in one list, with at-risk accounts surfaced.
What's on this screen
- Every client with plan, quota usage meter, open requests, site status and owner.
- Health KPIs surfacing near-quota (upgrade candidates) and at-risk (site down / overdue) accounts.
- Rows link straight into that client's requests and their site's report.
Why it changed
- No concept of a client record exists today — the team can't see who's near quota or whose site is down.
- "Near quota" is a live, honest upsell signal; "at risk" is a churn early-warning.
- A single owner per account makes accountability and CSM hand-offs clear.
Super admin · Business overview
The owner's view of the business: recurring revenue, growth, churn and where requests are coming from — the numbers that actually run a subscription company.
What's on this screen
- MRR, active subscriptions, churn and ARPU — the headline health metrics, with month-over-month deltas.
- An MRR trend chart, a plan-mix donut, and a live activity feed of new subs, upgrades and cancellations.
- Everything is real business data, drawn from Stripe + the request system.
Why it changed
- There is no business-level view today; the owner can't see revenue, growth or churn anywhere.
- Plan mix and ARPU inform pricing decisions and where to focus the funnel.
- The activity feed doubles as an early churn signal and a celebration of wins.
Super admin · Subscriptions
Every subscription in one place with its billing state — including the ones that need attention, like a failed payment in dunning.
What's on this screen
- All subscriptions with plan, MRR, status, start and renewal, filterable by billing state.
- A past-due row highlighted with its dunning retry count — the recovery workflow made visible.
- Status counts up top and one-click export for finance.
Why it changed
- Billing today is a single-account demo with a test card; there's no way to see the book of subscriptions.
- Failed payments are the quiet killer of subscription businesses — surfacing dunning recovers revenue.
- Owner can comp, refund, pause or change any plan from the row (write actions gated to super admins).
Super admin · Users & admins
Control over who can do what — inviting and role-scoping the internal team, and managing customer accounts, with a clear permission model.
What's on this screen
- A team roster with each admin's role, scope and status, plus an invite flow.
- A second tab for customer accounts (search, impersonate for support, suspend).
- A plain-language permission matrix for the three roles: Agent, Admin, Super admin.
Why it changed
- The current app has a single undifferentiated login — no roles, no team, no least-privilege.
- Agents should only see their work; refunds and role changes must be limited to the owner.
- Invitations and an audit of "last active" are basic security hygiene for a system holding customer sites and billing.