Winter ServicesBookings and jobs, one app
01 / 19
← → navigate · T theme · N notes · F present · P print
Web page · Android · works with no signal

An aircon shop's bookings, off Messenger and into one app.

I build apps for the way a workplace actually runs. Winter Services is one: customers book an aircon job on a web page, the office accepts, quotes and schedules it, and the technicians see every job on their phones — and everybody sees the same status.

Book online Track my booking Inbox & quotation Jobs & schedule Technician's phone Full status Three numbers

Guile Pitogo · Bacolod City, Negros Occidental
deadeyezjhin.github.io · guile.pitogo@gmail.com

book-form.png
Book an aircon jobNo account, no app to install
SpeakerOpen with what the shop gets: bookings that arrive complete, a schedule everybody shares, and numbers nobody has to count. Every slide after this is one question an owner asks.
Before

Every booking was a conversation

An aircon cleaning, repair and installation shop in Bacolod City. The shop ran on the owner's personal number and a Facebook page.

The booking

A call or a Facebook message. The address, the landmark and "which aircon?" asked one question at a time.

The schedule

In the owner's head and his chat history. The technicians were told who, where and when by message.

"Is it still on?"

The customer rang again to ask. The owner scrolled back to find the answer.

The month

No count of bookings, no idea how fast anyone was rung back, no list of whose aircon is due a check.

The rule I build by: anything that makes a person ask, retype or remember by hand is worth removing. Every screen in this deck removes one of those.
SpeakerThere was no system to replace — there was a phone, a chat and a good memory. And no customer list to import: the app starts empty on purpose.
After

Every message became a screen that does the work

A chat holds words. An app holds the job: who it is for, what is on it, whose turn it is, and when it was done.

What they did by hand
What the app does instead
"Where are you? Which aircon?" — asked over chat
→
The booking page — name, number, address, landmark, a pin, and a cart of aircons, all at once
Scrolling Messenger for today's bookings
→
The Inbox — new bookings with a count, Accept makes the customer and the job in one tap
A Word quotation typed each time
→
Quotation from the booking — his own layout, filled in, sent as a PDF
Telling each technician by message
→
Jobs on every technician's phone — with Call, Map, On the way, Done
"Is my booking still on?" calls
→
Full status — booked, accepted, scheduled, on the way, done, with who and when
Remembering whose aircon is due
→
Check-ups — a call list that fills itself, every 1 to 12 months per customer
Accounts

Three kinds of people, one app

The role on the account decides what each one sees — and the database enforces it, not just the buttons.

Customer

book-form.png
  • The web page — nothing to install
  • Books with no account; tracks with a code
  • An account shows only their own bookings

Office

office-inbox.png
  • Android app
  • Everything: bookings, jobs, customers, prices, users
  • Promotes a sign-up to technician or admin

Technician

tech-today.png
  • Android app
  • Every job that has a day on it
  • Never the customer list, never a price unless allowed
SpeakerOne HTML app behind all three. Owners ask "can a technician see my whole customer list?" — no, and it is the database that says no.
The customer

A booking that arrives complete

The page asks everything the owner used to ask on the phone — once, in order, with nothing left out.

  • A cart of aircons. Tap Window, Split, Cassette… each one gets its own services, brand and model
  • Prices as they tap, when the owner switches them on
  • The landmark, pushed hard — in Bacolod it is how a technician finds the gate. Pin the house, or pick it on a map
  • Only open days. Sundays and the owner's closed dates cannot be picked
  • A reference code back at once, like WA-7241
  • One plain privacy sentence and a tick box before it sends (Data Privacy Act)
A failed booking never looks like a successful one: the page says so, and keeps everything typed.
book-sheet.png
1 · What it needsEach aircon's services and prices
book-cart.png
2 · The cartThree aircons, ₱2,800
book-done.png
3 · The codeTo check it later
SpeakerThe link goes on the Facebook page's Book Now button and a QR on the van. A page nobody is sent to takes no bookings.
The customer

"Is my booking still on?" — answered without a call

The reference code and the number they booked with. The code is remembered on their phone, so next time it is already filled in.

Code and number

Both must match. A stranger with one code learns nothing about anyone else.

Or an account

Every booking, every step, on any phone. Bookings made before registering are added with the number and one of their codes.

track.png
Track my bookingNo login
cust-bookings.png
My bookingsWith an account
The office

New bookings, one tap to a job

