SLUG: handling-low-fodmap-tickets TITLE: Low FODMAP — handling tickets TAGS: ["loopa","health","protocols","support"]

Low FODMAP: handling tickets

Low FODMAP is a three-phase therapeutic protocol inside Loopa, not a diet preference. Most tickets about it are one of five things, and four of those are the protocol working as designed.

Premium, on the key fodmap. The only thing outside the gate is the vocabulary the app needs to draw the purchase sheet. Logging food is free and always has been; the protocol and the meal check are the paid part.

"It won't let me start the restriction phase"

Expected. Restriction needs seven days that carry a symptom entry — not seven days elapsed. The assessment at the end compares against that baseline, and a baseline built from two entries produces a result nobody should act on.

The app shows the count. baseline_too_short is the refusal code.

"It says my restriction ends on a date I didn't pick"

Expected, and it cannot be changed. The end date is written the day the phase starts and there is no way to extend it — no button, no setting, no admin override. Published guidance is that this phase should run no more than four to six weeks; Loopa uses six as a hard ceiling.

If a member wants to run the trial again they exit and enrol afresh, which starts a new dated record.

"It told me my trial didn't work and won't let me cut out more"

Expected, and it is the most important behaviour in the feature. If the symptom score did not drop by at least 50 points, Loopa's guidance is to stop, not to restrict further. That is the published advice, and escalating restriction is the failure mode this protocol is designed to avoid.

The member is offered personalization or exit. There is no path back into restriction from anywhere except baseline. Do not tell a member to re-enrol in order to restrict harder.

"It says 'no FODMAP data' for a food I eat all the time"

Expected. Loopa's food measurements come from published, peer-reviewed compositional analyses, and those do not cover everything. Two cases produce it:

• the food matched nothing at all
• the food was measured for some of the six groups but not all of them

The second is the common one, and it is deliberate. Cauliflower's fructan content was measured and is low; its mannitol, which is the part that matters about cauliflower, was not. Reporting that as "fine" would be the most damaging thing the feature could do, so it reports "no complete data" instead.

This is not a bug to escalate. If a member asks for a food to be added, note the food — the dataset grows only when a published measurement exists for it.

"The app says my meal is high but every item looks fine"

That is stacking, and the result says so. Several modest servings add up, and Loopa counts anything logged in the previous three hours as part of the same meal. The result names the group and says the sum crossed rather than any item.

What a coach can see, and what they cannot

A coach with the fodmap switch on sees the phase, the cap date, a count of days logged, and the tolerance profile. They never see a symptom score, anything about stools, a symptom note, or what any meal was checked as. If a member reports a coach seeing symptom data, that is a real defect — escalate it.

A clinician report is different and does include the readings. That is intentional: a coach gets the plan, a clinician gets the record.

The enrolment screen

Five questions about the member's relationship with eating, shown before they can start. A positive screen blocks self-enrolment with a supportive message pointing at a clinician.

Nothing about it is stored. Not the answers, not a score, not the fact that it ran. If a member asks what Loopa kept, the honest answer is: the date they completed it, and nothing else. There is no field that could hold anything more, so there is nothing to look up and nothing to delete.

Members can retake it whenever they like; there is no attempt counter.