Requests: a single inbox
A visitor rarely leaves a request where you expect it: one fills in a popup, another taps "call me back", a third books a service, and a fourth simply writes into a form on the site. Each of those channels used to live in its own corner of the panel, and the stream as a whole was visible nowhere. The Requests section puts them into one list.
Open: Admin panel → Requests (admin.cenaly.com/leads, the "Work" group in the sidebar). The section deliberately has no toggle: it exists precisely for the people who would otherwise never find it.
Requests are not Orders. A guest's order with items and payment lives in its own section with an operational flow. Here you get enquiries: a popup subscription, a form answer, a callback request, a service booking, a table reservation.
What lands in Requests#
| Channel | Where it comes from | Where it is handled |
|---|---|---|
| Popups & forms | popup leads and their form answers | "Popups and forms" in site widgets |
| Site forms | storefront form submissions | the location's website settings |
| Site messages | the contact form | the same place |
| Callbacks | the Callback widget | Customers |
| Appointments | online service booking | Appointments |
| Table bookings | a table reservation | Tables |
Rows are assembled at read time, from the very data the profile sections own. Nothing is copied or duplicated: Requests is a window over six channels, not a seventh storage.
What you need to start#
| What | Why |
|---|---|
| At least one location | the top-level split of the list is the location; one location = one of the owner's companies |
| Channels switched on | a request has to come from somewhere: site widgets, storefront forms, callback, online booking, table bookings |
| A role with section access | the section is meant for the owner and the marketer; access is configured in Employees |
Paid features live on the channels, not on the section: the "Popups and forms" widget is an extension in the app store, while the inbox itself costs nothing.
Step 1. Switch on the channels that collect requests#
An empty section is not a breakage but an honest "there have been no requests yet". To make the stream appear, switch on at least one of these:
- Widgets on your own website — one tag and ready-made products on top of it: a popup with a form, a callback, booking, reservations, online ordering. See My site: widgets.
- Forms on our storefront — the contact form and the forms on the location's site pages.
- Callback — the "call me back" button on the storefront or on your own site: callback.
- Online booking and reservations — appointments and tables; their requests land here too.
A request appears in the list as soon as the visitor presses "Send".
Step 2. Groups, period and filters#
At the top is the location selector. Inside a location the list is split into automatic groups "source plus its specifics": a popup campaign, a particular page form, or the whole channel for the rest. There is nothing to configure — the groups appear on their own, and each has two counters: total rows and unhandled ones. To their left sits "All requests".
| Control | What it does |
|---|---|
| Period | 7 / 30 / 90 / 365 days |
| Search | by name, phone, e-mail and the text of the answers |
| "Unhandled only" | leaves what has not been dealt with |
| "New since your last visit: N" | the visit marker is local, one per location: requests have no server-side "read", so the counter is not shared across the team |
| "Total: N" | how many rows are shown with the current filters |
| Surface chips | "Your Cenaly storefront" / "Your own site"; they appear only if the stream has more than one surface |
A list row shows the channel, the time the request appeared (not the time of the visit: otherwise a booking made for next month would fall to the bottom), the contacts and the gist of the enquiry. The status comes from the source: New, Handled, Cancelled.
Step 3. The request card and the source passport#
Clicking a row expands the details: the answers to all the form fields and the Source block — a passport of where the person came from:
| Passport line | What it shows |
|---|---|
| Surface | "Your Cenaly storefront" or "Your own site" (with your domain) |
| Widget / Popup campaign | which product exactly collected the request |
| Page | the normalised path; the link opens that page |
| Campaign tags | UTM tags of the visit |
| QR / action link | if this is one of our QR links, you get "placed on / action" instead of raw tags |
| Came from | Maps · Search · Social · Direct · Another site |
| Device | Phone or Computer |
Three things worth understanding about this block:
- It is computed at read time from the fields the channels already store. The passport is not written into the request itself — otherwise it would gain a second truth about its own origin.
- The surface is decided by the page address, not by the channel. A widget placed on your own domain that serves our storefront is honestly read as the storefront.
- For older requests the block is shorter, not empty. Records from previous months do not have the newer fields and will not gain them retroactively: missing knowledge is shown by a missing line, not by a dash and not by the word "unknown".
There is no personal data in the passport beyond what the visitor left: what goes out is a referral class (one of five values) and a single bit about the device. We store neither the raw referrer nor the browser string anywhere.
If the request came from your own form, captured by our tag, the card says so honestly: we saw the visitor submit it, not what your backend did with the data.
Step 4. Working with a request#
The row has three quick actions:
- "Call" opens the number on the device;
- "Write" opens the mail client;
- "Open section" leads to where the request really lives: Appointments, Tables, Customers, "Popups and forms" or the site settings.
The section only reads, and that is deliberate. Confirming a booking, marking a callback as done, deleting a lead — all of it happens in the profile section. If Requests changed statuses on its own, the same request would end up with two truths about what has already been done to it.
That is also why the section has no "request owner": the owner is assigned where the request is handled — in the booking, in the appointment or in the customer card. And converting into a customer is exactly what "Open section" does for a callback: the guest card with their whole history lives in Customers.
Step 5. CSV export#
The "Export CSV" button builds the file from the visible rows — respecting the chosen location, group, period, search and filters. In practice that means: first filter the list the way you need it, and only then export.
The file includes the source passport columns: surface, widget, UTM tags, referral class, device. It is prepared for Excel (non-Latin characters survive) and protected against formula injection into cells.
Where else the same stream lives#
The same panel is mounted as the Requests tab of the contact centre — the "Guests" section of the work chat (/team-chat/?guests=1&tab=leads). It is one and the same list: the component is shared, and there is no second truth about what the stream contains. The only difference is that there the location selector already sits in the tab row, so the panel does not draw its own.
That suits an operator who spends the day in guest conversations: requests and threads end up in one window.
Limitations#
- Statuses are not changed here. The section reads; "handled" is set in the profile section and read back from there.
- There is no section-level "read" mark. The "new since your last visit" counter is local to your browser and your location: a colleague has their own.
- Chat conversations are not included — guest threads live in the neighbouring tab of the contact centre, and they are not requests.
- Orders are not included — they have their own section with an operational flow.
- A channel that did not answer is visible. Such a case lands in a yellow banner "these channels did not answer and may be missing rows": "empty" and "broken" are never silently merged. The exception is callbacks and appointments: for them a missing file reads as "there were no requests", so they do not appear in the banner.
- The section dictionary covers 11 languages (English, Russian, Georgian, Turkish, Ukrainian, Polish, German, French, Spanish, Italian, Albanian); other languages see the English wording.
- The source passport will not appear retroactively. For requests collected before it existed some lines are simply absent.
Troubleshooting#
| Symptom | Check |
|---|---|
| The list is empty | the selected period (it is not unlimited by default), the location in the selector and the "unhandled only" filter |
| The yellow "may be missing rows" banner | it lists the channels that did not answer a read: a channel may be disconnected or temporarily unavailable — nothing is lost, refresh the page |
| A request from the site did not arrive | whether our tag is on the page and the widget is on — see My site: widgets; an installation check lives in that section |
| It arrived but with no contacts | the visitor did not leave them: the row says "No contact details left". Make the field required in the form settings |
| The "new" counter does not reset for a colleague | that is expected: the visit marker is local, one per person |
| The passport has no "Page" or "Came from" line | the request is old, or the channel does not provide those fields — missing knowledge is shown by a missing line |
| The status does not change | it is not meant to change here: press "Open section" and change it where the request lives |
| The CSV does not contain all rows | the file is built from what is visible: drop the filters and widen the period before exporting |
A symptom-by-symptom walkthrough lives in troubleshooting; if nothing helped, write to us — see how to get help.
FAQ#
How is Requests different from Customers?#
Requests is a stream of enquiries over a period: who contacted you and when. Customers is a directory of people: the guest card, history, debts, segments. A callback in Requests leads exactly into the customer card.
Why is a service booking in both Requests and Appointments?#
Because it is the same booking seen from two sides. In Requests you see it as an enquiry in the common stream; in Appointments as an event in the calendar with confirmation, rescheduling and reminders. There is no copy of the data.
Can I assign an owner to a request?#
Not in this section. The owner is assigned where the request is handled: in the booking, the appointment, the customer card or the guest chat thread.
What do "Your Cenaly storefront" and "Your own site" mean?#
The surface is decided by the address of the page where the request was left. If the widget sits on your own site (WordPress, Tilda, hand-written) it is "Your own site". If the form was opened on the storefront we built for you, it is the storefront — even when it runs on your domain.
Do requests feed advertising statistics?#
The source passport carries UTM tags and the referral class, and both are exported to CSV — enough to match enquiries to an ad campaign. The campaigns and their budgets themselves live in the advertising sections.
Who sees the personal data in requests?#
Whoever the role gives section access to. The rows are personal data left by a visitor, so access is worth opening only to the people who actually process enquiries; see data and security.
Related articles#
- My site: widgets — the popups, forms and buttons that collect requests
- Callback and the order widget — enquiry channels that do not require a call to you
- Customers — the guest card a callback request leads to
- Appointments and Tables — where bookings are confirmed
- Team chat and guests — the same panel as a tab of the contact centre
- Guest chat — conversations, which are not requests
- App store — where the paid source channels are switched on
- Data and security — who sees visitors' contact details