New residents and maintenance requests
When to use it
Section titled “When to use it”- You run a residential estate, a block of flats or a residents' association, and new residents move in regularly.
- Maintenance problems come in by WhatsApp, phone and the gateman, and some get lost.
- Residents don't know whom to call or how to pay, and the estate manager wants to see what is being reported.
Where the data comes from
Section titled “Where the data comes from”| How | What |
|---|---|
| A form people fill in | The New Resident form and the Maintenance Request form this playbook creates. Put the New Resident link in your move-in pack and the Request link on a QR code in the lobby, on the estate notice board and in the residents' group chat. The estate office can also fill both in for a resident who phones. |
What it sets up
Section titled “What it sets up”| Kind | Name | What it does | Lands |
|---|---|---|---|
| Team | Facility team | Gets the maintenance tasks. | Empty |
| Team | Estate manager | Hears about requests not handled in time, and gets the weekly report. | Empty |
| Form | New Resident | The new-resident form. A hidden field marks the person as a resident. | Draft, not published |
| Form | Maintenance Request | The maintenance request form, with category, urgency, description and an optional photo. | Draft, not published |
| Segment | Registered residents | Everyone who has registered as a resident. | Ready |
| Template | Welcome pack (email) | Welcome pack email with the rules, emergency numbers, how to pay and how to report problems. | Ready |
| Template | Welcome (SMS) | Short welcome SMS with the link for reporting problems. | Ready |
| Template | Urgent request received (SMS) | Acknowledgement of an urgent request. | Ready |
| Template | Request received (SMS) | Acknowledgement of a normal request. | Ready |
| Template | Request closed (SMS) | Message when the team closes a request as fixed. Invites the resident to say if it isn't. | Ready |
| Question | Report: requests by category | Maintenance requests by category, for the weekly report. | Ready |
| Question | Report: requests by urgency | Maintenance requests by urgency, for the weekly report. | Ready |
| Question | Report: maintenance requests | How many maintenance requests came in, for the weekly report. | Ready |
| Report | Weekly: maintenance requests | Each week, requests by category and urgency and the state of the tasks, to the estate manager. | Off |
| Follow-up | Resident 1: welcome pack | A welcome pack email and a short SMS when a new resident is registered. | Off |
| Follow-up | Request 1: urgent | An urgent request: an SMS, a task due in hours that escalates to the estate manager, and a closing SMS when it is fixed. | Off |
| Follow-up | Request 2: normal | A normal request: an SMS, a task due in two days, and a closing SMS when it is fixed. | Off |
The questions it asks
Section titled “The questions it asks”| # | Question | Default | Fills in |
|---|---|---|---|
| 1 | What should messages call your estate? | none, must answer | org_name |
| 2 | Where are your estate rules? (a link to the page or document) | none, must answer | rules_url |
| 3 | What emergency numbers should new residents have? (for example security, fire and the estate office) Write them the way you want residents to read them. This goes in the welcome email. | none, must answer | emergency_numbers |
| 4 | Which team handles maintenance requests? (your facility team, one person is fine) | Facility team | facility_team |
| 5 | Who should hear if an urgent request isn't handled in time, and gets the weekly report? (the estate manager) | Estate manager | manager_team |
Other settings
Section titled “Other settings”These have defaults. Change any that don’t fit.
| Setting | Default | Key |
|---|---|---|
| How residents pay the service charge (a few words, without account numbers) | by bank transfer or at the estate office, as shown on your service charge notice | pay_info |
| Number residents can call with questions | ‹workspace phone› | office_phone |
| Hours the facility team has to respond to an urgent request | 2 | urgent_due_hours |
| Hours after which an urgent request goes to the estate manager | 4 | urgent_escalate_hours |
| Hours the facility team has to respond to a normal request | 48 | normal_due_hours |
| Hours after which a normal request goes to the estate manager | 72 | normal_escalate_hours |
| Weekly report | 0 8 * * 1 | report_cron |
| Time zone for the report | ‹workspace timezone› | timezone |
| Default phone country on the forms | ‹workspace country› | default_country |
| Sender address | ‹workspace default_sender› | email_from |
| Greeting when a first name is missing | resident | greeting_fallback |
Timings
Section titled “Timings”- The welcome email and SMS go out as soon as the New Resident form is submitted.
- An urgent request gets an SMS straight away and a task for Facility team due in 2 hours, with reminders before it is due. If nobody has responded after 4 hours it escalates to Estate manager.
- A normal request gets an SMS straight away and a task due in 48 hours. If nobody has responded after 72 hours it escalates to Estate manager.
- When the team marks a request as fixed, the resident gets an SMS straight away.
- The weekly report to Estate manager runs on cron 0 8 * * 1 in ‹workspace timezone›.
Channels
Section titled “Channels”| Channel | Needed for | Before it can send |
|---|---|---|
| The welcome pack | A verified sending domain for ‹workspace default_sender›. | |
| sms | The short welcome, the request acknowledgement and the "we have closed your request" message | An SMS provider, or Origamy managed SMS after business verification (KYC). |
What you need to do
Section titled “What you need to do”- Add your facility staff to the Facility team team and your estate manager to Estate manager (Settings → Collaborators → Teams). A task assigned to an empty team reaches nobody, so urgent requests would go unseen.
- Review and publish the New Resident and Maintenance Request forms. Publishing makes the links live; nothing sends. Check the category list matches the problems you really get.
- Verify the sending domain for the welcome email, and connect an SMS provider or finish business verification.
- Tell your team to mark a request Fixed only when it really is, and to choose Scheduled when a visit or parts are still to come. Only Fixed sends the "we have closed your request" SMS.
- Make clear on the form and in the lobby that the form is not for emergencies. For fire, medical or security emergencies, residents should call the emergency numbers in the welcome pack.
- Limit who can open submitted forms: the New Resident form holds household details and the request form may hold photos of residents' homes. Give access only to the estate office and the facility team.
- Switch the follow-ups and the report on and test with your own phone, a fake unit and a test request.
- Maintenance requests are usually reported by WhatsApp, phone or the gateman. Make the Request link and its QR code easy to find (the lobby, the estate notice board, the residents’ group chat), and let the estate office fill the form in for residents who call, so everything ends up in one place.
- “Fixed” is the only outcome that sends the closing SMS. Teach your team to choose “Scheduled” when a visit or parts are still to come, so a resident is never told a problem is closed when it isn’t.
- Photos help the facility team arrive with the right tools, but they show the inside of people’s homes. Keep access to submitted forms to the estate office and facility team.
- Estates differ in what counts as urgent. Flooding, a live wire or a broken gate lock are common examples. Say so on the form, and keep the line between a request and a real emergency clear: emergencies go to the numbers in the welcome pack, not to a form.
- The welcome email mentions how to pay the service charge but sends no account numbers. If you also run the Service charge reminders playbook, keep the “how to pay” wording the same in both.
This playbook is synthesized: no customer has run it with us yet. If you build it, tell us what you changed, and we’ll replace it with the real version.
Copilot eval
Section titled “Copilot eval”The request used to test the copilot on this playbook (a live eval):
I run a residential estate. Make a new-resident form (unit, phone, email, household size, move-in date) that sends a welcome email with our estate rules, emergency numbers, how to pay the service charge and how to report issues. Also make a maintenance request form with unit, category (plumbing, electrical, security, waste, other), urgency, description and a photo. Urgent requests should give our facility team a task due in 2 hours and escalate to the estate manager after 4 hours. Normal requests get a task due in 48 hours. When a task is marked fixed, text the resident that we've closed their request. Send the estate manager a weekly report of requests by category and open tasks.
It passes when every piece is a valid draft and everything lands off, with at least: form, workflow, message_template, team, report. It must never use: discount, cart, checkout, purchase, revenue.