The Inbox is the office's morning: every new booking with a red count, what they want, the day they asked for and what it comes to.

  • Call and Map on every booking — the landmark and the pin come with it
  • Accept makes the customer file and the job, already on the day they asked for
  • A call the owner takes goes in as "By phone", so every job lives in one place
  • Reject needs no reason typed; the customer's page says so
  • A booking from an existing customer is accepted onto their file — never a second copy of the same person
office-inbox.png
InboxNew, today, no date, check-ups
office-booking.png
The bookingEverything the customer sent
office-accept.png
AcceptCustomer + job in one tap
Speaker"Accept — new customer" under a booking from an existing customer once made a second file of the same person. Now that booking offers only "Accept — on their file". Found by the owner on his first real booking; fixed the same day.
Paperwork

His quotation, already filled in

The owner writes quotations today, in Word. The app makes his layout — letterhead, subject, the table, the note, his signature and the customer's Conforme line — from the booking.

Quotation

  • Lines and note editable, saved on the booking
  • Send as PDF to Messenger, Viber or email
  • Accept takes its total as the job's price

Receipt

  • A4, from the job, for the technician to hand over
  • GCash number printed on it
  • The office marks it Paid — cash, GCash or other
No PDF library: the phone's own print screen makes the file. Nothing extra to download or break.
office-quote.png
QuotationFrom a new booking
tech-receipt.png
ReceiptShare or print
The office

The schedule, in one place

Today, tomorrow, upcoming, no date yet, done. Morning or afternoon — not a promised minute a shop cannot keep.

  • Route — today's stops, morning first, opened in Google Maps
  • Not paid in red on every open job until the office marks it
  • A limit per morning: a full morning cannot be booked from the page
  • Closed days: every Sunday, a fiesta, a training day — with the reason the customer sees
  • Edit the day, the aircons or the price; every change is written into the job's history
office-jobs.png
JobsToday, three stops
office-closed.png
Closed daysThe page refuses them
In the field

Every job on the technician's phone

A small shop, not a dispatch centre: every technician sees every job with a day on it, and the owner often rides along. Whoever presses the button is written down.

  • Call the customer, Map to the pin, the landmark in big letters
  • On the way — the customer's page says so
  • Start, Mark done, and Undo — an undo is a step in the history, never a silent rollback
  • A gate photo for next time, and the price to collect when the owner allows it
  • No signal at the house? It still works. Changes wait and send themselves
tech-today.png
TodayThree stops, with the route
tech-job.png
The jobCall, map, done
Speaker"No assignment" was the owner's decision: a technician picker is a screen a three-person shop would never use.
Everyone sees the same thing

Full status, everywhere

The same five bars on every booking and job — for the office, the technician and the customer — and underneath, every step with who and when.

Customer

Booked

on the page, or by phone

→
Office

Accepted

seen, then accepted

→
Office

Scheduled

a day, AM or PM

→
Technician

In progress

on the way, started

→
Technician

Done

then paid

An edit says what changed — "Split #2 added", "Day Thu → Fri". The customer sees the steps and the names; a price only if the owner shows prices.
office-job-status.png
The office's viewWho did what, and when
cust-status.png
The customer's viewThe same steps
Repeat business

Every customer's aircons, and when they are due

