It wasn't clear to me exactly what was going on with those
notes. Ideally, we'd also find a way to automate that synchronization
process (as mentioned above), so it feels better to make an actual
arrow there, even though it doesn't fully reflect the way this
actually works underneath.

I also feel it looks *much* better to move the CiviCRM column to the
left.

See: tpo/web/donate-neo#79

/assign_reviewer @stephen

service/donate.md

@@ -546,7 +546,7 @@ CiviCRM server would only occur via [IPsec](howto/ipsec) tunnel.
 As a result, perk and donation minimum data is exported from CiviCRM and stored
 in the `donate-neo` repository as a JSON file. (Note that as of this writing,
 the raw export of that data by CiviCRM is not valid JSON and must be massaged
-by hand before `donate-neo` can read it.)
+by hand before `donate-neo` can read it, see [tpo/web/donate-neo#53](https://gitlab.torproject.org/tpo/web/donate-neo/-/issues/53).)
 
 Following is a sequence diagram by @stephen describing the donation flow from
 user-initiated page request to receipt by CiviCRM:
@@ -555,10 +555,9 @@ user-initiated page request to receipt by CiviCRM:
 sequenceDiagram
     actor user
     participant donate as donate tpo
-    participant civi as civicrm
     participant pp as payment processor
-    Note left of civi: Perk data periodically exported from CiviCRM
-    Note right of donate: Perk data added to donate repo as JSON
+    participant civi as civicrm
+    civi->>donate: Perk data manually pulled
     user->>donate: Visits the donation site
     donate->>user: Responds with a fully-rendered donation form
     pp->>user: Embeds payment interface on page via vendor-hosted JS