The platform
One platform. Every part of the business, connected.
Fourteen capability areas, each explained the same way: what it is, the problem it solves, how it actually works, why it matters, and the outcome a business owner sees.
Business management
- What:
- The configuration layer that turns one codebase into your business — industry, modules, branding and plan, all resolved per business.
- Problem solved:
- Generic software forces every business into the same shape.
- How:
- Your industry and plan determine which modules and terminology appear automatically.
- Why it matters:
- You never pay for or wade through tools you don’t use.
- Outcome:
- A system that looks like it was built for your business — because functionally, it was.
Customer management (CRM)
- What:
- A full record for every customer — contact info, visit history and preferences.
- Problem solved:
- Customer knowledge trapped in one staff member’s memory, or a separate app.
- How:
- Every booking, order and sale attaches automatically to the customer record.
- Why it matters:
- Any staff member can pick up where the last visit left off.
- Outcome:
- Customers feel recognised, and marketing has a real list to work from.
Staff & team management
- What:
- Roles, permissions and schedules for everyone on the team.
- Problem solved:
- Either everyone has full access, or the owner is a bottleneck for everything.
- How:
- Roles like owner, manager, receptionist, cashier, staff and accountant come with sensible default permissions out of the box.
- Why it matters:
- Delegation without giving up control.
- Outcome:
- The owner stops being the only person who can do anything that matters.
Operations (bookings & orders)
- What:
- The day-to-day engine — appointments for service businesses, orders for laundry and retail-style flows.
- Problem solved:
- A calendar that doesn’t know about stock, or an order system that doesn’t know about staff availability.
- How:
- Bookings and orders read from the same staff, resource and inventory data as everything else.
- Why it matters:
- No double-booking a chair or promising an order the shop can’t fulfil.
- Outcome:
- A schedule the whole business can actually trust.
Payments (point of sale)
- What:
- Checkout — split payments, receipts and end-of-day cash-up.
- Problem solved:
- A standalone card machine that doesn’t talk to the booking or inventory system.
- How:
- Every sale updates finance and inventory the instant it’s rung up.
- Why it matters:
- Revenue numbers are correct the moment the till closes, not after manual reconciliation.
- Outcome:
- Faster checkout and a finance report that’s already accurate.
Scheduling & appointments
- What:
- Calendar logic tuned per industry — chair scheduling for salons, a walk-in queue alongside the calendar for barbershops.
- Problem solved:
- Generic calendar tools treat every business like a meeting-room booker.
- How:
- Scheduling rules match how the industry actually operates.
- Why it matters:
- Fewer double-bookings, less front-desk juggling.
- Outcome:
- Staff time is used the way it was actually planned.
Inventory
- What:
- Stock tracking for products and consumables used in service delivery.
- Problem solved:
- Running out of a product mid-service, or over-ordering because no one has visibility.
- How:
- Inventory decrements automatically as services and sales consume stock.
- Why it matters:
- Fewer surprise stockouts, less capital tied up in excess inventory.
- Outcome:
- Ordering decisions based on real numbers, not a guess.
Reporting & analytics
- What:
- Performance visibility by location, staff member and service.
- Problem solved:
- Knowing revenue happened, but not why or where.
- How:
- Every transaction across every module feeds the same reporting layer.
- Why it matters:
- Decisions on staffing, pricing and promotions get made on data, not instinct.
- Outcome:
- An owner who can answer “how’s the business doing” with a number, not a guess.
Notifications
- What:
- Automatic reminders and status updates to customers and staff.
- Problem solved:
- No-shows and “where’s my order” calls that eat staff time.
- How:
- Bookings and order status changes trigger reminders and updates automatically.
- Why it matters:
- Fewer missed appointments, fewer inbound status-check calls.
- Outcome:
- The business feels responsive without anyone having to remember to follow up.
Marketing & customer engagement
- What:
- Tools to reach customers with the right offer at the right time.
- Problem solved:
- Customer lists that exist but are never used.
- How:
- Marketing draws directly from the same CRM as bookings and orders — no exporting to a separate tool.
- Why it matters:
- Campaigns reach people who’ve actually visited, segmented by real behaviour.
- Outcome:
- Repeat visits that didn’t require a manual follow-up call.
Automation
- What:
- Configuration-driven behaviour — reminders, plan-based feature access and role-based visibility that apply without manual setup each time.
- Problem solved:
- Re-configuring the same rules by hand for every new staff member or location.
- How:
- Rules are set once at the plan, role or module level and apply everywhere automatically.
- Why it matters:
- Consistency across a growing team without a manual checklist.
- Outcome:
- New locations and new hires inherit the right setup on day one.
Integrations
- What:
- The architecture is built to connect — third-party integrations themselves are on our roadmap, not shipped today.
- Problem solved:
- Every business already uses something outside IMELDA — a payment processor, a phone line, sometimes a spreadsheet.
- How:
- Payment, messaging and calendar-sync integrations are being built on top of the same module architecture.
- Why it matters:
- You shouldn’t have to abandon tools that already work.
- Outcome:
- Want early access when integrations ship? Reach out through Contact and we’ll keep you posted.
Security
- What:
- Data isolation and access control at the architecture level.
- Problem solved:
- Shared tools where one business’s mistake or breach can expose another’s data.
- How:
- Every business’s data is isolated, and access tokens are scoped to a single realm — there’s no cross-realm leakage by design.
- Why it matters:
- A security question a technical buyer will actually ask, answered before they ask it.
- Outcome:
- Confidence handing over customer and payment data.
Scalability
- What:
- The same platform runs one shop or a thousand.
- Problem solved:
- Growing out of your software and facing a painful migration.
- How:
- Multi-tenant architecture means new businesses and locations are provisioned, not built.
- Why it matters:
- The platform you start on is the platform you scale on.
- Outcome:
- No re-platforming conversation in year two.
Multi-location support
- What:
- One owner login across every location they operate.
- Problem solved:
- Running each location as its own silo with its own login and its own numbers.
- How:
- Reporting and staff management roll up across locations automatically.
- Why it matters:
- The difference between “running five shops” and “running one business with five doors.”
- Outcome:
- One number for the whole operation, whenever you need it.
