From Missed Calls to Confirmed Bookings - Cowork Admin Assist App

Dinithi De SilvaJuly 13, 20264 min read
From Missed Calls to Confirmed Bookings - Cowork Admin Assist App

I spent an afternoon last month watching the front desk at a coworking space in Pannipitiya, and I can tell you exactly where bookings go to die: a sticky note.

The phone rings. Someone wants the 4-seater meeting room on Thursday afternoon. The agent writes "Thurs 2pm - 4 seater - Kasun - 0771..." on a Post-it, promises to call back, and gets interrupted by a member who can't connect to the WiFi. The note migrates under a coffee cup. Maybe the booking happens that evening. Maybe it happens the next morning, after Kasun has already found another room somewhere else.

Nobody at that front desk was being careless. The problem is that "take a booking over the phone" is secretly six jobs: check availability, create the booking, create the customer record, raise an invoice, generate a payment link, and get that link to the customer. Each one lives in a different tab. The sticky note is just the queue.

So we built an app that does the six jobs. It was designed for Cowork.lk, the coworking space in Pannipitiya, and it runs on the Google Pixel 7 Pro that sits at their front desk.

What Cowork Admin Assist actually does

Cowork Admin Assist is a Flutter app that lives on the front-desk Pixel. On Android, it registers as the device's call-screening service, which means it knows two things the moment a call happens: the caller's number, and when the call ended. The instant the agent hangs up, the booking form appears with the phone number already filled in.

If that number has booked before, the customer's name and email fill themselves in too. This sounds like a small thing until you've watched an agent ask someone to spell "Wickramasinghe" over a bad connection for the third time.

The form itself talks to the same backend that runs the cowork.lk website, so availability is live. When the customer asks "is Thursday afternoon free?", the agent is looking at the actual answer, not a guess. Half-day pricing shows up as separate morning and afternoon options, sold-out slots simply can't be tapped, and add-ons like projectors and extra data are right there with prices.

Then one tap does the rest. The server creates the booking, finds or creates the customer in Zoho Books, raises the invoice, and returns a payment link. The customer gets an email automatically. The agent gets a button that opens WhatsApp with the message already written: booking summary, total, Stripe checkout link. They read it over, hit send, done. The whole thing takes less time than writing the sticky note did.

One detail we fought for: if the internet drops mid-submission, nothing is lost and nothing errors out. The booking is saved on the device first, before any network call, and a background worker syncs it when the connection returns. The agent sees "saved offline, will sync" and moves on with their day. There's some genuinely fussy engineering behind that: the sync queue uses database-level claims so a booking can never be submitted twice, even when two sync attempts race each other. The agent never sees any of it, which is the point.

There are no logins, by the way. Front-desk devices are shared, and asking someone to log in while a customer is on hold is how you end up with everyone using the same password on a sticky note (see above, re: sticky notes). Instead, every submission just records the agent's name. Simple, auditable, no friction.

A note on iPhones, because someone always asks: iOS doesn't let apps see who's calling. Not "it's hard". Apple simply doesn't expose it, for privacy reasons that are honestly fair. So on iOS the agent taps "Log Call" after hanging up and the flow is otherwise identical. We'd rather be upfront about a platform limit than fake a feature.

The part I'm actually excited about: on-device AI

Watch an agent use the app for a day and you notice the last piece of manual work left. The customer says "Thursday afternoon, the 4-seater, and can I get a projector?", and the agent turns that sentence into taps. Space dropdown, date picker, slot chip, add-on checkbox. The translation from speech to form is still human labour.

That's the piece we're working on removing, and the interesting part is where the AI runs: on the phone itself.

The plan is straightforward. Right after the call, the agent records a five-second voice note ("Thursday 2pm, 4-seater, projector, for Kasun") or, with consent, the app transcribes the agent's side of the call directly. A small language model running on the device pulls out the structure: which space, what date, which slot, which add-ons, the customer's name. The form arrives pre-filled and the agent's job becomes checking it, not typing it.

Why insist on running the model on-device instead of just calling a cloud API? Three reasons, and the first one is the one that matters.

It's a phone call. Sending recordings of customer calls to a cloud transcription service is the kind of thing that's technically fine with the right consent checkboxes and still feels wrong. With on-device models (the current Android generation, including the Pixel 7 Pro, runs Gemini Nano through AICore) the audio and the transcript never leave the phone. The only thing transmitted is the same structured booking request the app already sends today.

It also works offline. The app was built offline-first from day one, and cloud AI would quietly break that promise. On-device inference means the voice-to-booking flow works during a connectivity blip and the extracted booking just joins the same sync queue as everything else.

And it's fast in the way that matters here. No round trip, no rate limits, no per-call API cost on something that happens forty times a day.

Further out, the same model can draft the WhatsApp message in the customer's own language, or nudge the agent that the caller asked about monthly rates and might want to hear about memberships. Small things. But front-desk work is made of small things.

We're not trying to automate the human out of the front desk. The person answering the phone is doing something a model can't: being the reason someone books with you instead of the place down the road. We just want the paperwork to stop competing with the conversation.

Where it stands

The app is running on real hardware against the live booking platform: call detection, offline queue, Zoho invoicing, Stripe links, WhatsApp handoff, all of it. The on-device AI layer is next.

If your business has phones that ring and bookings that leak, this pattern travels well beyond coworking. Come talk to us.