A customer file is made when a booking is accepted — never straight from the public page. It keeps their aircons, their jobs and their bookings.

  • A regular check per customer: every 1, 2, 3, 6 or 12 months from a chosen date
  • Check-ups is the owner's call list. He rings; Book it makes the job
  • A week after the job: "is it working well?" — All good, or book a visit
  • Customers on a map, and Book again from any past job
  • Delete a customer for real — every phone forgets them (the privacy law's right to be removed)
No SMS and no automatic reminders: the owner calls. A message nobody reads is cost, not value.
office-customer.png
A customer's fileRegular check, their aircons
office-checkups.png
Check-upsThe call list
What it is for

Three numbers, nobody counting

The app was built to answer three questions from its own records. A screen that moves none of them was not built.

1
Bookings through the page, per week

Against the calls and messages it replaces. Phone bookings are kept out, so the number stays honest.

2
How fast the office rings back

From the booking to the office's first action. Measured first, judged later.

3
Done on the day promised

The job keeps the promised day and when it was really done, or this could never be answered.

Plus a month's takings by cash, GCash and other, exported in one tap.
office-numbers.png
Admin → NumbersAn invented month
SpeakerThis is the slide for owners: the app pays for itself only if these move. Deciding them first is also what kept the app small.
No developer needed

The owner changes it himself

Everything a shop changes month to month is a screen in Admin, not a phone call to me.

  • Services & prices — one price per service per appliance; a new service shows on the page at once
  • Appliances — aircons, freezers, washing machines; his own picture for each; hide one without losing its history
  • Two switches: show prices on the booking page; show prices to technicians
  • Page photos, closed days, the shop's GCash, his quotation and receipt
  • Users: anyone signs up; the owner makes them a technician or an admin, or switches them off
office-prices.png
Services & prices
office-appliances.png
Appliances
office-users.png
Users
Security

A public page, and nothing public behind it

The booking page's key to the database is public — anybody can read it from the page. So the whole design assumes a stranger holds it.

A stranger with the key

Can do three things

Send a booking · look up a booking they have the code and number for · read the service list

→
The database

Three functions, no tables

No read of any table. Not customers, not jobs, not the team — not one row.

→
Staff

Signed in, by role

What an account may see is a database rule, checked on every request.

Proven, not promised

A test runs as the stranger and tries to read every table. Every read must be refused — it runs after every change to the database.

Public input is untrusted

A booking never becomes a customer on its own. A person in the office accepts it first. A hidden trap field catches bots; one booking a minute per number.

Privacy law

Name, number and address are personal data (RA 10173): one plain sentence before sending, and the owner can remove a customer completely.

SpeakerThis is the one rule whose breach could not be undone — the key is public the moment the page ships. So it was designed first and tested before anything else was built.
Works offline

A dead zone at the house loses nothing

Every screen reads the phone's own copy. A change lands on the phone first and waits in a queue; the network is a bonus, never a condition.

At the house

Mark done

No signal. The job says Done on the phone at once.

→
On the phone

"1 waiting"

The change is kept, even if the app is closed.

→
Signal back

Sent by itself

The office and the customer see Done. Nobody taps anything.

Two phones, one job

If the office and a technician change the same job, the loser is told what happened — never silently overwritten.

The page opens offline

Once opened, it opens again with no signal. Only the shop's own page is kept — never the data.

Updates itself

The Android app says when a new version is out and installs it, with what changed in plain words.

How I work

I decide what it is for, then build only that

The three numbers came first. Everything else had to move one of them, or wait.

1
Ask the owner

Eleven questions before a line of code. One phone call settles more than a week of guessing.

2
Safety first

The public key's limits were built and tested before the page existed.

3
Test the real thing

On a phone width and a PC width, with made-up data — never a real customer's.

4
Ship with notes

Every version says what changed, in words the owner uses.

What I chose not to build is part of the work. Invoices, parts and stock, SMS, push notifications, email updates, customer ratings and photos from customers were all considered — and parked, because each would open to an empty screen on day one. A screen nobody opens is cost, not value.
19
Builds shipped
30
Database changes, each tested
1.8 MB
Android app
₱0
Running cost
Speaker₱0: GitHub Pages and the free database tier. A free database sleeps after a quiet week, so a small scheduled ping keeps it awake — a paused database would mean a customer's booking failing silently.
Hiring a virtual assistant?

Every screen here is a job I know from the inside

I built the tool that does each of these for a real shop — so I know every step, and where the numbers go wrong.

Invoicing & quotations

A quotation from each booking, the accepted total as the price, a receipt with discounts and paid or unpaid. Slide 8 →

Booking & scheduling

New bookings accepted onto the right day, a limit per morning, closed days, every change in the history. Slides 7 & 9 →

Dispatch

Each technician told where, when and what — with the landmark, the pin and a route for the day. Slide 10 →

Customer follow-up

"Is it still on?" answered by a status page, and a call list of whose aircon is due a check-up. Slides 11 & 12 →

Reports

Three numbers the owner runs the shop by — counted for him, never by hand. Slide 13 →

Clear notes

Every change written down in plain words the owner uses — 19 versions, each with its notes. Slide 17 →

SpeakerFor a team hiring a VA rather than an app: the work behind each screen — quoting, invoicing, scheduling, dispatch, follow-up — is work I can do by hand in your own tools, because I had to understand every step to build it.
Winter Services

Tell me how your bookings arrive — I'll show you what one app can take off your hands.

Aircon, plumbing, pest control, a laundry, a clinic: anyone who books a visit, sends someone, and gets asked "is it still on?" has the same lists — and the same fix.

Guile Pitogo

  • Bacolod City, Negros Occidental
  • guile.pitogo@gmail.com

More work

  • deadeyezjhin.github.io
  • SukiRun — orders for a distributor's field agents
  • deadeyezjhin.github.io/sukirun-deck

Try it

The demo and every screenshot use invented customers, invented numbers and invented jobs, answered by a pretend server inside your browser. No real customer, address or booking appears in this deck, and nothing you do in the demo leaves your browser. App icons by Flaticon.