Skip to content
SemCue

Art Quest · Horror Cinema · MORPHEUS

Close it once.It closes everywhere.

For a three-brand company, money lived in one system, deals in a second, tasks in a third and server health in a fourth. Every morning the head of the company toured every one of them and built the day by hand. We built the command centre: a macOS app that pulls 15 sources into a single day plan. A “done” mark passes through a ledger and a delivery queue, then closes the item in Asana, and after that in the day plan and the CRM.

In daily use · since 10 October 2026 · figures as of 29 October

Close it once

  1. 1 · MarkA chat or a screen

    You tell an assistant in a chat that it is done, or tick it in the app.

  2. 2 · LedgerThe done ledger

    The closure is written to the queue on disk. Quit the app mid-action and anything undelivered goes out at the next start.

  3. 3 · QueueDelivery with retries

    It sends every 20 seconds. If that fails, it waits 30 seconds, 2 minutes, 10 minutes, an hour, then 6 hours each time.

  • AsanaTask closed
  • Day planItem cleared
  • CRMDeal step closed
248 of 248
closures delivered, 0 lost
5.5 s
average time to confirmation
2
needed a second attempt

Mornings began with a tour of systems

Mornings began with a tour. The till and payouts sat in one system. Deals in the CRM. Tasks in Asana. Server health in monitoring. Then mail, the calendar and client chats. Each system answered one slice of “what do I do today”.

Closed items were the worst part. A task was marked done in a chat, yet Asana still showed it. The day plan was rebuilt and the item came back the next morning. The head of the company closed the same thing twice.

We moved everything into one place. The command centre reads the sources itself, turns them into cards and keeps a single day plan. A closed item does not return to the plan.

The day plan in the app: focus of the day, results, time windows and an hourly schedule
One day plan instead of a tour of systems. Demo data. Interface translated for this page.

Before

  • A tour of every system each morning
  • Closed in a chat, still open in Asana
  • Items return when the plan is rebuilt
  • Money, deals, tasks and servers in four systems

After

  • 15 sources in one day plan
  • One mark closes the item everywhere
  • Finished work is never suggested again
  • Thousands of signals filtered into hundreds of action cards

Close it once

The core idea is simple. You mark an item done in one place and the system does the rest. The mark goes into the done ledger, and from there into a delivery queue.

The ledger keeps marks for 14 days, up to 300 entries. It also stops the day plan from suggesting finished work again. If a rebuild rewords an item, the mark still finds it by its link and shared words.

  • 248 of 248closures reached Asana0 lost and 0 rejected
  • 241 of 248delivered within 10 seconds247 of 248 within a minute
  • 0.8 son average at the first attemptoverall average 5.5 s
The diagram above shows the path of one closure. Figures: 19 to 29 October 2026.

What the queue does when the connection drops

Asana does not always answer. The network drops, the service asks you to wait, a laptop lid closes mid-action. A closure that “left but never arrived” is worse than a manual one, because nobody knows it was lost.

So a closure is written to the queue on disk: when a CRM deal task is closed, the queue entry and the local change are saved in one transaction. The queue sends closures at start-up, after every action and every 20 seconds. Over 11 days (19 to 29 October) it sent 248 closures. Two needed a second attempt. The other 246 arrived first time.

  • Queue on disk

    Closing a deal task and its delivery job are saved in one transaction. Closures not yet sent stay in the queue on disk and go out at the next start.

  • Retries without duplicates

    A closure sets the state to “done” rather than pressing a button. Sending it twice cannot break the task. Before a retry the queue reads what Asana already shows.

  • Growing pauses

    Retries run after 30 seconds, 2 minutes, 10 minutes, an hour, then every 6 hours. After 12 attempts the closure is marked undelivered.

  • Failure shows

    On the Today screen a badge counts closures waiting for confirmation and those Asana rejected. A closure does not vanish silently.

  • 39closures on 26 October
  • 102closures on 27 Octoberthe peak of the period
  • 0closures lost on either day
At the peak, 101 of 102 closures reached Asana within 10 seconds. After that: 22 closures on 28 October and 8 by the evening of 29 October.

11,229 signals become 548 action cards

Sources are noisy. A server blips, a payment lands, a till total does not match, an email waits for a reply. In three weeks, 9 to 29 October, the command centre accumulated 11,229 signals from 11 sources (the earliest events are dated 14 September). Nobody can read that in order.

