Art Quest · Horror Cinema · MORPHEUS
The weekly packagein 7 minutes.
Three brands, two sites: CRM, bookings, payments, websites and Avito. The week’s data used to be gathered by hand. Now a server does it. At 03:30 Tashkent time every Monday it pulls 20 sources, checks completeness and seals the package with a hash. A language model writes the conclusions, and code calculates every number.
Running · three scheduled Mondays in a row: 12, 19 and 26 October 2026
Monday, 03:30 Tashkent time
- Collect20 sources
- CRM full pull
- bookings and calendar
- payments and refunds
- Metrica and search
- Avito and bots
- CheckCompleteness
- 3 critical: no package without them
- 17 optional: a failure is PARTIAL, not zero
- PackageSHA-256 hash
- immutable snapshot of the week
- Drive gets summary files and a manifest
- read back to verify the hash
- 06:00Conclusions
- a language model reads the package
- code has already done the maths
- ResultThe manager
- week against last week and year
- what slipped
- what to check
03:30 → 03:37: the first scheduled package was ready in 7 minutes
- 7 minfrom start to a finished packagefirst scheduled run, 12 October; 19 and 26 October: 3–6 minutes
- 20sources in one packageCRM, bookings, payments, Metrica, search, Avito
- 3 of 3Mondays in a row assembled by the timer12, 19 and 26 October, no manual start
- 80 minthe full analysis of 19–25 October, on top of a finished packageinstead of hunting for data: funnel, websites, Avito, money, checks, letters
Monday, 03:30. Nobody presses a button
At 03:30 Tashkent time a timer fires on the server. In Omsk it is 04:30 and the business week is closed. The server collects data for two sites and three brands and builds the weekly package.
The first scheduled run took place on 12 October. From start to finished package took 7 minutes, 03:30 to 03:37. The next day we checked the result: the package was in Google Drive and the run was logged in the sheet. On 19 and 26 October the packages reached Drive the same way, with no manual start, 3–6 minutes after the timer fired.
Before
- The week’s data pulled by hand from different systems
- Assembling 5–11 October and eight weeks by hand on 13 October took about 62 minutes
- About half of that time went on finding the data
Now
- A timer builds the package on Monday at 03:30
- The package is ready in 7 minutes
- Every week is stored as its own hashed package
- The comparison with the previous week is already inside the package
- The full analysis of 19–25 October took about 80 minutes, on top of a finished package
Twenty sources in one package
The package covers 20 sources. Three are critical: a full CRM pull, the booking store and the calendar. Without any one of them, no package is released. The other 17 add the context around sales.
Monday, 03:30 Tashkent time
- Collect20 sources
- CRM full pull
- bookings and calendar
- payments and refunds
- Metrica and search
- Avito and bots
- CheckCompleteness
- 3 critical: no package without them
- 17 optional: a failure is PARTIAL, not zero
- PackageSHA-256 hash
- immutable snapshot of the week
- Drive gets summary files and a manifest
- read back to verify the hash
- 06:00Conclusions
- a language model reads the package
- code has already done the maths
- ResultThe manager
- week against last week and year
- what slipped
- what to check
03:30 → 03:37: the first scheduled package was ready in 7 minutes
- Critical · 3
Sales
CRM is pulled in full, not by recent changes. Next to it sit the booking store and the calendar.
- Optional · 17
Money
YooKassa payments and refunds: what was paid and what was returned in the week.
- Optional · 17
Websites and search
Metrica, extended Metrica, the search console, site events and tagged links.
- Optional · 17
Avito and bots
Six Avito streams: listings, chats, statistics, calls, daily account totals, balance operations. Plus bots and the experiment registry.
A gap is flagged, never drawn as zero
Say a source does not answer overnight. A plain spreadsheet would show a zero in its place, and the week would look like a disaster. The package does not do that.
Each of the 17 optional sources gets a coverage flag: fresh or PARTIAL. PARTIAL means “the source did not answer or its data is stale, and you can see it”. No zero appears in its place. The finished package records which sources are fresh and which are not.
- Coverage
A flag instead of zero
An optional failure lands in the warnings and the coverage map. A critical failure stops the package.
- Seal
SHA-256 hash
The finished package gets a checksum. A rebuild reproduces it. The file in Drive is read back and the checksum compared.
- Delivery
Aggregates only
Drive receives a copy built only from allowlisted files, plus a manifest. It holds no chats, bookings or customer identifiers.
A language model is set up for the conclusions: at 06:00 Tashkent time it reads the finished package. It has nothing to calculate, because code has already done that. The automation takes the package for the current full Omsk week. If it is missing or conflicting, it returns a “not ready” status and does not substitute last week.
What the report found in a single week
Take the week of 19 to 25 October. The report compared it with the week before and with last year and pointed out what had slipped. It linked the cinema branch’s slump to a failure of the booking form on iPhone.
Cinema branch: 14 events against 23. From 19 to 23 October the website booking form did not submit from iPhone. Self-service bookings from the site 3 against 12. Fixed on 23 October.
- Week total
27 events against 32
Over four weeks: 113 events, 27% more than the previous four and 12% more than a year ago. The value of CRM deals is up 16% on last year.
- VKontakte
10 inbound against 64
Inbound messages in the VKontakte community over the week. Deals tagged as coming from the bot: 0 against 7. The report put the bot on the week’s checklist.
- Search
Google clicks: 4 to 21
The children’s birthday page got a new title. Over 12 days (10–21 October against 18–29 September) Google clicks rose from 4 to 21 and the position moved from 10 to 6.
- Halloween
18 bookings against 26 or more
18 bookings are confirmed for 26 October to 2 November. A year earlier the CRM held at least 26 for the same dates by 26 October, and at least 21 on a like-for-like weekday basis.
- 35enquiriesagainst 50 the week before
- 25confirmedagainst 35
- 71%of enquiries reach confirmationagainst 70%
- 27%cancelled by event date10 of 37; it was 30%
The week on the desks: what the report answers
The report has nine sections. Each answers its own question.
The week of 19–25 October on nine desks
- What was doneWhat did customers see and what are we trying?
- Funnel and bookingsHow many came, how many confirmed, where do cancellations fall? How does it compare with 8 and 4 weeks and with last year?
- Websites and searchWhere do visits come from, which pages grow or fall, does online booking work?
- Avito and platformsWhat did promotion and aggregators deliver?
- MoneyHow much cash and non-cash, which payments, what is the cash forecast?
- LandlordsWhich figures and which letter to prepare? A draft, sent by a person.
- HypothesesWhich checks have come due? 23 board rows and 4 calendar rows.
- VKontakteWhat about VKontakte advertising and enquiries?
- Yandex WebmasterHow do the sites’ pages look in Yandex, and does it agree with Metrica?
The report prepares landlord letters as drafts. A person sends them.
The 04:30 snapshot and a fresh cut
The package is built at 04:30 Omsk time. Managers close Sunday’s deals later. The first package, for 5–11 October, was missing 8 completed deals.
We added a second step. The final report is calculated on a fresh cut once the week is closed. The report for 19–25 October uses the CRM as at Monday, 19:10 Omsk time. By then managers had closed every event of the week.
The package gives the base of the week within minutes. The fresh cut adds the final figures once deals are closed.
How it was built
From manual assembly to a timer
It rests on a weekly reporting standard: source-aware comparison of weeks and search, CRM, bookings and payments kept apart, data coverage and a short report for the manager. Collection, checking and conclusions are separate. The collector invents nothing: it pulls the data, checks it and seals it.
Before the first live Monday, the whole chain ran on a protected copy of the database. Sources were read for real, while Drive and sheet writes were simulated. All 12 phases finished in 98.6 seconds.
- The companyWhich questions matter every week, who reads the report, which decisions it must support.
- SemCueThe data collector, completeness rules, hashed package, delivery to Drive and the sheet, the timer and the report structure.
- Language modelReads the finished package and writes conclusions. Code calculates the numbers.
For technical readers
How it is built
- Schedule
- A systemd timer on Mondays at 03:30 Tashkent time. Business weeks follow Omsk time; delivery follows Tashkent time.
- Collector
- Python. Three collection services write to the database under one lock; the weekly job waits for it up to 20 minutes. Service limit: 60 minutes.
- Coverage
- 3 critical sources block the package; 17 optional sources get FRESH or PARTIAL.
- Package
- An immutable weekly snapshot and a safe Drive copy built from an allowlist: aggregate files and a manifest. SHA-256 hash, read back and compared.
- Conclusions
- A language model is set up to read, at 06:00, the package for the current full week. If it is missing or conflicting, the automation returns a “not ready” status.
Where the numbers come from
Sources
- The collector’s status log and the report on the first scheduled run of 12 October 2026, checked on 13 October.
- The timer status and run log on the server, read on 29 October 2026.
- The collector’s source code: the list of sources, completeness rules, schedule and rehearsal phases.
- The weekly report for 19–25 October 2026 and its comparisons with the previous week and last year.
- The time log: manual weekly analysis on 13 and 26 October 2026.
Next system
Command centre: a company’s day on one screen →