3 Replies Latest reply on Jul 5, 2018 12:04 PM by Steven Gaittens

    Appointment Reminders for patient with multiple cases

    Dominik Wegner

      Hey there,

      We're just in the process of setting up a customer journey for a physio company. My questions are around how the database should be setup for patients that have multiple cases.

       

       

      Setup is a custom CRM that is pushing data daily into Marketo

       

      Example

      Patient A has scheduled an appointment in one weeks time and one in 4 weeks time. (some patients have treatment plans that can span up to 10 visits)

       

      Fields Used: fname, lname, time, clinic_location, therapist, treatment_area

       

      These fields will change(dynamic): time, therapist, treatment_area

       

      Questions

      If the fields that I indicated above are dynamic how do we store that in Marketo?

      Should we just create multiple fields per record?

       

      Let me know, thanks in advance

        • Re: Appointment Reminders for patient with multiple cases
          Jay Jiang

          You need to be a lot more detailed in explaining your CRM set up. There are a couple of ways I can think of to make it work but I'm making lots of assumptions on the capabilities/limitations of your CRM.

          How is your CRM pushing data to Marketo? through middleware? export, transform, load?

          How is each appointment along with time, therapist, treatment_area saved in the CRM?

          Why can't your CRM just update a lead with the next immediate appointment details on your daily syncs so you don't need to create X "sets" of custom fields for X number of lined up appointments?

          • Re: Appointment Reminders for patient with multiple cases
            Sanford Whiteman

            In addition to Jay's questions about how you're actually updating (and the good suggestion that if you only care about one "upcoming" appointment on any given day, you can just keep one set of fields updated from the source) there's an elephant in the room: Marketo should not be used to send operational emails like medical appointment reminders.

             

            This isn't just a Marketo thing: no multi-tenant MA system should be entrusted with this responsibility, even if your client considers a PT session to be less important than a surgery appointment.

             

            If you have a dedicated Marketo server, the risks are lower, but you don't want any risk of these emails being flagged as promos simply because they come from Marketo's IP range.

             

            Such emails should be sent from a server that is never, er, implicated in marketing.

             

            At any rate, to maintain one-to-many relationships in Marketo -- relationships between a lead and a set of other things -- while referencing said things in emails, you typically use Custom Objects. (Orders, quotes, appointments, holdings, interests, opportunity-like facts are all things here.) You don't use flat lead fields at all. But let's not skip over the big question above.

            • Re: Appointment Reminders for patient with multiple cases
              Steven Gaittens

              I'm in agreement with Jay and Sanford here. But if you were to use Marketo for this kind of activity... I would suggest (against my better judgement) using a custom object.

               

              If you make an Appointments custom object that is linked to your Person records by email address and dedupes on time and therapist (or whatever combination of fields that would guarantee each appointment record is unique), you could have a number of Appointments associated with each Person record, so you could run your email smart campaigns in parallel. There is, however, a whole host of limitations and quirks that come with Marketo's custom objects, and you would still need to bring your data in from your CRM, likely utilizing the REST API. But aside from cluttering up your Person object with multiple iterations of your appointment-related fields, I think a custom object would be the way to go. We've used custom objects to hold data from a number of external systems, and although we've hit a few roadblocks, they function well enough to get the job done.