It merges repeats and duplicates into episodes and shows one card with its history. 1,786 signals landed in 548 action cards, and noise rules hid another 9,443: they stay visible under “Quietly hidden”. Of the cards, 327 are closed, 217 open and 4 dismissed.

  1. 11,229signals

    Server faults, payments, tasks, mail, till mismatches. 9 to 29 October.

  2. 548action cards

    1,786 signals merged into cards with history, 9,443 hidden by noise rules.

  3. 327closed

    217 open, 4 dismissed.

Where signals come from

  • 7,911server monitoring
  • 1,611money
  • 724tasks
  • 545payroll
  • 264cash desks
  • 98mail
  • 35payments and ads
  • 41bridge, reconciler, work board
Signals as of 29 October 2026. Bar widths are proportional to the numbers.

Server monitoring sends the most signals, 7,911: 70% of the stream. Of these, 42 landed in cards and the rest were hidden by noise rules.

Chat assistants see the same plan

Assistants in chats plug into the command centre. Before new work, an assistant checks whether it has already been done. When it starts, it leaves a trace on the work board. When it finishes, it closes the day-plan item and the Asana task.

The command centre offers chat tools for this. One call closes up to 20 Asana tasks. The assistant reads open tasks from a local copy that refreshes every 2 minutes, so reading never calls Asana.

Another check runs on the plan itself. After every day build, an AI model compares each unfinished item with the facts: has the client replied since the step date, has the payment arrived, is there a mark in the ledger. A finished item is marked done, and items tied to an Asana task get a note.

  • Find

    Never twice

    Before starting, the assistant searches the board and the day plan for similar work and reads open Asana tasks from the local copy.

  • Leave a trace

    Every stage visible

    Started, blocked, done: a short comment on the work-board card.

  • Close

    No tour of systems

    One call queues up to 20 Asana tasks for closing and writes to the done ledger; the day-plan item closes once Asana confirms.

14 screens and three weeks of figures

The app has 14 screens: overview, today, tasks, decisions, done, money, systems, assistants, bridge, journal, sources, geo reports, CRM and checked. A small CRM inside holds deals, payments and the next step for each client.

The command centre also tracks the company’s numbers. From 9 to 29 October it gathered 42,502 points across 32 indicators and saved 115 reports.

The sources screen: 15 data sources with status, last request time, data age and coverage
Freshness of every source at a glance. Demo data. Interface translated for this page.
  • 42,502metric points32 indicators, 9–29 October
  • 115saved reports
  • 14days of marks in the done ledger
  • 1 h 10 minthe “Sales” mini-CRM plus loading 20 deals into it13 October, 11:35–12:45 Tashkent time
  • about 2 hthe done ledger, the closure check and two new sources16 October, payroll and chats
Build time from the estimates log: 13 and 16 October 2026.

How it was built

Built one loop at a time

By 10 October money, deals, tasks, the work board, server health, payments and ads, and the calendar and capacity were running on live data. Cash desks followed on 15 October, payroll and chats on 16 October.

The mini-CRM with its first load of deals took 1 hour 10 minutes; the done ledger, closure check and two sources took about two hours. On 19 October the delivery queue replaced direct sending to Asana. The head of the company has worked in it every day since 10 October.

  • Head of the companyDecides which sources matter and what counts as closed. Uses the app every day.
  • SemCueThe app, source collection, ledger, delivery queue and chat tools.
  • Chat assistantsFind work, leave traces and close items through the command centre’s tools.

For technical readers

Under the hood

App
Native macOS: Swift and SwiftUI with a local SQLite database.
Delivery
A closure queue on disk, written in the same transaction as the local change for CRM deal tasks; retries with growing pauses, up to 12 attempts.
Signals
Repeats merged into episodes, action cards, freshness per source.
For chats
A tool server: work search, board traces, the day plan, closing up to 20 Asana tasks per call, CRM.
Item check
An AI model compares unfinished items with chats, payments and the ledger after every day build.

Where the numbers come from

Sources

Next system

Our own CRM instead of amoCRM →

SemCue / Let’s talk

What would you like to work on?

Tell us about your project and what you need. A rough idea is enough.

Get in touch on Telegram

We’ll discuss your goals, where things stand and the right next step.

Discuss your project on Telegram
In developmentThis site is still being built, so things may change.