The whole operation, running in one system

A live-performance company that produces and stages shows and runs a teaching studio. Its operations used to live in WhatsApp and across a dozen disconnected tools. DataWise rebuilt that operation onto a single operating system: one place where the work, the money, and the schedule all live, most of it moving on its own. It is live and in daily production use.

This is not a “we set up some boards” story. It is a business-operations transformation, and this page tells it the way the system itself is built: honestly, with the quality controls in view.

What was actually broken?#

The company ran on WhatsApp as its de-facto ERP. Task tracking, approvals, scheduling, and money decisions all happened in chat threads across more than a dozen fragmented tools and spreadsheets: a scheduling system, a ticketing tool, a registration app, a design tool, drive folders, e-mail, and the rest.

The cost of that was concrete. A grant deadline was missed because nothing existed to escalate it. Operational knowledge walked out the door when staff left, because it lived in people’s heads and their chat history, not in a system. And the whole operation funnelled through a single person; if she was unavailable, visibility went with her.

None of this is unusual for a growing operation. It is what “we’ll organize it later” looks like a few years in. The company decided later had arrived.

What replaced it?#

One operating system, built on Monday.com for the work surface and Make.com for the automation layer underneath it, with around thirty automation scenarios organized into six functional workstreams. The point was never the number of boards. The point is that the operation now runs as one connected system instead of a dozen disconnected ones.

Three things make that real rather than cosmetic, and each is a value in its own right.

Recurring work creates and files itself. The daily operation lives on a single “breathing” board. Every task, lesson, rental, and production window lands there as an item with its own checklist. Recurring work is not typed in by hand each day: it spawns automatically on daily, weekly, and monthly cadences, and a routing engine moves each item into Today, This Week, Upcoming, or Overdue as its date approaches. Calendar events flow in and are tagged and turned into tasks by a keyword dictionary, so the schedule and the task list are the same thing rather than two systems someone has to reconcile.

The books are semi-automated, end to end. This is the piece we are proudest of. Money enters the system once, at the source, and flows upward on its own into a single monthly view. We cover it in its own section below.

The automations watch themselves. Any system that runs thirty automations will eventually have one fail. So the build includes a dedicated automation-control board: every scenario’s health, its faults by severity and type, and the status of each fix, all on one screen. That is observability, built in from the start rather than bolted on after the first silent failure.

How does the money actually move?#

Payroll and payments used to be a monthly reconstruction job across spreadsheets and chat. Now they are a chain. Three streams enter at the bottom, at the point where the real-world event happens:

• Performer attendance. Each rehearsal, show, or accompanist session is logged once. Hours are computed from entry and exit times; a show counts as a unit (and as 1.5 on a Sabbath); an accompanist session counts at a fixed rate. The pay row builds itself from those events.
• Teaching. Lessons arrive automatically from the studio’s scheduling system, pulled on a schedule several times a day. A person’s only job is to confirm attendance; the moment a lesson is marked verified, that teacher’s pay recomputes instantly, including a higher rate band for larger classes.
• Supplier invoices. Each invoice is entered once as a row and flows straight up.

All three streams roll into one monthly board, one row per payee per month, which is the single surface where payment status is tracked: payment-requested, receipt in, paid. That single view is the whole point. There is one place to answer “who do we owe, how much, and what have we already paid.”

Two engineering choices make this trustworthy. First, rates are frozen at the moment each month’s pay row is created. Change a rate later and history does not silently rewrite itself; each past month keeps the rate that was actually in effect. Second, the chain is deliberately semi-automated, not fully automated: a human confirms the source event, and a manual override is always available and clearly flagged when used. The machine does the arithmetic and the plumbing; the person keeps the judgment. For anything that touches money, that is the correct division of labour.

What did it take to get it right?#

Two things worth naming, because they are the difference between a demo and a system that runs.

Partway through, we changed the architecture. The first design connected many boards together; in use, it was heavier than the operation needed. We rebuilt around a single “breathing” daily-ops board with the reference data behind it. Rebuilding your own design mid-engagement is not a setback; it is what engineering judgment looks like when the goal is a system someone will actually live in every day, not a diagram that demos well.

And we migrated two years of real operating history into the new structure, so the system launched with the company’s past already in it rather than starting empty. One click still spawns a complete production as a ready-to-run checklist across every track (marketing, logistics, cast, sales, finance, and post-show), so a new show starts fully planned instead of from a blank page.

What this looked like#

This is a real production system, not a mock-up, and client confidentiality bounds what we can show: company and people, venues, production names, and every currency figure stay out of anything we publish. We publish no invented metrics for this engagement, here or anywhere on this site; the figures we do state (a dozen-plus tools replaced, roughly thirty automation scenarios, two years of history migrated, three payment streams into one monthly surface) are structural facts about what was built, not performance claims.

FAQ#

Is this just a Monday.com setup? No. Monday.com is the surface people touch. Underneath it is an automation layer of around thirty scenarios, live integrations with the company’s calendar and scheduling systems, a semi-automated payment chain, and a control board that monitors all of it. The value is the operating system, not the boards.

What happens when an automation breaks? It surfaces on a dedicated control board, classified by severity and type, with the status of the fix tracked to closed. Failure monitoring was designed in, not discovered later.

Is the accounting really automated? Semi-automated, on purpose. Events are logged once at the source and the totals build and roll up on their own, but a person confirms every source event and can override any figure, with the override clearly flagged. On money, judgment stays with the human.

What if the person who runs it leaves? That was the original risk. The whole point of moving off WhatsApp and people’s memory is that the operation now lives in a system, with two years of history in it and the recurring work defined once rather than re-remembered daily.

What would this look like for your company?#

If your operation lives in WhatsApp, spreadsheets, and a handful of tools that do not talk to each other, the starting point is a scoping conversation: where the work, the money, and the schedule actually live today, and what it would take to make them one system instead of a dozen.

We build it the way we built this one: live, in production, with the automations watching themselves and the judgment left where it belongs.