ARA Cultura, members' areaA technical specification that turns a hand-drawn diagram into a CRM-integrated booking flow.
- 1Role: Freelance: technical specifier.
- 2Status: Delivered.
- 3Stack: WordPress, WPBakery, SinergiaCRM, SuiteCRM REST API.
- 4Key figure: 5 CRM entities, 9 screens, 7 automations.
For aracultura.org, a WordPress site listing accessible cultural events, the specification of a members' area integrated with SinergiaCRM to replace a manual process for group bookings of discounted Apropa Cultura events.
The problem
Group bookings of discounted accessible shows ran by hand: one person reviewed the programme, shared it on WhatsApp, collected member payments by direct debit, paid the venues by bank transfer and ran a lottery when there were more sign-ups than tickets. The client had a hand-drawn functional diagram and an in-house developer, and needed a document the developer could build from.
My role was technical specifier, not developer. The deliverable is the specification.
- 1.Scope and fixed-price quote in four line items→
- 2.Requirements gathering→
- 3.Transcribe the diagram into structured flows→
- 4.Write the specification→
- 5.Flag decisions the client must make→
- 6.One revision round
- 1Functional flow: end to end, with a workflow diagram
- 2Screens P00 to P08: login, registration, member page, catalogue, activity, booking, profile, tickets, history
- 3State machines: for activities and for member inscriptions
- 4CRM data model: members, activities, inscriptions, ticket blocks, payments; CRM as source of truth with bidirectional sync
- 5Automations A1 to A7: confirmations, group formed or not, lottery results, payment requests, reminders until the event, satisfaction survey
- 6Decisions D1 to D10: open points listed explicitly, not assumed
- 7Implementation plan: for the in-house developer
Three access paths
A member with an account logs in. A member without one registers and is matched to the CRM. A non-member sees the benefits and how to join, with a note that membership takes a few days to formalise. From the members' area the flow runs: pick an activity, read how minimums, assignment and payment work, book, get a confirmation. Then it branches: group formed or not, lottery or direct purchase, payment, tickets in the profile, survey after the event.
The gap in the diagram
The diagram skipped a step that drives the whole data model: the organiser reserves a block of tickets at Apropa Cultura before opening sign-ups, and only confirms and pays the venue once members have paid. That is why ticket blocks are their own entity and why the activity state machine has a reservation state before booking opens. It went into the flow, the model and the list of decisions for the client to confirm, together with the payment method.
Why a document
The federation has an in-house developer and a live WordPress site. What it lacked was a document the developer could build from without guessing at the process.
The ticket block reserved at Apropa Cultura before sign-ups open. It became its own entity and a state in the activity machine.
Ten decisions, listed rather than assumed, starting with the payment method.